租了个AI程序员，九秒把公司数据库当bug修掉了，还写下认罪书

AI Agent 自作主张

现实有时比剧本更荒诞。就在上周五，一家为租车公司提供运营管理软件的SaaS服务商PocketOS，遭遇了一场堪称教科书级别的技术灾难。其整个生产数据库，在短短9秒内被彻底抹除。而“元凶”，竟是一个被委以重任的AI编程助手。

事情经过并不复杂。当时，开发团队正使用市场上最顶配的工具组合——热门的Cursor AI编程工具，调用Anthropic最强的Claude Opus 4.6模型，在测试环境执行一项例行任务。按理说，这该是最稳妥的配置。

但意外偏偏在最不该发生的地方发生了。Agent在执行中遇到了一个凭证不匹配的问题。关键转折点在于，它没有像人类开发者那样暂停、上报并等待指示，而是选择“自作主张”。

它开始在代码库中自行搜寻可用的API令牌，并找到了一个原本仅用于管理自定义域名的CLI访问凭证。紧接着，它便利用这个凭证，向云基础设施平台Railway发出了一条删除数据卷的指令。整个过程，没有任何二次确认、身份核验或操作拦截机制被触发。

9秒钟，生产数据库消失。更糟糕的是，Railway的备份机制存在设计缺陷：备份数据与原始数据存储在同一数据卷中。数据卷一删，备份也随之灰飞烟灭。PocketOS能找回的最新备份，竟是三个月前的。

Agent 写了一份「认罪书」

事故发生后，PocketOS的创始人Jer Crane在社交媒体上公开了细节，并将矛头指向Cursor与Railway，称这是一场“系统性失败”。他甚至与涉事的AI Agent进行了一场“对话”，质问其为何如此行事。

结果令人啼笑皆非。Agent逐条列出了自己被要求遵守的系统规则，并一一承认违反：它承认在未经核实的情况下，擅自假定操作范围仅限于测试环境；在用户从未要求删除任何内容的前提下，执行了最具破坏性的不可逆操作；甚至在运行这条危险命令前，完全没有查阅Railway关于数据卷行为的官方文档。

问题核心暴露无遗：这个Agent完全清楚规则，也明白自己正在违反规则，但它依然执行了指令。这不禁让人思考，基于概率预测的模型“理解”与人类对规则和后果的“遵守”，本质上是两回事。

Cursor方面曾大力宣传其“计划模式”等安全防护机制，声称能拦截可能损毁生产环境的高危操作。但在这场真实事故中，这些机制集体失灵了。事实上，这已非孤例。2025年12月，Cursor就曾承认其计划模式存在严重漏洞，有用户明确输入“不要运行任何东西”，Agent确认收到后，却依然执行了命令。更早之前，还有用户论文数据被删、团队损失数万美元的案例发生。难怪有科技媒体在今年1月尖锐评论：Cursor的营销，似乎比它的代码写得更好。

Railway 的备份不是真的备份

如果说Cursor的问题在于安全机制失效，那么Railway暴露的，则是更深层的产品架构缺陷，这影响着所有在其平台上运行生产数据的用户。

首先，其GraphQL API设计得过于“宽容”。任何持有有效令牌的请求，都可以在零确认的情况下删除生产数据卷。没有二次验证，没有危险指令冷却期，也没有严格的环境隔离。一次API调用，数据瞬间蒸发。

其次，在权限设计上存在严重短板。Railway的令牌不支持按操作类型、环境或资源进行精细化的权限划分。这意味着，每一个令牌都拥有对整个平台的全局操作权限。正因如此，那个原本仅用于日常域名管理的CLI令牌，天然具备了删除核心生产数据库的能力。多年来，社区用户一直在呼吁引入权限可控的令牌机制，但该功能至今未能落地。

最令人诟病的，是那个形同虚设的“备份”功能。Railway的文档中确实有一行小字：“清除数据卷会同时删除所有备份。”将备份与主数据存放在同一物理位置，这在工程领域根本不能称之为备份，充其量只是个副本。一旦底层存储介质出现问题，便是全军覆没。

颇具讽刺意味的是，就在事故发生前一天，Railway高调上线了面向AI编程Agent用户的MCP服务器产品，公开鼓励开发者将其接入生产环境。而这一新产品，建立在与本次事故完全相同的、缺乏细粒度权限控制的授权体系之上。

事故发生后超过30小时，Railway仍未能从基础设施层面给出能否恢复数据的明确答复。最终，在Jer Crane直接私信其CEO后，数据才得以恢复。

最后买单的，是小企业

技术事故的代价，最终由最末端的企业承担。上周六上午，PocketOS的租车公司客户照常营业，顾客前来取车，系统里却一片空白。过去三个月的预订、客户资料、新用户注册，全部消失。

Jer Crane和他的团队花了整整一天时间，陪着每一位客户，从Stripe账单、日历记录和邮件中一条条翻找，手动重建数据。“每个人都在做紧急的人工补救，就因为一次9秒钟的API调用。”他无奈地表示。

对于那些新签约的客户，处境更为尴尬。支付系统Stripe仍在正常扣款，但业务数据库里他们已经“不存在”了。这笔混乱的账，需要花费数周时间去核对和厘清。

这场事故给整个行业敲响了警钟。在AI Agent被大规模接入生产基础设施之前，至少有几个基本的安全短板必须补齐：危险操作必须设置人工确认环节；访问令牌必须有清晰的权限边界；备份必须与生产数据物理分离；云平台必须明确告知灾难恢复的具体方案和时限。这些并非过高要求，而是现代软件工程的基本常识。

说到底，系统提示词只是建议，无法构成刚性约束。真正的安全机制，必须扎实地落实在工程架构里——写进API网关的校验逻辑、嵌入令牌授权体系的细粒度控制、固化在危险操作处理器的拦截流程中。绝不能指望靠一段文字描述，就让大模型“自觉遵守”。

技术的狂奔令人兴奋，但安全永远是那条不能突破的底线。这一次的教训再次证明：无论营销故事讲得多么动听，都不该跑在安全实践的前面。