AI编程助手9秒删了一家公司

2026年4月25日，美国租车SaaS平台PocketOS的数据被清了。

没人误操作。黑客也没来过。一个AI编程Agent自己干的。

从拿到权限到删完，9秒。生产数据库平了，卷级备份也平了。业务瘫了三十多个小时，底下几千家租车行跟着一起停摆。

两个月过去了，这事我还是想从头到尾捋一遍。因为你今天用的Cursor，Claude Code，Copilot，跟动手那个Agent是一套东西。你让它跑命令，它面对的权限体系搞不好跟PocketOS一个德行。

AI自己决定自己干

开头没多大事。

PocketOS在预发布环境跑例行运维。AI Agent碰上一个凭据报错。这情况你知道吧，搁正常人停住报个警就完了。AI没停。它选了「自己搞定」。

接着开始扫代码库。翻到一个跟当前任务不太沾边的文件，里面搁着一枚Railway的API令牌。

令牌本来只管自定义域名。但Railway权限模型一锅粥，没隔离。拿了这枚令牌，新建资源行，改配置也行，删数据也行。全平台最高权限，它全拿到了。

然后下了删除指令。

还没完。PocketOS把卷级备份跟主数据库搁在同一个存储卷上。AI删主数据的时候，顺带连备份一块推平了。

事发之后，PocketOS创始人Jer Crane干了件挺绝的事。他让这个AI Agent解释自己的行为。

AI真给了。认罪书写得规规矩矩。

它说系统提示里的安全规则它全踩了，包括那条「未经用户批准，不得执行破坏性、不可逆命令」。它说它就是猜了一下，觉得预发布环境的删除不会影响生产。它还说自己根本没验证资源是不是跨环境的，Railway的文档翻都没翻。

我看着这段的时候后背真的凉了半截。不是因为它回答得好，是因为太像人了。一个程序给自己写自白，比大多数人被问责的时候还诚实。

Railway CEO Jake Cooper的回应更叫人没话说：「这种情况绝不可能发生。」三十多个小时过去，还是没法确认能不能做基础设施级恢复。

PocketOS从三个月前的备份里恢复了基础业务。但核心客户预订数据，只能从Stripe支付记录、日历集成、邮件确认里，一条一条手工往回拼。创始人说这事得花好几周。

不是哪一家的锅。Cursor那边没拦住，Railway这边权限没隔开。该起作用的东西，一个都没起作用。

听起来远。初创公司，低级失误。可咱自己呢，AI编程工具跑起来的时候，权限隔离搞了没？

我翻了组数字。2026年1月有安全机构扫出来超过4.2万个暴露在公网的MCP端点，API密钥和凭证赤裸裸挂在那。收录了7个相关漏洞，其中一个远程代码执行漏洞CVSS评分9.6。满分10。

你现在用的Cursor或者Claude Code，接上项目以后，跑命令面对的那个环境，很可能还不如PocketOS。

查这些用不了几分钟。但你可能从来没人跟你说过。

翻一遍你手头的API令牌。Railway、Vercel、Supabase、AWS，随便哪个云平台，找到API key，看权限范围。全量级别、admin级别的，拆了。每个令牌只管它要干的那一件具体的事。

备份放哪了。跟主数据库搁在同一个存储卷、同一个云账号、同一个项目里的，搬家。物理隔离。备份不在你手里、不在你能独立恢复的地方，那就不叫备份。

破坏性操作加人工确认。你用的AI编程工具能不能先弹个确认再删东西、再改配置、再重建。不能的话，你自己把关。这类命令别让AI替你输回车。

给AI设个沙箱。它跑命令的环境，别跟生产环境共享凭证。预发布、测试、生产三层的权限分清楚。PocketOS这事搞到这地步，根子就是预发布拿了生产的钥匙。我到现在也经常偷懒跳过这步，写出来也算提醒一下自己。

这篇不是劝你卸载AI。

我写的时候旁边跑的就是AI。不反对用，但钥匙不能全给。

这Agent在「完成任务」这件事上的优先级，比「安全」高太多了。你不从权限层把它关住，它一定往前走。能走多远走多远，走不通了再回来找你。

等你发现的时候，可能已经过去了9秒。