企业 AI Agent 安全接入 AWS 的四层防线

企业部署 Agent 工具失败的原因不在于工具本身不够强大——而在于他们要么交出了全部权限，要么把所有东西都锁死。前四篇文章给你提供了另一种选择：

我实际会使用的部署顺序

首先建立沙盒环境。 一个专属的成员账户或 OU，理想情况下不包含生产数据。在调整任何配置之前，先把 Agent 从共享账户中移出来。

消灭长期密钥。 全面使用 SSO，在 Agent 角色的信任策略中要求 source identity，并限制会话时长。验证凭证提供商能够刷新。

给 fleet 打标签（第二篇）。Claude Code 用托管设置，Codex 用托管配置，其他地方用 OS 级备选方案。在信任之前，用一条 CloudTrail 查询确认带标签的调用已经正确落地。

挂载 SCP（第三篇）——等沙盒基线建立之后再操作。预期会有影响，记录每一个你授予的异常，并记住每个异常也是一条继承路径。

在开放给用户之前接入检测层（第四篇）：从 CloudTrail 到 Athena 的路径、至少一条你实际运行过的仪表板查询、GuardDuty，以及一个预算告警。

然后向一个小队开放一个工具，观察一周安静的日志。谨慎地扩大范围；廉价层的核心价值在于让你能够负担得起迭代。

这不能解决什么

这些层限制了 Agent 对 AWS 的操作范围，但它们无法控制机器的其他部分。文件系统隔离、网络出口、MCP 工具白名单，以及决定什么内容可以通过 prompt 离开宿主，仍然至关重要。一旦 Agent 已经读取了密钥，AWS 权限就无法保护它——这里也没有任何东西能把被污染的上下文变成安全的。第三层限制了它的范围；但对于变更操作的人类审批仍然是你最强的控制手段。

第二层的诚实总结也需要在这里说一下：UA 标签是遥测数据。第二篇的实验精确展示了基于标签的条件控制能达到什么效果——只差一个环境变量就能被绕过。

这一切的意义

这些都不是重量级的沙盒隔离，也都不需要远程浏览器。这是一组轻量级的防护层，让你的 Agent 能够真正像 Agent 一样工作——在限定范围内读取、诊断、建议、修复——同时即使某个工程师做了欠考虑的操作，账户也能保持安全。

你不必在"Agent 毫无用处"和"Agent 完全接管账户"之间二选一。有了合适的轻量级防护层，你既能获得能够自主排查问题的 Agent，又能在它们出错时限制影响范围。

完整系列：part 1（威胁模型与身份）、part 2（UA 标签）、part 3（SCP 兜底）、part 4（检测）。第三篇中引用的完整 SCP 策略见 gabrielkoo.com/devto/ai-agents-aws-sandbox/agent-sandbox-scp.json。