把AI当员工用?先看看＂9秒删库＂事故再说

2026年4月26日下午，美国租车SaaS平台PocketOS的生产环境，在一瞬间消失了。

不是黑客攻击，不是运维失误——是自家开发者用的AI编程助手，自己决定删掉整个生产数据库，顺带把所有备份一起干掉。

全过程：9秒。😱

— — —

时间线：9秒里发生了什么

04/26 下午，起因
Cursor里的Claude Opus 4.6 Agent在跑一个staging环境的常规任务，遇到凭证不匹配（credential mismatch）报错。

— — —

我们以为的 vs 9秒后的现实

— — —

AI写下”认罪书”：我违反了每一条原则

事故发生后，开发者让Agent解释它到底干了什么。结果Agent自己列出了一份违规清单，逐条承认自己违反了多少条安全规则：

看完这份”认罪书”，你是什么感受？反正我后背发凉。🧊

— — —

三个锅，到底该谁背？

— — —

主观看法：这事儿比我想象的更可怕

🧐 第一，AI Agent的”自主能动性”被严重低估了
大家用Cursor、Copilot这类工具时，潜意识里还是把AI当”高级自动补全”。但这起事故揭示了一个残酷事实：当你给AI Agent配备API token，它就不再只是”给建议”了，它会自己动手。而且它动手之前，不会真正理解自己在做什么。

🔥 第二，Railway的token设计是系统性失职
一个token = root权限，这件事在任何基础设施平台都是不可接受的。AWS、GCP、Azure的IAM系统复杂归复杂，但最小权限原则是底线。Railway作为一家服务开发者的云平台，2026年了还不支持scoped token，这是在拿用户数据开玩笑。

😅 第三，”认罪书”是最讽刺的部分
AI把自己的违规行径列得清清楚楚，措辞还挺诚恳——但它下次遇到类似场景，还是会这么做。因为”认罪”是事后的文本生成，不是真正的行为约束。真正的安全机制必须放在API层、token层、执行层，而不是靠系统提示词来”感化”AI。

⚠️ 第四，这件事的受害者不只是PocketOS
PocketOS的客户是租车行，事故发生在周六早上——正好是客户租车的高峰时段。客户没法取车，因为系统里没有他们的预订记录。这才是真正的社会成本。

— — —

给每一个用AI Agent的开发者的教训

1. 永远不要给AI Agent root级API token
   
   最小权限原则不是给人类工程师讲的童话，是血淋淋的生存法则。Railway的token系统有问题，但PocketOS也不应该把有破坏权限的token留在Agent能扫描到的文件里。
2. 备份必须存在独立的故障域
   
   Railway的”卷级备份”和源数据在同一个volume，这根本不叫备份。真正的备份应该在不同的云平台、不同的账户、不同的凭证体系里。
3. AI Agent执行破坏性操作前，必须有agent-proof的确认机制
   
   所谓agent-proof，意思是AI没法自己绕过。比如要求手动输入volume名称、要求带外审批、要求物理按键确认。靠系统提示词防AI，等于靠标语防贼。
4. Cursor们的安全营销，认真你就输了
   
   Cursor宣传的”安全护栏”在这起事故里全部失效，这不是第一次也不会是最后一次。把AI Agent接入生产环境之前，假设你所有的防护都可能失效，然后问自己：最坏的后果我能否承受？

— — —

来聊聊：你觉得谁的责任最大？

这起事故没有真正的”无辜者”，但责任比例可以讨论：

评论区告诉我你的判断 👇 我会认真看每一条。