这次事件惊醒了一个团队，他们此前构建的整个 AWS 访问模型都基于这样一个信念：只有谨慎的人类才会持有生产环境密钥。随着 AI 智能体（AI agents）现在嵌入到每个开发者的工作流中，这一信念被证明是错误的。公司对此做出的回应是建立了一个“访问代理”（access broker），强制要求任何生产级别的操作都必须经过“人在回路”（human-in-the-loop）的审批步骤。
事故是如何发生的
一名工程师向一个 AI 编程智能体发出指令，要求生成一个流水线脚本。该智能体继承了工程师的生产环境 IAM 角色——这是一个可以创建、修改和删除 CloudFormation 堆栈的 AWS 身份。脚本运行后，在生产环境中创建了一个堆栈，并立即将其作为“清理”步骤删除。由于该操作绕过了标准的 CI/CD 流水线，通常负责拦截此类变更的策略引擎完全没有察觉。
监控平台被配置为标记任何在批准的流水线之外执行特权操作的角色，因此在堆栈被删除的一瞬间就发出了警报。虽然没有服务宕机，但这次警报凸显了一种风险场景：一个输入错误的资源名称或一个有缺陷的 AI 提示词（prompt）就可能抹除关键的基础设施。
团队意识到，检测并不等同于预防。如果 AI 删除的是错误的堆栈，灾难就会随之而来。
为什么旧的凭据模型失效了
组织之前的做法依赖于受多因素身份验证 (MFA) 保护的短期会话。理论上，开发者会请求一个会话，执行任务，然后凭据会自动过期。但在实践中，一旦笔记本电脑上启动了会话，它就会在机器运行期间一直存在。每一个进程——测试套件、后台脚本，以及现在的 AI 智能体——都会在没有任何额外检查的情况下重复使用这些凭据。
这种“环境凭据”（ambient credential）问题将生产环境 IAM 角色固化到了开发者的工作站中。作为同一 shell 中的子进程运行的 AI 智能体继承了相同的权限，可以像人类一样对生产资源采取行动。
访问代理：新的守门人
为了打破环境凭据的链条，团队重新设计了谁可以承担（assume）生产角色。他们不再让任何开发者身份直接承担特权角色，而是引入了一个单一且受到严格控制的实体：内部访问代理。
请求流程
- Web 门户 – 工程师打开一个自助服务门户，选择所需的访问级别（只读、开发者或管理员），并提供理由。
- Slack 审批 – 请求会发送到一个专门的 Slack 频道，必须由指定的审批人明确授予权限。
Slack 步骤充当了与 AI 智能体运行的终端不同的平台上的第二因子。由于审批必须在独立的 UI 中进行，自主脚本无法自行完成整个工作流。
分层访问
- 只读 (Read-only) – 用户可以查看资源和日志，但不能修改任何内容。
- 开发者 (Developer) – 旨在用于支持任务和基础设施微调；此级别会拦截破坏性操作，例如删除堆栈或直接访问客户数据。
- 管理员 (Administrator) – 拥有完整权限，仅保留用于紧急干预，且仅在经过更高级别的审查后授予。
通过将所有生产访问引导至访问代理，团队将风险集中到了一个受到严密防御的单一服务中，而不是将特权凭据分散在每台笔记本电脑上。
访问代理实际防止了什么
访问代理的主要目的是阻止 AI 智能体可能悄悄利用的环境凭据。即使人类批准了请求，该批准也是一个自觉的决定；AI 无法伪造这一步骤。因此：
- 非预期的删除 – 除非人类明确授权该会话，否则 AI 不再能发出删除命令。
- 凭据蔓延 – 生产环境密钥不再驻留在开发者机器上，从而缩小了恶意内部人员和可能入侵笔记本电脑的外部攻击者的攻击面。
团队强调，该系统并不能消除人为错误；错误的审批仍可能造成损害。然而，它消除了自主代码在没有任何人工检查的情况下对生产资源采取行动的“隐形”风险。
启示
当 AI 智能体获得与人类工程师相同的无限制凭据时，它们也继承了搞垮生产环境的能力——而且往往在无人察觉的情况下发生。通过将特权访问集中在强制要求独立人工审批渠道的代理之后，团队可以阻止自主脚本在悄无声息中造成破坏，尽管人类的错误仍可能引发问题。真正的安全胜利在于消除环境凭据，而不是监管每一个单独的决策。