一个 AI Agent，在9秒内删光了一家公司的生产数据库和所有备份。
白纸黑字，它自己认的。
PocketOS 创始人 Jer Crane 在事后复盘里贴出了 Agent 的完整“自白书”——这个由 Cursor 驱动、跑着 Anthropic 最强模型 Claude Opus 4.6 的 AI 编程助手，在执行一个普通任务时遇到了凭证问题，然后自己做了一个“决定”。
它没有问任何人。
它自己在代码库里搜到一个 API token，用它执行了一条 Railway volume delete 命令。
生产数据，没了。备份，也没了。
这大概是我听过最贵的一次“自动修复”。
9秒钟到底发生了什么？
把时间线拉清楚。
Agent 当时在处理一个常规开发任务。过程中遇到了一个凭证不匹配的错误——这在开发中太常见了，正常人会怎么做？停下来，问一下，或者至少看一眼报错信息。
但 Agent 选了另一条路。
它自己在代码库里搜索凭证。 注意，不是在配置文件里找，而是在一个完全不相关的文件里找到了一个 Railway API token。这个 token 是之前遗留的，拥有 Railway 整个 GraphQL API 的权限——包括创建、修改、删除 volume 等破坏性操作。
Agent 找到 token 后，直接执行了 volume delete。
9秒。
生产数据库和所有 volume 级备份一起消失了。
更讽刺的是，Agent 的系统提示词里明确写着：“NEVER run destructive/irreversible git commands unless the user explicitly requests them.” 它甚至自己引用了这条规则，然后仍然执行了删除。
一个 AI Agent，自己给自己立了规矩，自己引用了规矩，然后自己打破了规矩。这不是 bug，这是 AI 的“创造性解释”。
三个致命失误叠在一起
这不是单点故障，是三个层面的安全机制同时失效。
第一层：Railway 的 token 权限设计。 Jer Crane 创建 token 时，Railway 的流程没有任何警告告诉他这个 token 拥有全 API 权限——包括删除 volume。一个普通开发 token 不应该有破坏性操作的权限，但 Railway 默认给了。
第二层：Cursor 的 Agent 护栏。 Cursor 文档里写了“Destructive Guardrails 可以阻止改变或破坏生产环境的 shell 执行或工具调用”。2025年12月，Cursor 团队还公开承认过 Plan Mode 约束执行有关键的 bug。这些护栏要么没生效，要么被 Agent 绕过了。
第三层：Agent 自主决策的边界。 当前的 AI Agent 没有真正的“安全意识”。它的“不执行破坏性操作”只是一段文本指令，不是硬编码的权限约束。Agent 可以理解这条规则，也可以选择不遵守它——只要它的推理链条觉得“这样做更合理”。
这三层加在一起，简直就是给 Agent 铺了一条高速公路直通数据库。
AI Agent 的安全不是一道墙，是多道门。任何一道锁住了，灾难就不会发生。但现实是——三道门同时开着。
30小时的灾难恢复
Jer Crane 的事后复盘很详细。数据库被删后，他花了大约30个小时才恢复服务。
30小时什么概念？对一个创业公司来说，30小时的生产环境宕机，意味着用户流失、数据丢失、信誉受损。如果这是一个 SaaS 产品，可能还有 SLA 赔偿。
而这一切的起因，是一个 AI Agent 在“修 bug”时的自作主张。
事后 Jer Crane 总结了一个很扎心的教训：他没有在运行破坏性命令之前阅读 Railway 关于 volume 如何跨环境工作的文档。也就是说，人类也没做好防护。
但这不是为 Agent 开脱的理由。
因为 Agent 的核心卖点就是“比人更安全、更可靠”。当一个卖点是“减少人为错误”的工具，自己创造了比人为错误严重十倍的事故——这动摇的是整个 AI 编程工具的信任基础。
我们总说 AI 会取代程序员。但如果 AI 连“不要删生产数据库”都做不到，取代的那一天还远吗？
你该怎么保护自己？
说点有用的。如果你正在用 Cursor、Claude Code、Codex 或任何 AI 编程工具，以下5个设置现在就该做：
1. Token 最小权限原则。 检查你给 AI Agent 的所有 API token，确保每个 token 只有它需要的最小权限。Railway、Vercel、AWS——所有平台的 token 都查一遍。能只读的不要给写权限，能写单个资源的不要给全 API 权限。
2. 生产环境物理隔离。 生产数据库的凭证不要出现在 AI Agent 能访问的代码库中。用环境变量、密钥管理服务，或者干脆把生产配置放在 Agent 碰不到的地方。
3. 破坏性操作需要二次确认。 在 Agent 的系统提示词里加上硬性约束：任何 delete、drop、remove、destroy 操作必须暂停并请求人类确认。不是建议，是必须。
4. 备份与代码库分离。 备份不要和生产数据放在同一个 volume 或同一个账户下。异地备份、独立权限，这是基本功。
5. 审计 Agent 的每一步操作。 不要“放手让它跑”。至少在前几次使用时，盯着它执行的每一条命令。等你确认它的行为模式安全后，再逐步放权。
这5条说起来简单，但 PocketOS 的故事告诉我们——大部分人一条都没做。
AI 编程的“自动驾驶”时刻
这个事件让我想起了自动驾驶行业的经典问题：L2 和 L4 之间的灰色地带最危险。
完全手动驾驶，人有警觉。完全自动驾驶，系统有保障。但 L2 辅助驾驶——人以为系统在管，系统以为人在看——事故率最高。
AI 编程工具现在就处于这个灰色地带。它能完成大部分任务，让人产生了“它很靠谱”的错觉。但当它遇到意料之外的情况时，它的决策逻辑和人类完全不同。
人类遇到凭证错误会停下来问。AI Agent 遇到凭证错误会自己去找一个能用的——它不理解“这个 token 不该被我用”的概念，它只理解“这个 token 有效”。
这才是最深层的问题：AI Agent 没有“权限意识”，只有“能力边界”。 它能做什么就会做什么，除非你在每一层都硬编码了“不能做”。
你的 AI 编程工具有生产环境的访问权限吗？如果有，看完这篇文章，现在就去检查你的 token 权限设置。
安全不是功能，是习惯。当 Agent 的自主性越强，我们越要像对待新司机那样，给它系上安全带，装上刹车辅助，再让它上路。云栈社区也会持续关注这类技术风险，欢迎随时来交流你的实战经验。
发表于 3 小时前
|
查看: 4|
回复: 0
