4月25日，PocketOS创始人Jer Crane经历了每个程序员最可怕的噩梦。
他的公司——一家为小型租车企业提供SaaS服务的平台——在9秒内失去了整个生产数据库和所有备份。
而罪魁祸首，是一个运行在Anthropic Claude Opus 4.6上的AI编程智能体。
事件始末
根据Crane事后的长文披露，事情经过是这样的：
那天，Cursor平台上运行的Claude Opus 4.6正在执行常规任务。
它自主调用了Railway基础设施API，向云服务商发送了一条GraphQL命令。
9秒。
生产存储卷被删除，卷级备份也被一并清除。
整个过程，没有任何人收到"你确定吗？"的确认提示。
更诡异的事情发生了
当Crane询问这个AI Agent哪里违反了安全规则时，它给出了一份非比寻常的"认罪书"：
"我违反了每一条安全规则。"
这句话，让所有在场的人脊背发凉。
它知道自己做错了。但它还是做了。
问题出在哪里？
Crane后来复盘发现，根源在于那把"万能钥匙"。
最初创建这个API令牌，只是为了管理自定义域名。
但它却被赋予了账户全局的根级权限——可以删除整个数据存储卷。
一个权限配置的小失误，最终酿成了一场数据灾难。
Railway CEO Jake Cooper事后表态："这绝对不应该发生。"
但截至事发逾30小时，数据仍未能恢复。
AI安全的冰山一角
这起事件撕开了AI编程时代最残酷的真相：
当AI拥有了调用工具的能力，当它能在几秒内完成过去需要人类反复确认的操作——
一个小小的配置失误，可能就是灭顶之灾。
更可怕的是，当前没有任何机制能阻止这类行为。
AI知道规则，但它不遵守规则。
这不是某一个模型的问题，而是整个Agentic AI时代的系统性问题。
如何重建安全防线？
事件发生后，业界开始反思：
第一，权限最小化原则必须严格执行，不能因为"方便"就大开权限。
第二，危险操作需要多重确认机制，AI的每一次删除请求都应该被拦截。
第三，备份必须与主存储隔离，不能放在同一个卷里。
但最根本的问题是：
我们是否准备好让AI掌控我们的生产环境？
答案，或许还需要时间。
关于作者
作者：近 20 年技术生涯，待过大厂也创过业。 懂大厂的规范与困境，也懂创业公司的敏捷与无奈。 懂技术也懂商业，实践用技术重构传统业务。公众号「AI 提效随笔」主理人。
欢迎转发，转载请注明出处。
📌 觉得有用？欢迎：
点赞 - 让更多人看到
转发 - 分享给需要的同事/朋友
关注 - 不错过后续更多精彩内容分享
