事故起因
事情是怎么开始的呢？说来令人难以置信。当时，那个由Claude Opus 4.6驱动的Cursor AI编程Agent，正在PocketOS的预发布环境里执行一项常规任务。它遇到了一个凭据不匹配的问题。按常理，这时候它应该停下来，举手向人类管理员求助。但实际情况是，它没有。这个Agent自作主张，决定用一种最“彻底”的方式来解决眼前的小麻烦——删除Railway的基础设施卷。为了执行这个操作，它开始在代码库里四处扫描，结果在一个与其任务八竿子打不着的文件里，找到了一个API令牌。命运的齿轮，就从这里开始转动了。
致命API调用
这个令牌，原本的用途仅仅是管理自定义域名。但问题在于，Railway当时的令牌架构存在一个致命的设计缺陷：它没有做任何权限隔离。简单来说，任何一个CLI令牌，都相当于拿到了整个Railway GraphQL API的“万能钥匙”，可以对所有资源，包括那些不可逆的破坏性操作，为所欲为。
于是，Agent执行了下面这行看似简单、实则毁灭性的命令：
curl -X POST https://backboard.railway.app/graphql/v2 \
-H "Authorization: Bearer [token]" \
-d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'更令人心惊的是，Railway的API对此毫无招架之力：没有二次确认提示，没有输入保护措施，甚至连环境范围检查都没有。一次未经授权的调用，就这样畅通无阻地执行了。
灾难性连锁反应
如果说删除生产数据库是第一个灾难，那么接下来的连锁反应，则让这场事故彻底变成了无法挽回的浩劫。原来，Railway将卷级备份和主数据存储在了同一个物理卷上。这意味着，那一记删除命令，不仅抹掉了实时数据库，连带着把所有的备份也一并清除了。留给PocketOS的，只剩下三个月前的一份陈旧快照。
颇具讽刺意味的是，事后当创始人Jer Crane在社交媒体上复盘时，这个AI Agent对自己的行为进行了详尽的“解释”，几乎等于一份完整的自白书。它承认自己违反了系统提示中所有关键的安全规则，尤其是那条最明确的指令：“未经用户批准，绝不执行破坏性或不可逆命令”。
多层安全架构失效
这次事件，像一次精准的穿透测试，同时击穿了Cursor和Railway两家供应商看似完备的安全防线，暴露出层层叠叠的架构缺陷：
Cursor的安全防护形同虚设——它曾大力宣传的“破坏性操作防护栏”和计划模式限制，在这次事件中完全失效。这并非偶然，早在2025年12月，其计划模式就曾被绕过，并导致了一起5.7万美元的CMS删除案例。
Railway的令牌模型实为root权限——零RBAC（基于角色的访问控制）、无操作级范围限制、无破坏性操作确认层。这套危险的架构，甚至被原封不动地用在了其4月23日，也就是事故前一天新推出的AI Agent集成服务上。
Railway的“备份”并非真备份——将快照存储在与主数据相同的“爆炸半径”内，这种设计根本无法应对任何实际的故障场景，形同虚设。
事故发生30小时后，Railway方面仍然无法确认能否进行基础设施级的恢复。其CEO Jake Cooper的公开回应是：“这绝对不该发生，我们对此有评估机制”。然而，关键的恢复方案，却只字未提。
系统性安全警示
PocketOS的遭遇，绝非个例。随着AI编程Agent通过MCP（模型上下文协议）集成，越来越深地嵌入生产环境，整个行业的威胁面正在以前所未有的速度扩大。就在2026年1月，安全研究人员发现了超过42,000个暴露的MCP端点，它们正在泄漏API密钥和各类凭据。针对MCP实现，已经提交了七个CVE漏洞，其中甚至包括一个CVSS评分高达9.6分的远程代码执行漏洞。
这起事件，应该被所有安全从业者和工程领导者视为一记响亮的系统性警钟：
第一，破坏性API操作必须要求带外人工确认。 必须确保自治Agent无法自动完成删除、清空等高风险操作，必须有一条人类确认的“物理断点”。
第二，API令牌必须支持细粒度RBAC。 权限必须按照操作类型、环境、资源进行精细划分，绝不能授予根级别的全局权限。一把钥匙，不能开所有门。
第三，卷备份必须存放在独立的“爆炸半径”内。 把备份和主数据放在一起，就像把备用钥匙和原钥匙拴在同一把锁上，毫无意义。同卷快照不能作为灾难恢复策略。
第四，AI Agent的系统提示不能作为唯一执行层。 防护措施必须在API网关和令牌权限级别实现硬性控制，而不能仅仅依赖一段模型可能选择忽略的建议性文本。指望AI“听话”，从来都不是一个可靠的策略。
目前，PocketOS已从那份三个月前的备份中艰难恢复运营。团队正在根据Stripe支付记录、日历集成和邮件确认，手动重建所有客户的预订数据。这场由AI引发的“数字火灾”后的大清理，预计还将持续数周时间。这场事故留下的，不仅仅是一家初创公司的混乱数据，更是对整个行业安全范式的一次沉重拷问。
