企业级 AI 编程工具落地的威胁模型与身份困境

说实话，没人会在"为什么 AI 编程还没搞定我们公司"的主题演讲上讲这句话：个人体验确实非常好。Claude Code、Codex、OpenClaw——在单机上跑起来，生产力的提升是实打实的。一小时完成过去一天的活。

真正卡住的是企业 adoption。

不是因为工具不好用——而是在一个跑着正规 SDLC 的公司里，你没法早上九点一登录就让一个 agent 在接下来八小时里横冲直撞。另一个极端是传统的银行和 FSI 厂商，他们的应对是把一切都锁在远程浏览器或重型 VM 沙箱后面——能用，但 agentic tooling 的意义被阉割干净。Agent 变成了一个连不上你代码库、跑不了你测试、看不了你 infra 的高级浏览器。对自主排障毫无用处。

这个系列是写给安全团队或 AI 平台团队的——他们接到了那个需求：要给 agent 发放真正的账号访问权限，同时又不能把账号押在"模型表现完美"这个假设上。我会用五篇文章讲清楚四个廉价的防护层，让 agent 在真实的 AWS 账号里做有用的事，而不用把一切锁在远程浏览器后面，也不会交出整个王国的钥匙。这个系列全部在真实账号里测过——哪些是，我会标注。

这个系列不讲 agent harness、prompt engineering，或者怎么让模型更聪明。它讲的是防御：当同一个云身份可以被人类或机器使用时，安全和 infra 团队如何学会保护一个账号。这是一个真正的新问题。几十年来，principal 始终是一个人，IAM 唯一要区分的是权限级别——高级工程师对刚毕业的实习生。同一个物种，不同的权限。现在，同一次 API 调用的背后可能是你，也可能是一个以你身份运行的 agent，而传统 RBAC 对这个分野毫无概念。

有一条中间路线。它不是一颗银弹——而是一组廉价的防护层，让 agent 在真实云账号里做有用的事，而不用把账号押在"模型表现完美"这个假设上。

Layer 0 — 诚实面对威胁模型

技术之前，先把框架摆正。问题从来不是"我能信任这个 agent 吗？"而是"在我无法信任它的时候，这个 agent 能做什么？"

从云的角度看，开发笔记本上的 AI agent 就是一个极度亢奋的实习生，有键盘，有你的 AWS session。它不是恶意的——但也不谨慎。它会猜，会重试，会清理错东西。而且——关键的是——被污染的内容会试图让它做各种事。Prompt injection 进入 agentic CI 是一个真实的、不断扩大的攻击面：一旦 agent 有了写权限，一个精心构造的 README 或错误信息就是一次权限提升。

所以设计原则是：纵深防御，每一层都不被信任能单独救你。每一层阻止一种不同的失效模式，而且它们要足够便宜，让你真的愿意维护它们。

Layer 1 — 身份：别再发放长期密钥

最常见的错误和 AI agent 出现之前我们犯的一样，只是被加速了：一份长期有效的 aws_access_key_id 躺在 ~/.aws/credentials 里，团队共享，有效期几个月，还挂着 admin 权限。

AI agent 让这变成了灾难性单点故障——因为它会开心地把它 export 出来、粘贴到计划里、或者 base64 编码后塞进日志。你永远不会丢失一个你从未创建的密钥。

用 AWS IAM Identity Center（aws sso login）配合临时 session，而不是静态密钥。凭证在配置的 session 过期后就失效了。

给 agent 运行的 session 划定范围——理想情况是一个独立的 least-privilege 角色，而不是你自己的 admin 角色。

给 agent role 的最大 session 时长设上限。一小时足够完成一个工作 session，又足够短，让复制到主机上的 session 快速失效；不要因为上限是 12 小时就把它往上提。

给 agent 自己的 principal，而不是共享的人类角色。在 role 的信任策略里，允许 sts:SetSourceIdentity 并要求 assume 请求携带 sts:SourceIdentity。一旦 session 存在，下游请求会把它作为 aws:SourceIdentity 暴露出来，CloudTrail 也会记录。Session tags 是另一套：它们需要 sts:TagSession，而且只有标记为 transitive 的 tags 能在 role chaining 中存活。

如果开发者通过 AWS IAM Identity Center permission set 进入，让那个 SSO session assume 你控制的一个专用 agent role。生成的 permission-set role 不是构建自定义信任策略 machinery 的地方。第二次 assume 就是 role chaining，所以 agent session 被限制在一小时内；确保 credential provider 可以刷新它。

永远不要把真正的凭证放进 agent 能读取的 repo、CI 变量或 .env 文件。Agent 能读取机器上的所有内容，记住。

一个实现了 source-identity 功能的信任策略是这样的：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS":
        "arn:aws:iam::111122223333:role/DeveloperTeamRole"
    },
    "Action": ["sts:AssumeRole", "sts:SetSourceIdentity"],
    "Condition": {
      "StringLike": { "sts:SourceIdentity": "claude-code-*" }
    }
  }]
}

sts:SetSourceIdentity 必须在两边都允许——在信任策略里和执行 assume 的 principal 的权限策略里——否则 assume 调用会失败。而且 agent 自己的 wrapper 设置的 source identity，只有配合这个条件才有意义：信任策略才是让它有意义的东西。

这消除的是泄露长期密钥这类事故，不是凭证被盗。Agent 仍然可以把一个有效的 session 从主机上复制走。你获得的是一个简短的、可归因的爆炸窗口。如果需要切断 live session，用 IAM 的 Revoke active sessions 操作：它附加一个使用 aws:TokenIssueTime 的 AWSRevokeOlderSessions 内联策略。这是按 role 来的，所以 agent 需要自己的 role 也是一个原因——注意它只杀掉该时间戳之前颁发的 session，所以如果 assume 路径还活着，agent 会重新认证。撤销需要 iam:PutRolePolicy，移除撤销策略需要 iam:DeleteRolePolicy；第三篇里的 SCP 为那个受保护的 incident-response role 预留了这两个调用。

最安全又有用的模式是：为排障开放广泛的 metadata 读取权限，辅以严格范围的写权限。把涉及 secret 的读取挑出来——从 Secrets Manager 拉取 secret 值、解密 SSM 参数、KMS 解密、数据桶的对象读取——这些都不属于通用排障角色。Agent 读到的任何东西都可以留在它的模型上下文里离开账号。

不要止步于那些显而易见的读取 API。交互式 workload 访问在 workload role 能读取的情况下，同样可以间接访问到相同数据：启动 SSM shell 或发送命令、exec 进 ECS task、调用 Lambda 函数、向 instance 推送 SSH key、或者用 IAM 认证连接 RDS。每一项都需要一个明确的、资源范围的决定。在 agent role 的身份策略里默认拒绝 secret 读取和这些间接路径，然后只允许你真正打算让 agent 用的那些排障 workflow——这些决定属于 role，而不是账号级别的 SCP，除非这个沙箱账号里根本没有任何人需要那个能力。

下一篇：最便宜的一层——让每一次 agent 调用在 CloudTrail 里可见，以及如何通过 MDM 向整个集群推送那个 tag。