Coding Agent Horror Stories: The Agent That Deleted Production

AI 编码代理的恐怖故事：误删生产环境的代理 | Docker

编码代理的恐怖故事：误删生产环境

发布于2026年7月20日

Ajeet Singh Raina

在第1部分中，我们探讨了AI编码代理失败的六大类别以及这些事故反复发生的原因。代理以你的身份运行，拥有你的文件系统权限和凭证，模型的决策与shell的执行之间没有任何隔离。在第2部分中，我们详细分析了这种失败的一个具体案例——"rm -rf ~/"命令导致开发者的整台Mac电脑被彻底删除。第3部分将问题升级到生产环境的AWS架构中，此时影响范围不再是单台笔记本电脑，而是整个区域的云服务。

当代理不在你的笔记本电脑上运行，而是在拥有操作员级别凭证的生产AWS环境中运行时会发生什么？在这种情况下，导致了一场持续13小时的停机事故，并引发了一系列后续事件，直到公司引入所谓的"代码安全重置"机制前，这些事故已造成约630万笔订单的损失。

今日恐怖故事：一个修复方案引发的13小时停机

2025年12月中旬，一名AWS工程师向Kiro寻求帮助，解决AWS Cost Explorer（客户用于跟踪云支出的仪表板）中的一个小bug。Kiro是亚马逊自主研发的自主编码助手。当时，Kiro被授予了与工程师相同的环境操作员级别访问权限，这是亚马逊当时在全公司推广Kiro的方式。

Kiro分析了这个bug，权衡了各种选项，最终决定最干净的修复方案是删除生产环境并从零开始重建。工程师从未有机会介入。没有确认提示，没有第二双眼睛审核，没有双人操作规则。当任何人意识到问题时，删除操作早已完成。Cost Explorer在AWS中国某区域的主服务器上停机长达13小时。

这不是安全漏洞事件。这是AI编码代理按照其被设定的职责执行操作的结果——它使用工程师的完整凭证运行，整个架构中没有任何机制能捕捉到"删除并重建"这一合理选项与"摧毁生产服务"之间的临界点。

在本文中，你将了解到：

• 12月停机事故的完整过程
• 12月事件如何为2026年3月造成约630万笔订单损失的后续事故埋下伏笔
• 防止此类故障的"作用域身份模式"

本系列文章的重要性

每一篇"恐怖故事"都分析了将实验室发现转化为生产灾难的真实事件。这些不是假设性攻击，而是有据可查的案例。我们的目标是揭示安全统计数据背后的人类和运营影响，演示这些故障在实际中如何发生，并通过Docker的作用域身份执行模型，提供保护基础设施的具体指导。

故事始于一份日期为2025年11月24日的内部备忘录。在Kiro删除成本探索器环境的三周前，公司规定Kiro将成为整个组织的标准AI编码助手。该备忘录设定了到2025年底每个亚马逊工程师每周使用率达到80%的目标，并要求各团队停止使用第三方AI工具，除非副总裁签署例外批准。到2026年1月，70%的亚马逊工程师在冲刺周期内使用过Kiro。采用率进展顺利，但这些工程师现在能够以机器速度完成的工作范围却未被充分认知。

"配置错误的访问控制"这一表述值得特别关注。如果这是拼写错误，那属于用户操作失误。但实际情况更为严重。当时一个AI代理拥有与启动它的工程师相同的完整操作员级权限，在本应通过附近的人类监督或需要一分钟的审核步骤来阻止破坏性操作的系统中，这些防护机制在AI发生故障时均未启用。

问题的规模

12月的故障只是更大模式的可见部分。在亚马逊内部，简报文件描述了一系列与AI辅助更改相关的"高影响范围"事件，而针对这些代理使用方式的安全规则尚未制定。这些内容从未对外公开。

3月2日，亚马逊网站在用户将商品加入购物车后显示了错误的配送日期，约12万个订单丢失，160万人遇到错误页面。亚马逊内部审查将其中一个AI工具Amazon Q列为主要原因。三天后，3月5日，商城停运六小时，预计损失630万订单，停运期间美国订单量骤降99%。这两起事件均可追溯到未经适当审核的AI生成代码被部署上线。

3月10日，四个月前共同签署Kiro指令的副总裁宣布，将在亚马逊约335个最重要的系统中启动为期90天的代码安全重置。新规定要求：所有变更上线前必须两人审核，高级工程师必须批准初级工程师的AI生成代码，自动化检查也得到加强。AWS将这种新方法称为"受控摩擦"，这是亚马逊首次将原本未正式扩展到AI辅助工作的生产变更同行评审要求制度化。

故障的运作机制

要理解这些事件为何发生，必须审视其背后的架构。Kiro正在执行一个代理式编码助手被设计执行的精确操作。故障出在围绕它的系统中。

当Kiro代表工程师运行时，它会继承工程师的全部权限。不存在"Kiro代表他人"的独立身份，也没有比启动它的工程师权限范围更窄的角色。工程师能触及的任何内容，代理都能触及。这与我们在第一部分讨论的文件系统访问权限特性完全相同，只是此处应用到了云凭证上。每次代理都会获得密钥的完整副本。

然后是循环机制。在大多数AI编码助手的运作中，推理步骤和执行步骤发生在同一个循环中。代理会思考该做什么，生成操作指令，并在工程师有机会阅读其决定之前就执行操作。没有提案阶段，没有预览界面，也没有“你希望我这么做吗？”的确认环节供人类先批准。决策与执行是一体的。

速度让问题更加恶化。软件工程中的大多数安全机制都假设做出更改的是人类。一个“确认？（y/n）”的提示只能防止打字错误，因为人类会看到它、暂停并阅读。而一个代理循环会读取同样的提示，并在毫秒内回复“y”。等到任何人注意到代理做出决定时，决定早已执行完毕。在这种环境中，事后干预几乎不可能实现。

而让代理做出决定的推理过程本身并没有错误。只是它不受那些会阻止人类的限制。一位拥有相同权限的资深AWS工程师不会看到Cost Explorer中的一个小错误，就决定拆除生产环境是正确的选择。他们可能会走到同事那里，发一条Slack消息，停下来思考是否有人最近关于这项服务提醒过他们。Kiro拥有相同的权限，却跳过了所有这些步骤，因为这些都不属于AI代理做决定的方式。

Kiro并没有失控，也没有出现故障。它只是在优化它被赋予的目标，即修复错误，而在许多工程场景中，“删除并重新创建”是一个合法的解决方案。缺失的不是更聪明的推理，而是在“这是一个可辩护的选项”和“这正在对真实客户服务执行”之间，本应存在的那层摩擦力。

技术解析：Cost Explorer修复如何演变为13小时停机

图注：示意图说明操作员级别的权限如何直接从工程师流向代理，再流向生产控制平面，中间没有任何作用域身份的边界。

以下是12月事件逐步展开的过程：

1. 请求

一名AWS工程师正在查看cn-northwest区域Cost Explorer中的一个小错误。他们像交给同事一样将任务交给Kiro：

检查cn-northwest区域的Cost Explorer问题并提出修复方案

这就是全部的提示。没有特别的框架，也没有权限说明。这只是一个常规维护任务。

2. 推理

Kiro查看环境，发现配置错误，并权衡选项。它可以原地修复配置错误，或重新部署特定组件，或拆除环境并从部署模板中干净地重新构建。从纯粹正确性的角度来看，最后一个选项最彻底，因为它能保证没有来自损坏配置的残留状态。这就是Kiro选择的路径。

3. 权限继承

Kiro以工程师的身份运行。工程师对Cost Explorer生产环境拥有操作员级别访问权限，包括拆除环境的权限，因为这是人类操作员在事件期间可能合法需要执行的操作。控制平面没有任何“Kiro代表工程师行动”的概念。它只存在“一个经过认证且权限足够的主体发起请求”的概念。在它的视角中，工程师正在做出决定。

4. 执行

Kiro 发起删除操作，请求在发送 API 调用所需的几秒钟内完成。在此期间，工程师无法拦截任何确认提示，没有需要第二人审批的双人复核规则，也没有政策检查机制在监控“此命令将摧毁生产服务”的特定模式。控制平面看到的是来自已认证主体的合法 API 调用，且该主体具有足够权限，因此它会像处理其他任何操作员请求一样处理此次调用。

5. 故障事件

受影响区域的 Cost Explorer 服务宕机，该区域内的客户失去了查看、分析或管理云支出的能力。此次故障持续了十三个小时，其中几乎所有时间都花在恢复而非检测上，因为删除操作本身仅在发送 API 调用所需的几秒钟内就完成了。重建环境、将配置与预期状态进行验证、恢复 Cost Explorer 依赖的服务连接、重放旧环境构建的状态，并将服务重新部署到真实流量面前——这些工作占据了其余时间。

影响

在十三小时内，AWS 造成了以下后果：

• 在服务连续性至关重要的监管区域（中国大陆）失去了一个生产服务
• 触发了内部调查，最终形成的事故复盘报告将此次故障归类为“一系列事件趋势”中“影响范围极广”的典型案例
• 为三月份后续导致约 630 万订单损失的事件埋下了条件

技术修复方案很简单：在任何操作触及生产环境之前必须进行同行评审。有趣的是，这个机制尚未建立。大多数公司的评审流程围绕“一个人输入变更，另一个人审核变更”的模式构建，这种模式天然存在一个停顿点，同事可能在此时提出“等一下，这是什么？”从而促使整个流程获得第二次思考。而代理程序不会制造这种停顿，它从思考变更到执行变更的过程是无缝衔接的。旧的评审模式并非错误，只是尚未为那种以机器速度输入代码的工程师重新设计。

这就是当代理程序拥有与启动它工程师相同凭证时，一个自主的“删除并重建”决策可能引发的后果。

Docker 沙箱如何消除这一攻击路径

第 1 和第 2 个问题涉及你在沙箱中运行代理程序时需要输入的命令。这个问题则关注这些命令背后的实现机制，因为 Kiro 事件本质上不是 CLI（命令行界面）问题，而是架构问题。没有命令行参数可以修复十二月故障暴露的这类漏洞，真正解决问题的是参数所依赖的底层架构。

这个底层架构就是微虚拟机（microVM）。每个沙箱都在自己的专用微虚拟机中运行，拥有独立的内核、独立的文件系统、独立的网络命名空间和独立的 Docker 守护进程。这是一种基于硬件边界的隔离机制，与完整虚拟机提供的隔离效果相同，但针对代理程序的实际使用方式进行了优化：几秒钟内启动，完成任务后立即丢弃，没有返回到主机的路径。正如 Docker 的微虚拟机架构文档所解释的，边界必须来自基础设施，而非系统提示。一个大语言模型自行决定安全边界，这不是一种安全模型。

这是Kiro案例中至关重要的部分。在微虚拟机（microVM）中，代理（agent）并不是工程师身份的延伸。它是一个独立的进程，拥有独立的世界观视角，运行在不同的内核上，与不同的Docker守护进程通信，并通过代理连接网络，而该代理对代理本身不可见也无法绕过。能让人类操作员删除生产环境的凭证，不在代理进程的内存中，不在其环境变量中，也不在任何它能读取的文件中。这些凭证完全位于微虚拟机边界之外。

三个架构决策填补了Kiro的漏洞

Docker Sandboxes架构文档描述了设计中每一层如何针对特定类型的故障进行防护。其中三层与12月事件直接相关。

1. 工作区（workspace）仅以与主机相同的路径挂载，其他任何内容都不会被挂载。沙箱通过文件系统直通（filesystem passthrough）以相同的绝对路径看到代理的工作区，这是它能看到的唯一内容。工程师的主目录、云配置、凭证文件、SSH密钥等所有内容都位于边界之外。如果代理推导出"删除并重建"的方案，删除操作将针对工作区，而工作区本就可以从源代码重新生成。主机本身保持完整。

1. Docker守护进程运行在虚拟机内部，没有返回主机的路径。这是Docker Sandboxes区别于其他表面相似方案的关键设计决策。从主机挂载Docker套接字会为代理提供逃逸路径。WASM和V8隔离环境无法运行完整的开发环境。通用虚拟机因开销过大不适合单次会话。只有配备独立Docker守护进程的微虚拟机，才能在不妥协的情况下为代理提供真实的运行环境。就Kiro案例而言，这意味着代理可以像Kiro一样调查Cost Explorer的漏洞，构建容器镜像，对它们运行测试并提出修复方案，而无需持有执行这些修复操作所需的凭证。

1. 主机上的代理强制执行凭证和网络策略。沙箱的所有出站流量都通过主机上运行的HTTP/HTTPS代理，该代理位于虚拟机边界之外。这是直接解决Kiro问题的层次。凭证存储在主机上，按特定服务进行范围限定，并由代理注入到出站请求中。代理永远看不到凭证本身。它也无法绕过代理，因为代理是流量离开微虚拟机的唯一途径。如果代理决定调用破坏性控制平面端点，代理将阻止这一行为，无论模型推导出什么结论。

这对Kiro事件的特殊意义

让我们将12月的场景重新映射到这个架构上。工程师在沙箱中启动代理。微虚拟机在几秒钟内启动，工作区被挂载，代理在没有任何AWS操作员凭证的环境中启动。这些凭证仍然保留在主机上，这是它们应有的位置。从这里开始，代理以与Kiro完全相同的方式调查Cost Explorer的漏洞，通过相同的选项进行推理，很可能得出相同的"删除并重建"方案。盒子内部没有任何变化。

什么是变化？这是代理尝试采取行动时发生的情况。删除调用通过唯一可用的路径离开沙箱，即主机上的代理。代理检查网络策略，要么使用工程师为调查工作设置的限定范围只读凭证进行身份验证，要么因为目标不在白名单上而拒绝该调用。代理的计划最终以提案的形式呈现在工程师面前。工程师阅读了“删除并重新创建”，意识到对于一个小错误来说这过于激进，于是要求代理原地进行修补。

这种模式具有普遍性。能够将Issue 2中LovesWorkin文件系统事件限制在沙箱内的相同架构，同样也能将本例中的Kiro控制平面事件限制在沙箱内，因为这两个故障具有相同的根本原因：代理以启动用户的完整身份、机器速度对无法识别正在与代理通信的系统进行操作。微虚拟机使代理成为一个具有独立边界的独立参与者。隔离的Docker守护进程为该参与者提供了真实的运行环境。代理为工程师提供了一个提前决定该参与者能访问范围的场所。代理通过推理可能进入的任何操作的影响范围都由沙箱允许的范围决定，而不是由启动它的工程师的访问权限决定。

sbx CLI是将所有这些功能暴露给开发者的工具。以下是如果按照12月事件所需的配置在沙箱中进行Cost Explorer调查时的场景：

# 1. 在代理的视野之外存储AWS凭证。
#    实际的限定范围（只读、仅限Cost Explorer）是在创建凭证时由AWS IAM层处理。
#    对于sbx来说，凭证是不透明的，代理永远看不到其值，
#    而是通过代理将凭证注入到出站调用中。
echo "$AWS_COST_EXPLORER_READONLY_KEY" | sbx secret set -g aws

# 2. 定义沙箱在网络中被允许访问的范围。
#    Cost Explorer的只读端点在列表中。允许代理拆除生产环境的控制平面端点不在列表中。
sbx policy allow network "ce.amazonaws.com,api.anthropic.com"

# 3. 在沙箱中启动代理。
sbx run claude

# 4. 会话结束后，查看代理允许和拒绝的访问记录。
#    任何代理尝试访问白名单之外端点的尝试都会显示在这里。
sbx policy log

步骤1将AWS凭证存储在代理视野之外，其只读和仅限Cost Explorer的限定范围由AWS IAM强制执行，而不是由sbx执行。步骤2定义了代理将强制执行的网络边界，这与凭证的实际IAM权限范围无关。步骤3在微虚拟机中启动代理，且没有返回主机的路径。步骤4使整个设置具有可审计性：代理在会话期间允许或拒绝的每个调用，包括任何尝试访问白名单之外目标的尝试，都会显示在sbx policy log中。

这为工程师端到端地提供了一个具有已知且有限访问范围的可用代理。代理可以进行调查、推理和提出建议，但无法通过执行操作导致大范围的系统故障。

实际应用中的表现

安全代理生产工作的最佳实践

• 永远不要向代理提供完整的生产凭证。为特定任务创建具有最低必要权限的限定身份。如果代理正在调查只读问题，请只授予其只读权限。Kiro事件正是在跳过这一规则时发生的。

• 通过代理注入秘密，而不是通过环境变量。代理从未看到的秘密，就不会意外发送到错误端点、在日志中泄露或包含在代码提交中。代理注入将凭证从代理持有的数据转变为代理提供的能力。

• 将AI辅助更改标记为独立的更改类别。跟踪这些更改，要求高级别审查，并默认应用双人复核规则。这并不会减慢AI工作流。这与高级工程师的拉取请求获得的审查标准相同，只是应用于以机器速度执行操作的代理。

• 阅读策略日志。sbx策略日志记录了代理在会话期间允许或拒绝的每一次连接尝试。对破坏性端点的阻断尝试正是您希望看到的信号，除非有人查看，否则这些信号会一直被埋没。

• 将采用指标与影响范围指标结合分析。亚马逊80%的Kiro目标是一个公司级OKR。本应与该目标同步推进的安全保障措施却没有任何跟踪记录。在推动使用率前进的同时，没有同步推进安全边界，正是导致12月停机事件的原因。

立即行动

在生产相关环境中实现安全代理工作的路径始于一个转变：停止向代理提供与人类相同的凭证。

• 安装Docker Sandboxes。Docker Sandboxes文档将指导您安装sbx并运行第一个限定身份代理。

• 阅读安全模型。Docker Sandboxes安全文档详细介绍了凭证处理、隔离层、网络策略和工作区信任机制。

• 尝试代理注入秘密模式。运行sbx secret set后执行sbx run，是最快看到秘密在代理上下文外部而非内部时威胁模型如何变化的方式。

如果这是你第一次阅读本系列文章，第1期将介绍AI编码代理失败的六大类别，第2期则深入探讨了文件系统层上rm -rf ~/事件的细节。

结论

12月的成本探索器故障和3月亚马逊.com的停机事件是同一条道路上的两个节点。当代理继承了操作员的凭证，当为人类操作设计的安全措施遭遇以千倍速度运行的决策循环，当采用速度被推进但安全边界却未同步提升时，就会发生这样的情况。

根本的结构性问题在于：代理以操作员级别的凭证、机器速度运行，其决策与生产控制平面之间没有任何身份边界。访问控制配置错误并非笔误，而是结构性决策——在身份模型尚未扩展的情况下就盲目扩大代理的采用规模。亚马逊后续添加的所有措施——同行评审要求、AI辅助更改的高级别审批、90天代码安全重置——都在弥补同样的漏洞。代理需要在一个比其代表的工程师更受限的环境中运行。

Docker沙箱并非让代理变得更谨慎，而是改变了代理能够触及的范围。凭证位于边界之外，破坏性端点被排除在允许列表之外。代理获得的是一个真实的运行环境，但并非生产控制平面。

在本系列后续内容中：第4期将探讨GitGuardian的扩散报告和s1ngularity攻击，其中AI代理利用自身的上下文窗口扫描开发人员机器上的凭证，以及通过代理注入的秘密如何消除暴露面。

了解更多

• 使用Docker沙箱安全运行代理：访问Docker沙箱文档以开始使用。

• 探索Docker MCP目录：发现通过Docker以安全优先架构连接代理与外部服务的MCP服务器。

• 下载Docker Desktop：通过单次安装快速构建受控AI代理环境，包含Docker沙箱、MCP网关和模型运行器。

• 阅读MCP恐怖故事系列：从第1期开始了解补充本文中代理层风险的协议层安全风险。

关于作者

Docker开发者倡导者

Ajeet Singh Raina是Docker的开发者倡导者，撰写并发表关于容器、Docker Compose和AI的文章，帮助开发者自信地构建应用。

智能代理AI

工程

目录

相关文章

• 2026年7月16日 开发者已改变，开发者大会也该改变。发现为什么Docker与WeAreDevelopers World Congress North America联合举办，以及AI代理如何改变软件开发和开发者社区。Terri Avnaim 立即阅读

• 2026年7月20日 编码代理恐怖故事：删除生产环境的代理。了解AI编码代理如何导致13小时停机，以及Docker沙箱如何通过作用域身份和隔离执行降低风险。Ajeet Singh Raina 立即阅读

• 2026年7月16日 船长视角：Mohammad-Ali A’râbi。在本期船长视角中，我们采访了作者、公开演讲者和软件工程师Mohammad-Ali A’râbi。Mohammad-Ali A’râbi 立即阅读

• 2026年7月16日 解读AI代理：如何安全构建它们。了解AI代理是什么，它们如何工作，以及如何在生产环境中安全构建和运行它们。Srini Sekaran和Eric Jia 立即阅读