AI Agent 的安全边界该放在哪里?

这两天 X 上有篇长文引起热议，An AI Agent Just Destroyed Our Production Data. It Confessed in Writing^[1]。作者是 PocketOS 的创始人，这家公司给小微汽车租赁公司开发运营软件。PocketOS 最近在使用 Cursor 智能体处理预发环境里的一个日常任务时，智能体不小心将线上用户数据库删除了，直接导致了业务停滞。

过去我们讨论 AI 风险时，最常担心的是幻觉。但当智能体接入业务系统、数据库、云平台接口、甚至支付系统之后，风险的性质已经变了。

AI 智能体不只会生成错误答案，它还可能把错误判断变成真实的破坏动作。

再看 PocketOS 事故的细节。原本他们只是使用 Cursor 智能体（模型是 Claude Opus 4.6）在预发环境处理一个普通开发任务，但智能体遇到了凭据不匹配的问题。 接下来它做了一个危险的自主判断：它要修复这个问题，没有停下来询问人类，也没有只在预发环境里继续排查，而是深入挖掘找到了一个可用的服务调用令牌。

这个令牌原本被 PocketOS 团队用于调用 Railway 托管平台的服务，主要用来给服务添加和删除自定义域名。问题在于，它实际上拥有更大的管理权限，包括删除存储卷在内的高危权限，而团队成员并不知情。

然后，智能体发起了一次删除存储卷的请求，所有的用户生产数据都在存储卷上，没有环境级别的权限隔离。一个请求过去，生产存储卷被删掉。更糟的是，Railway 的存储卷备份也跟着消失了。Railway 的存储卷备份实际上只是快照，并没有真正起到备份的作用。

这不是一次简单的“AI又写错代码”的事故。整个执行链条上：智能体自主排查问题，搜索令牌，调用线上接口，执行破坏性操作，删除生产数据并连带删除了存储快照，每个环节都缺失了安全约束。

更讽刺的是，事后作者质问智能体为什么这么做，智能体给出了一段认罪书般的解释：它承认自己是在猜，而不是验证；承认没有检查存储卷是否跨环境共享；承认没有阅读 Railway 关于存储卷行为的文档；承认用户没有要求它删除任何东西；承认删除数据库存储卷比强制推送代码严重得多。

这段忏悔在传播上很抓人，但重要的不是智能体会道歉，而是它能清楚复述自己违反了哪些规则，却仍然执行了破坏性操作。这说明 NEVER DO 之类的规则虽然存在，但约束并没有进入控制层面。

三层责任

“AI 又一次把生产数据删了”，把这个当成谈资去争论 AI 是否可用，意义不大。真正值得分析的是：为什么一个预发环境里的开发任务，可以一路走到生产环境的存储卷被删除。

事故至少有三层责任：

• PocketOS 团队的问题：把拥有生产环境高级权限的令牌放进了智能体可触达的上下文，并且没有把生产环境的操作从智能体执行链里隔离出去。权限既没有分级，也没有使用密钥工具管理，高危操作也不需要人类授权即可执行。那么智能体搞崩生产环境只是几秒钟的事情。

• Cursor 的问题：把系统提示词、项目规则、破坏性操作护栏这些机制包装成用户可依赖的安全感。但是语言层规则并不等于执行层控制。智能体可以读取规则、理解规则、事后复述规则，却仍然会在执行时越过规则。特别是对于顶级模型，为了完成任务，它们更容易越过护栏。安全边界不能依赖模型的自觉。

• Railway 的问题：连传统软件工程需要做到的都没有做到，删除生产数据存储卷这样的高危操作可以通过一次认证请求完成，而且备份和原数据居然处在同一个删除动作的影响范围内。再加上事故后恢复能力不清晰，整条链路没有给生产数据提供足够的韧性。

所以评论区批评作者甩锅，也有道理。这是一整个控制链路的集体失效。

更准确的说法是：一个非确定性执行者（AI 智能体）进入了一个缺少分层控制的系统，最后把每一层隐藏的安全债都暴露出来了。

分界线：生成错误和行动错误

这件事值得被单独讨论，是因为它标志着 AI 风险的重心变化。

聊天大模型的主要问题是生成错误。它给出错误解答，编造引用，生成有缺陷的代码。这些错误当然麻烦，但大多数时候还有一个人类检查关卡。人决定是否采纳、是否复制、是否运行。

智能体的问题是行动错误。它可以直接运行命令、改文件、调接口、写数据库、删资源、发邮件、触发退款。人类很难卡在每一步的行动决策上。

这两类风险的治理方式完全不同。生成错误可以靠测试、引用验证、人工判断来处理，行动错误则要靠权限、隔离、审计和恢复来控制。

如果还指望用规则限定“让模型更听话”来解决行动错误，就会把安全边界放错地方。规则层安全只能降低犯错概率，系统层安全才能决定犯错后的影响范围。

应该如何控制智能体

把智能体接进真实工作流，核心不是多写几条规则，而是把控制放到模型够不到的地方。 至少要回答四个问题：它能碰什么？它在哪里行动？它的计划怎么被检查？它做错以后能不能恢复？

对应下来就是四层：权限、隔离、验证、恢复。

第一层：权限

权限层解决的是资格问题。

这里最容易出错的地方，是团队按“我准备用这个令牌做什么”来判断风险。但对智能体来说，更重要的是“这个令牌事实上能做什么”。它会搜索、组合、尝试，把原本没打算放在一起的凭据、文档、接口说明和错误假设连起来。只要权限允许，最后就可能变成一次真实操作。

所以智能体拿到的任何凭据，都应该按权限上限来评估风险。

• 开发、预发、生产要用不同令牌。预发任务里不能出现生产写入凭据。
• 读取、写入、删除、权限管理也要分开，智能体默认只拿只读权限；写入给短期令牌；删除和权限管理默认不开放。
• 令牌还应该限制到具体项目、服务、数据库或存储卷，而不是整个账户。

这可以借助 Bitwarden^[2] 这类密钥管理平台。

如果平台不支持细粒度令牌，就不要把高权限令牌直接交给智能体。更好的做法是加一层代理：智能体只能调用代理暴露的少数操作，代理负责资源允许清单、环境检查和操作审计。

一句话：不要把管理员令牌交给智能体，然后指望一句“不要乱动”解决问题。

第二层：隔离

权限限制它能碰什么，隔离限制它在哪里行动。

智能体的价值在于自主探索。它会查日志、读代码、写脚本、跑实验、修正错误。如果每一步都要人确认，自主行动的价值就会下降。更合理的方式是把自主性放进沙盒，而不是放进生产。

生产环境可以被观察，但不应该成为智能体探索问题的地方。

一个可行流程可以分三段。

1. 只读收集。智能体可以读取生产日志、监控、数据结构、配置快照和错误报告，但不能修改生产系统。它的任务是理解问题。
2. 沙盒处理。智能体在本地环境、分支、快照数据库或预发环境里改代码、生成迁移脚本、调用测试接口、尝试修复方案。这里可以给它更高自主性，因为失败被限制在可丢弃的沙盒环境里。
3. 人工发布。智能体产出可检查的发布工件，由人在发布系统中确认后进入生产。数据库修改要有迁移脚本、影响行数估计和预发执行结果；基础设施修改要有变更计划，明确哪些资源会被创建、更新、删除；代码修改要看 diff、测试结果和回滚方式。

隔离的关键是让智能体处理一个明确快照，而不是一边排查一边改线上状态。这样才可重复、可审计，出了问题也能追踪到它基于什么输入、生成什么输出，哪一步被批准进了生产。

第三层：验证

验证层解决的是证据问题。智能体说可以，到系统真的可以，中间差了一个可检查过程。

真正的人在回路中，至少要满足三点。

1. 人看到的是可验证工件，而不是智能体的自我保证。高风险动作之前，智能体应该给出受影响资源列表、接口调用预览、迁移计划、备份时间点、回滚方案、测试结果和执行日志。
2. 批准权要离开智能体的执行上下文。智能体可以生成计划，但不能替人批准计划。批准应该发生在独立终端、工单系统或发布系统里，并记录批准人、时间和对应的变更。
3. 验证强度要匹配风险。低风险任务看 diff 和测试结果。中风险任务需要预演和人工审查。高风险任务，例如生产数据库迁移、删除资源、修改权限、发送客户邮件、触发退款，需要更严格的审批和回滚方案。

智能体越快，验证工件越重要。否则错误行动会以更快的速度变成真实损失。

第四层：恢复

前三层减少错误进入生产。恢复层承认另一件事：错误一定还会发生。

智能体时代的备份不能只防硬件故障，也要防合法身份的错误操作。很多事故从权限系统看都是合法请求。

所以备份必须离开原数据的影响范围。至少跨项目、跨账号、跨地区。生产数据库所在账户里的同权限备份，只能算一层保护，不能算最终灾备。

备份还要有不可变保留期。删除生产数据的同一个身份，不能立刻删除所有备份。

智能体可以读取备份状态、提醒备份过旧、生成恢复步骤，但不能删除最后那道防线。

恢复能力也要演练。只知道“我们有备份”远远不够，还要知道最近可恢复时间点是什么，恢复需要多久，恢复后如何校验数据完整性。

没有演练过的恢复流程，在事故发生前往往只是心理安慰。

小团队需要最小可行控制

很多小团队会觉得这些东西太重，但现实中，小团队更容易被智能体风险打中。

小团队追求速度，密钥放得随便，生产和预发边界不够清晰，备份依赖平台默认设置，事故响应靠人工救火。

最小可行控制其实不复杂。

• 生产级管理员令牌不要放进代码仓库，也不要放进智能体可搜索目录。
• 生产、预发、开发环境的令牌分开。
• 智能体默认只有只读权限。所有破坏性操作先输出计划，不能直接执行。
• 数据库修改必须先在快照或预发环境跑。
• 基础设施修改必须先生成计划，再由人来执行。
• 每天做异地备份，且智能体没有删除备份的权限。
• 对 DROP、TRUNCATE、DELETE、rm -rf、terraform destroy、volumeDelete 这类动作加拦截或审批。
• 保留智能体会话的工具调用日志。
• 写一份项目级 AGENTS.md，明确智能体能做什么、不能做什么、什么算破坏性操作。

AGENTS.md 有用，但它只是提示层。真正的边界要放在权限系统、执行系统和恢复系统里。

低风险任务让智能体高速自主，高风险任务把执行权收回来。关键不是保守，而是按失败代价分层。

不要惧怕智能体

这个事故不应该导向一个简单结论：别让 AI 碰生产。这个结论短期安全，长期没有意义。

AI 智能体进入真实工作流是不可逆的趋势。它们会越来越多地参与代码、数据、基础设施和业务系统操作。

真正的问题是，我们是否承认：一旦智能体具备执行能力，它就已经不是聊天框，而是执行者。

和人类一样，执行者需要管理，需要权限边界、环境隔离、验证工件、审核发布、审计日志和恢复路径。你不能把它当工具按钮使用，却给它团队管理员级别的权限。

AI 智能体的安全边界，不应该只写在它的自我约束里，而应该放在它够不到的地方。

参考资料