存在于代码中的权限所带来的问题
Agent 框架擅长编排。它们不是身份系统，它们所暴露的权限模型也不是治理控制手段。框架中的工具允许列表只是应用代码中的一份列表。它随 Agent 一起版本化，随 Agent 一起部署，由执行该 Agent 的运行时读取。身份团队看不到它，它不会出现在访问审查中，也无法与基于目录对象运作的入职-转岗-离职（joiner-mover-leaver）流程进行对账。
这一缺口如今正在大规模地受到检验。范德堡大学将身份治理扩展到 AI Agent 的做法是一个有用的参照，因为它把 Agent 视为与人类相同的治理机制所管辖的主体，而不是带有配置文件的软件制品（SiliconAngle）。这一教训是结构性的，而非机构性的：如果一个行为主体能够读取数据、调用 API，或代表某人行事，它就需要一个目录能够签发、限定范围、审查并撤销的身份。
为什么框架权限无法通过审计
有三种失败模式反复出现。
第一，不可见性。工具允许列表和 scope 字符串存在于 Agent 自身的配置中。查看身份提供方的访问审查者看到的只是一个拥有宽泛授权的服务账号，或者如果 Agent 通过共享凭证进行认证，则什么都看不到。审查者无法看到该 Agent 可以调用支付 API、工单系统和文档存储，因为这些细节位于审查者不会去读的代码仓库中。
第二，退役后的存续。当 Agent 被下线时，其凭证往往仍留在环境变量、密钥存储或另一个系统仍在加载的配置文件中。框架生命周期中没有任何机制强制移除，因为框架并不知道该 Agent 有一个已经离职的负责人，也不知道它所支持的功能已被退役。凭证的生命超出了其用途。
第三，权限蔓延。Agent 随着功能上线不断累积 scope。一次新的集成增加一个 scope；一次重构又增加一个。scope 很少被移除，因为移除需要知道哪个 scope 对应哪个功能，而这种映射关系并未得到维护。结果是 Agent 拥有的访问权限超出任何单一任务所需，并被无限期持有。
目录原生 Agent 身份是什么样的
目录原生 Agent 身份是存放人类账号的同一目录中的一等对象。它具备使治理成为可能的属性：
- 负责人与担保人。 负责人是对 Agent 行为负责的团队。担保人是授权其存在的人类主体。二者都是目录引用，而非自由文本字段。
- 有效期。 该身份具有有效期限。它默认不会永久存在。
- 权限。 scope 作为目录权限授予，挂载到 Agent 对象上，并与人类访问在同一审查周期中呈现。
- 委派链接。 Agent 代表某个具名主体行事。该链接被存储且可查询，因此审计人员可以询问某一给定操作背后是哪个人的授权。
这不是表面上的改动。它把问题从“这段代码能做什么？”转变为“这个行为主体被授予了什么权限，是谁授权的，该授权何时终止？”
框架无法表达的生命周期操作
一旦 Agent 成为目录对象，生命周期操作便成为可能，而在框架内部则不然。
按计划轮换与撤销。 凭证按日历轮换，而非按部署轮换。撤销是一项目录操作，会在所有信任该目录的系统中生效，而不是必须发布到每个集成的代码变更。
自动暂停。 如果负责团队被解散，或担保人从目录中离职，Agent 的身份可以被自动暂停。框架没有“担保人离职”这一概念，因为框架不对雇佣关系或团队成员关系建模。
证明（Attestation）。 定期的人工签核确认该 Agent 仍然需要它所持有的每一个 scope。证明是一项治理原语：它强制对每一项权限做出决定，并产生一份关于由谁做出该决定的记录。
这些都无法表达为框架权限，因为它们依赖于框架并不拥有的目录状态。
一种具体机制：结合实际使用 scope 遥测的权限映射
一种切实可行的实现方式，是把目录视为权限的事实来源，同时让框架（至少在初期）继续作为执行点。
在签发时，目录铸造 Agent 身份并授予一组权限。框架收到一个编码了这些权限的 token 或凭证。在运行时，框架记录哪些权限被实际使用。该遥测数据作为 Agent 对象上的一个属性写回目录。
随后目录呈现两种视图：已授予 scope 与已使用 scope。二者之间的比率是主要的卫生指标。一个持有十二个 scope 却只使用三个的 Agent，就是缩减的候选对象。该机制不要求框架理解治理；它要求框架报告使用情况，由目录进行比对。
这是一个刻意乏味的设计。它把目
无需“大切换日”的迁移
一个常见的错误是试图一次性干净切换：同时把签发和执行都迁移到目录。这会破坏正在运行的系统，因为尚未更新的执行点会拒绝新的凭证格式，而已经迁移的签发端也不会再产生旧格式。
更安全的顺序分为三个阶段。
- 镜像。 读取框架层面的 scope，并创建对应的目录权限。此时尚未执行任何强制。目的是让访问审查有东西可查。
- 从目录签发。 把凭证签发迁移到目录，同时框架仍执行自己的允许列表。二者必须一致；不一致之处会被记录并对账。
- 从目录执行。 一旦签发稳定且镜像准确，就把执行切换到目录签发的权限。框架的允许列表成为可移除的冗余检查。
这个顺序很重要。先签发，后执行。颠倒顺序意味着目录在执行尚未向任何系统签发的权限，这会产生看起来像身份故障、实则是顺序故障的宕机。
诚实的权衡
目录原生 Agent 身份会增加延迟和耦合。每一个依赖目录签发权限的 Agent 操作，都继承了目录的可用性。框架本地的允许列表没有这种依赖；它只是内存中的一份列表。把治理移入目录，意味着接受目录处于 Agent 操作的关键路径上，且目录宕机就是 Agent 宕机。
这一权衡通常是值得的，因为替代方案是一个无人能够审查的访问面。但它应当被明确做出，而不是在事故中才被发现。缓解手段是缓存和具有明确撤销语义的短期 token，而不是放弃目录作为事实来源。
应当衡量什么
主要指标是每个 Agent 已授予权限与已使用权限的比率，按计划进行审查。次要指标包括从担保人离职到 Agent 被暂停的时间，以及设置了有效期的 Agent 所占比例。这些是目录查询，而非框架日志，这正是重点所在：治理问题应当能够从记录系统（system of record）中得到回答，而不是从应用遥测中重建。
Agent 身份治理不是 Agent 框架的一项功能。它是目录的一种属性，只有当目录签发、限定范围、审查并撤销 Agent 所使用的身份时，它才真正有效。
封面照片：panumas nikhomkhai / Pexels。