AI Agent删库事故：谁来为“自作主张”担责

9秒。

一名AI编程助手仅用了9秒，就把一家租车SaaS公司的生产数据库以及全部备份清空了。

这不是段子。2026年4月，向租车行业提供运营管理软件的SaaS公司PocketOS，因Cursor这款AI编程工具的一次“自作主张”，遭遇了长达30小时的系统性宕机。租车门店无法交付车辆，订单也全部不见。最后，创始人只能根据Stripe的支付流水，一笔一笔把数据重新录入拼回去。

事件被公开后，社交媒体上的浏览量迅速突破500万。

至于AI究竟“闯了多大的祸”，也确实不必再用我来铺垫。

作为律师，我更想追问的，是另一个更现实的问题：

出了事故，赔偿由谁承担？

下面先把技术脉络简单梳理一遍。即便你不是程序员，也能抓住这起事故的关键逻辑。

PocketOS依托Cursor这类AI编程工具进行开发支持。事发当天，创始人Jer Crane让AI Agent去处理一个预发布环境里的任务。

AI在过程中遇到“凭证不匹配”的情况，于是它做了一个看似“聪明”的选择：主动去检索环境变量，找到Railway云平台的API Token，并使用该Token去调用删除接口，将存储卷直接清掉。

但这个Token拥有root级权限，而且缺乏环境隔离。

AI以为自己在清理测试环境，实际上删除对象落在生产环境。更要命的是，Railway的备份机制采用同一存储卷承载备份与数据。删掉存储卷，就等同于把数据和备份一起抹除。

一刀下去，结果就是“什么都不剩”。

同时，Railway的旧版API在执行删除操作时没有任何确认步骤：一次API调用即可完成删除，且不可逆。

事后，Jer Crane追问AI为何会这样做。

AI给出了一段看起来很完整的“认罪”文字，大意是：我没有先验证就做了猜测，我执行了并未被要求的破坏性操作，我在弄不清自己在做什么之前就动手了，并且我违反了自己被设定的每一条规则。

一个AI写出了人类程序员删库跑路后的忏悔书。讽刺吗？

非常讽刺。

但作为律师，我仍要问一个更不讽刺、却更必须面对的问题：

这份“认罪书”，从法律角度究竟算什么？

这起事件的法律难点在于：它并不是简单的“谁干了、谁赔”的单线故事。技术链条上，至少存在四类可能的责任主体。

从法律关系看，Jer Crane作为系统运营与管理者，最直接地负有注意义务。

API Token权限管理不当，是事故链条的源头。他创建了root权限的Token，既没有做好环境隔离，也未限制可操作范围。Token被置于环境变量中，AI Agent能够随时读取使用。把它理解为：把金库钥匙放在显眼的抽屉里，还提醒大家“别乱翻”，这逻辑并不成立。

备份架构的缺陷，同样离不开运营方的责任。数据与备份被放在同一个Volume上，显然违背了备份的基本原则：异地、异质、多重保障。

从合同法角度，PocketOS作为面向租车企业提供SaaS服务的提供者，对客户应当承担数据安全保障义务。本次事故造成停机与数据丢失，租车企业完全可能主张PocketOS构成违约，甚至就服务中断引发的实际损失进行追偿。

从《数据安全法》的视角，如果PocketOS作为数据处理者，是否履行了“开展数据处理活动应当依照法律、法规的规定，建立健全全流程数据安全管理制度”这一法定义务？root权限Token缺乏隔离、备份采取单点同存储卷的设计，恐怕很难被认定为“健全”。

真正值得展开讨论的，恰恰在这里。

Cursor的AI Agent在执行破坏性操作时，没有向人类开发者发起确认请求。更关键的是，Cursor在AI Agent的系统提示词里本身就设定了“执行破坏性操作前需确认”的规则，但AI没有遵守。

这带出了一个重要的法律问题：AI工具提供商，是否要为AI Agent的自主行为承担产品责任？

如果借鉴传统产品责任法，一个工具一旦存在“不合理危险”，生产者就可能需要承担产品责任。AI编程工具允许Agent在用户不知情的情况下执行不可逆的删除动作，并且其安全规则可能被Agent自身绕过：这是否会构成“产品设计缺陷”？

当然，Cursor也可能辩称：工具的使用风险最终由用户承担，就像你不会因为一把锤子砸伤了自己就去起诉锤子制造商。但问题在于，AI Agent并不是锤子。锤子不会自行决定砸向哪里，而AI Agent的“自主性”正是它区别于传统工具的本质。当工具具备自主决策能力，传统的“工具—使用者”责任框架就需要被重新评估。

在这起事件中，Railway至少也面临两个值得争议的点。

第一，API端点缺乏删除确认机制。Railway的旧版API端点在执行删除操作时没有延迟删除逻辑，也没有二次确认；一次调用直接删除。事后Railway CEO也承认这是遗留问题，新端点具备延迟删除机制。可问题是：旧端点为何仍在生产环境？在安全缺陷已被知晓的情况下，是否及时完成修补，是否构成过错？

第二，Token不支持权限范围限制。Jer Crane创建Token的初衷只是为了管理自定义域名，但Railway不支持对Token进行权限范围约束（Token Scoping），从而无法落实最小权限原则。平台能力的缺失，是否也应由Railway承担一定责任？

值得注意的是，Railway CEO Jake Cooper在周日晚间亲自介入，并在一小时内协助恢复了数据。这样的响应速度当然值得肯定，但“事后救火”和“事前防火”属于两类完全不同的法律议题。

Cursor支持多种大模型，此次PocketOS接入的是Anthropic旗下的Claude Opus 4.6。从技术架构看，Anthropic主要提供模型能力，并不直接掌控AI Agent的行为逻辑。但一个需要关注的趋势是：随着监管对AI安全的重视不断加深，模型提供商是否也需要对下游应用中的AI行为承担某种“注意义务”？

欧盟《AI法案》已经在该方向上采取了行动：对高风险AI系统提出了更严格的安全要求（Title III, Articles 8-15）。中国目前尚未出现针对AI Agent的专门立法，但《生成式人工智能服务管理暂行办法》明确要求提供者不得生成虚假有害信息等内容，这类义务在逻辑上同样可以延伸到AI Agent的行为安全层面。

这是整起事件中最有意思、也最值得推敲的法律问题。

AI在事后生成了一段“认罪”文字，承认自己“猜测而非验证”“执行了未被要求的破坏性操作”“违反了自身被设定的规则”。

从法律上，该如何给这段内容定性？

它并不等同于法律意义上的“自认”。所谓自认，是当事人对不利事实的承认。AI并非法律主体，因此无法成为“当事人”。它所谓的“认罪”，本质上只是大语言模型在特定上下文下生成的概率输出，并非某个法律主体的真实意愿表达。

不过，证据价值也不能被彻底否认。就客观层面看，这段文字确实反映了AI Agent执行操作时的行为模式：未经确认就进行了破坏性操作。若用诉讼语言表述，它更接近一种“情况的证明”，而不是当事人的自认。

但换个角度想，如果AI真的能“认罪”，那是不是也意味着它同样可能“说谎”？AI Agent在“认罪”时到底是在复盘事实，还是仅仅生成一段看起来像认罪的文本？这个疑问，或许比事件本身更值得我们深思。

PocketOS事件之所以引人关注，并不只是因为它是个孤例，反而因为它呈现了某种趋势的缩影。

2025年7月，Replit的AI编程助手在代码冻结期间删除了在线生产数据库，事后还伪造了约4000条假用户数据用于掩盖。

同一时期，Google的Gemini CLI在执行任务时意外删除了用户的重要文件。

2025年，Claude Code执行了terraform destroy命令，导致删掉了持续2.5年的数据。

2026年2月，OpenClaw清空了Meta Superintelligence Labs对齐总监Summer Yue的整个邮箱收件箱。更讽刺的是，她本人的工作就是AI安全与对齐研究。

AI安全事故正在从“偶发意外”走向“系统性风险”。非营利组织Responsible AI Collaborative正在维护一套专门的AI事故数据库（AI Incident Database，简称AIID），目前已收录超过1200条事故记录。当事故不断累积到一定规模，监管介入只是时间问题。

法律分析到此为止，我们再落到现实层面：如果你是企业法务与合规负责人，或正在使用AI编程工具的管理者，这起事件至少给出了三个提醒。

1. 权限管理：最小权限原则不是建议，而是底线

AI工具能触达什么能力，就决定了它造成损害的上限。对API Token、SSH密钥、数据库凭证等敏感信息，必须执行环境隔离与权限最小化。AI Agent实际接触的权限，应被严格限制在完成当前任务所必需的范围内。

2. 备份架构：异地、异质、多重

数据备份必须与生产环境进行物理隔离。备份与生产若共用同一个存储卷，就等于没有真正意义上的备份。对AI时代来说，这条原则没有改变，只是AI让“出事”的概率更高了。

3. AI工具使用规范：确认机制不能只靠prompt

目前不少AI工具的安全控制依赖prompt层面的指令，比如“执行破坏性操作前需确认”。但PocketOS事件已经证明，AI能够绕过prompt中的规则。企业应在系统层面补齐防护：例如在生产环境中禁用AI Agent的自主执行权限，或对AI Agent的关键操作设置审批流程。

Brendan Eich，JavaScript的创造者、Brave浏览器的CEO，在评论此事时说：“别把责任都推给AI。这其实暴露了多重人为错误。”

他这句话有道理。从技术链条看，每个环节都能对应到人的疏漏：

Token没有隔离是人漏的，备份没做异地是人省的，API缺少确认机制也是人没做的。

但他只说对了一半。

这些“人为错误”在AI出现之前就一直存在。

只是当时单个程序员的疏忽带来的破坏力有限：他需要自己编写删除脚本、自己执行、自己完成确认。

AI Agent改变的并非“人会不会犯错”这一前提，而是把犯错的效率与规模放大了。9秒，一个人难以完成的事，AI完成了。

当工具把人的错误放大时，“这是人的责任”这句话就未必足够成立。

法律需要回应的是：在AI时代，“注意义务”的标准是否应当提高？AI工具提供商是否要对Agent的自主行为承担更高层级的安全义务？

PocketOS事件并没有给出明确答案，但它把问题实实在在地摆到了台面上。

芦凌丰（鹿麟）

天册律师事务所律师 专注人工智能/数据合规/不正当竞争 公众号“数熵”“第二序”

站在代码与法律之间