第 1 天授予的权限，到第 90 天也没人收回

你在第一天为 Agent 创建的 IAM 角色本应是临时性的。试点项目需要进度，团队需要 Agent 在演示前投入生产，而有人——大概就是你——在 PR 中加了一条评论：“发布后再收紧权限。”九十天后，试点项目已经上线，Agent 已经在为付费客户提供服务的生产环境中运行，而该角色仍然拥有对三个 Agent 从未接触过的存储桶的 write:* 权限。运维人员（On-call）无法告诉你这 18 个 Scope 中哪些是核心负载，哪些是冗余，因为唯一了解情况的人已经转岗，而能够证明区别的运行时遥测数据也从未接入。

这并不是关于一个粗心团队的故事。而是一个关于所有构建 Agent 的团队如何陷入同一困境的故事，因为大多数公司尚未发明防止这种情况发生的生命周期管理规范。人类身份识别在过去 30 年中为此积累了大量机制——入职工作流、季度访问审查、转岗时的自动权限撤销。而 Agent 身份识别只有一条 Slack 消息，写着“我晚点会清理”。第一天的授权变成了第九十天的遗产，而爆炸半径随着每次模型升级、每个添加到 Agent 工具箱的新工具以及每个接入该角色的新客户而不断扩大。

为什么人类生命周期的管理逻辑无法平移

大多数团队的本能是将 Agent 身份建模为服务账号（Service Accounts），而服务账号本身又是松散地模仿人类身份建模的。逻辑听起来没错：Agent 是一个主体（Principal），它进行身份验证，在某个角色下进行 API 调用，角色有策略，策略在有人记起时会进行审查。问题在于，没有任何能约束人类身份的生命周期钩子（Lifecycle Hooks）实际上会被触发到 Agent 身上。

人类的权限会过期，是因为他们换了团队、换了主管、离职，或者未能通过某个日程表中注定要进行的季度审查。Agent 不会换团队。它没有主管。它归属于部署它的那位工程师，而当那位工程师转到另一个项目时，Agent 并没有新的所有者——它只是带着它在配置当天拥有的 Scope 继续运行。行业数据支持这一点：大约 97% 的非人类身份携带的权限超过其实际所需，且近一半的身份已超过一年未进行凭据轮换。8% 根本没有所有者，这是一种委婉的说法，即在能够撤销访问权限的人不再关注之后，这些访问权限依然存在。

更糟糕的是速度。人类身份中的权限漂移是随着人员流动和组织架构调整而在数年间累积的。Agent 系统的权限漂移则是在每个 Sprint 中累积的，因为 Agent 学会调用的每个新工具、每个重试路径、每个“也给它写入权限吧，这样它就能修复自己的错误”的操作，都在朝着一个无人审查的方向扩大权限范围。这种复合速率的差异就像是缓慢漏水与水管爆裂的区别。

生产环境中出现的三种故障模式

第一种故障模式是每个人都预见到但依然会发布上线的：Agent 的角色累积 Scope 的方式就像资深工程师的账号累积遗留权限一样。每个新功能都会在这里加一个 iam:PassRole，在那里加一个 s3:PutObject，或者加一个需要 customer:write 的 Stripe Webhook 处理程序。这些 PR 很小，且在单独看时都是合理的。总和则是一个几乎无所不能的角色，直到审计员要求解释每个 Scope 的合理性，团队才意识到他们无法提供。

第二种故障模式是团队说服自己无需担心的。论据是：“Agent 只执行其提示词（Prompt）指示的操作，而提示词是由我们控制的。”这在提示词注入（Prompt Injection）有效负载到来之前是正确的——它可能嵌入在客户服务工单、检索到的文档或工具执行结果中——然后 Agent 就会乖乖地按照有效负载的指示行事，利用它已经拥有了九十天的合法写入权限。OWASP 将提示词注入列为 2025 年 LLM 风险清单之首，正是因为这种攻击不会绕过基础设施控制；它直接操控了一个已经拥有访问权限的系统。被记录为 EchoLeak 的 2025 年 Microsoft 365 Copilot 漏洞就是一个生产环境中的实证。Agent 的权限决定了爆炸半径，而提示词从来都不是防线。

第三种故障模式是最隐蔽的。Agent 发起的 API 调用在策略范围内，符合其声明的目的，但略微超出了产品应有的行为——由于 Agent “只是在做它的工作”，没人去阅读审计日志。为人类身份构建的审计流水线假设策略违规（Policy Violations）是有价值的信号。对于 Agent，有价值的信号是那些意图发生漂移的策略内调用：原本是支持类的 Agent 开始向它在技术上一直有权写入的数据库写入数据，或者原本是编码类的 Agent 开始调用没人告诉过它的部署端点。基于 ACL 的审计无法捕捉到这一点。只有具备意图感知能力的审计才能发现，而几乎没人构建这种审计机制。

当团队真正建立这种规范时，它是怎样的

有一小部分但日益增多的实践来自那些经历过第一次事故并决心不让第二次发生的团队。这些模式在不同的供应商和技术报告中交相辉映，而且它们与人类身份实践有着足够的差异，必须从头构建，而不能直接借用。

第一个模式是默认限时授权。代理（agent）获得的每一项权限范围都带有过期时间——30 天、90 天、冲刺结束（end-of-sprint），或者任何符合节奏的时间——且只有在值班人员审核并批准了可读的理由后才能续期。这听起来很官僚，但在实践中，这是唯一能在团队轮换中幸存下来的机制。理由本身就是记录；没有它，下一位工程师就无法区分哪些是残余权限，哪些是核心支撑，于是他们会续期所有权限，规范也随之崩溃，变回了披着时钟外衣的长期权限（standing privilege）。

第二个模式是通过即时访问（just-in-time access）强制执行零长期权限。代理不持有凭证。它在行动的瞬间请求凭证，权限范围仅限于任务、工具以及发起请求的用户（或系统）的授权，并在任务结束时凭证失效。2026 年的行业覆盖将其视为代理 IAM 的基准，其背后的数据是关键杠杆：向 AI 系统授予过度权限的组织，其安全事故大约是未过度授权组织的 4.5 倍。JIT 将可利用的时间窗口从“无限期”缩短至“调用持续期间”，这才是针对该威胁模型的正确数量级。

第三个模式是按已知节奏进行最小权限校准。每 30 天、90 天或每季度——将角色与运行时的实际使用情况进行比对（diff），任何代理在窗口期内未实际行使的权限都会被移除。AWS IAM Access Analyzer、Google Cloud 的 IAM Recommender 以及十多家 ISPM 供应商现在都提供了这种基础功能；差距在于组织层面，而非技术层面。只有在有人负责运行校准、且有人负责根据结果采取行动时，校准才会奏效，而大多数团队都没有分配这两个角色。

第四个模式是与人类身份注册表分离的代理身份注册表。代理是第一类主体（first-class principals），而不是穿着伪装的服务账号，它们的生命周期钩子是为代理实际发生的事件而设计的：团队重组、产品退役、模型版本升级、能力扩展。2026 年初的 CoSAI 第 4 工作组出版物和 NIST 的 AI Agent Standards Initiative 是这场讨论的源头，而 Google Cloud 基于 SPIFFE 构建的第一类代理身份原语是最显著的生产环境实现。SPIFFE 本身就是合适的底层架构，因为它就是为短效、自动轮换的工作负载凭证而设计的——X.509-SVIDs 在其有效期过半时就会在无需人工干预的情况下自动续期，这正符合代理身份所需的节奏。

第五个模式是意图感知审计。审计管道不标记违反策略的行为；它标记那些模式超出代理声明用途的 API 调用。这要求代理拥有一个结构化的、足以被审计的声明用途——用 Trustle 的话说，就是一份包含工作地点和合同的职位描述（job description）。这种规范更接近于异常检测而非访问审查，而且它是这五个模式中唯一能真正捕捉到上述第三种失效模式的。

组织架构才是真正的障碍

这件事之所以困难，并不是因为缺乏控制手段。控制手段存在，供应商在售卖，标准机构也在发布框架。困难的原因在于，在典型的组织架构中，没有一个团队能端到端地负责代理的权限。

AI 团队在试点期间授予了权限范围，并在演示成功时认为工作已经完成。安全团队抽象地拥有 IAM 策略，但缺乏关于代理实际需要什么的领域背景。值班团队负责运行环境，但继承了没有历史背景的角色。平台团队拥有身份提供商，但将代理视为服务账号。代理是唯一一个横跨这四个管辖权的实体，而代理却不在任何会议中。

解决方案不是新工具。而是一个明确的负责人——单一团队，理想情况下是负责生产环境中运行代理的团队——拥有拒绝续期、强制校准以及在产品退役时注销代理的权力。如果没有这个负责人，限时授权就会变成形式上的续期公章，校准过程会变成没人参加的季度会议，而注册表则会变成没人阅读的 CSV 文件。

核心启示

一个没有权限过期策略的代理，不过是一个披着友好名称的 sudo 授权。回想起来，当初那句“在试点之后收紧权限”的便签，实际上是一项在你的组织中没有任何日历会提醒你去完成的工作承诺。代理不会自动转交团队。角色不会自动过期。审计日志也不会主动举手示意。

那些在回顾 2026 年时认为自己做对了的团队，是那些今天就在构建人类身份已拥有数十年的生命周期机制的团队——并且承认，由于节奏和失效模式完全不同，这些机制必须为代理量身定制，而不是直接套用人类的模式。那些没能做到的团队会在大约第 120 天左右发现，他们发放的每一个凭证的爆炸半径（blast radius）都随着代理数量的增加而扩大，而挡在提示词注入攻击（prompt-injection payload）与生产环境写入权限之间的唯一屏障，竟然是他们决定推迟执行的规范。

第一天是缩小授权范围成本最低的唯一机会。此后的每一天，授权都会变得更难撤销、更容易被遗忘。团队在第一天承诺的清理工作不是一个待办事项；它本身就是权限策略，在第一天就把它写下来，才是真正能持久的规范版本。