权限复核是围着「离职日」建起来的。你的智能体没有离职日。
你们组织里每一套权限复核之所以管用，是因为有人离职时 HR 会发出一个事件，而真正清理掉权限的正是那个事件——季度认证不过是压在它上面的文书。智能体没有离职事件。它的凭据是某个工程师在项目中途创建的，它活得比项目久、比那个工程师久，通常也比那个用例久，而没有任何地方会发出「该停了」的信号。解法不是在表格里多加几行服务主体：而是干脆别再复核凭据，改为复核「够得着的调用」，并让到期由使用情况驱动，而不是由复核人的记性驱动。
把「人的生命周期为何搬不过来」说清楚。
入职—调动—离职是一套好设计，而它立足于三条智能体并不具备的性质。在你试图复用这套流程之前，先把它们说出口，因为每一条都会打坏一道不同的管控。
- 没有终止事件。一个人的权限会衰减，是因为别人的系统宣告了结束。一个智能体的权限在某个人想起来的时候才结束——也就是说，它不会结束。
- 没有能背书的主管。认证假定复核人知道被复核对象整天在干什么。你去请一位总监确认
svc-agent-prod-07仍然需要对计费库的写权限，你会拿到一个「通过」，因为另一个选项是在周五弄坏点什么。这里的橡皮图章不是纪律问题，而是对一个读不懂的问题所能给出的理性回应。 - 没有稳定的岗位职能。人的权限随着岗位变化缓慢漂移。智能体的实际可达范围，在有人改了一句提示词或注册了一个工具的那一刻就变了——那是一次部署，不是一次调岗。你的复核周期是季度，而你的变更频率是天。
实际后果是：审计师写下的那条发现——「服务账号未纳入周期性权限复核」——附着的整改措施是错的。把它们加进同一套复核，产出的是规模化的认证和零清理。下面讲的是管用的那套整改，而它恰好还能产出比认证更好的证据。
复核「够得着的调用」，而不是凭据那一行。
单位比周期更要紧。一份凭据清单会在两个方向上都低估智能体的可达范围，而事故就住在这道缺口里。
- 一份凭据，多项能力。一个数据库角色、一个云角色、一次带六个 scope 的 OAuth 授权。复核那一行，并不能告诉你这六个里智能体到底用了哪几个。
- 多份凭据，一个智能体。智能体自己的密钥、MCP 服务器另有的密钥、连接器平台按用户存的令牌、某人顺手复用的那个共享只读分析账号。归属人不同、系统不同，爆炸半径却是同一个。
- 没人签发过的可达范围。一个带着活跃会话的浏览器配置文件、一条没有出站策略的网络路径、一个文件系统挂载点。这是环境权限，它压根不出现在任何凭据库里。
所以可供复核的对象是：这个智能体可以针对这个系统、在这些数据上、执行这个调用。把它从工具注册表与「每份凭据实际授予了什么」的连接中推导出来，并把它放在智能体清册旁边，而不是放进 IAM 工具里——IAM 工具看不见你的工具定义。
// The row a reviewer can actually answer.
{ "agent": "invoice-triage",
"capability": "erp.invoice.approve",
"credential": "svc-invoice-triage",
"limit": { "max_amount_eur": 5000, "rate_per_hour": 40 },
"granted_for": "JIRA-4412 — AP automation pilot",
"owner": "ap-platform-team",
"last_successful_use": "2026-04-02T09:14:22Z",
"expires": "2026-10-01" }
让每一项授权都能用一句话复核，否则它会在没人读的情况下被通过。
复核人只能拒绝他看得懂的东西。三个字段就能把一行无从回答的记录变成答得上来的记录，而这三个都必须在授予的那一刻采集——事后一个也重建不出来。
- 理由，写成一个链接。不是「生产访问」，而是那张为它背书的工单、事故单或项目。一项理由指向已关闭工单的授权，等于自己回答了自己的复核问题。
- 具名的归属方。写团队，别写个人，因为个人会走，而授权不会。这与问责那一页派给操作者的是同一个角色。
- 绑定的限额。金额上限、速率上限、行级范围。一项带着限额的能力可以就限额来复核——「这个还该是 5,000 欧元吗？」是一个业务负责人答得上来的问题，而「这个智能体该不该有 ERP 权限？」不是。
理由要用业务流程的语言写，别用基础设施的语言。检验标准是：平台团队之外的人能不能读完这一行并形成意见；如果不能，那么无论你跑多勤，这场复核都是演戏。
用「按使用情况到期」取代认证。
这才是真正会移除权限的那道管控，而它需要的数据早就躺在你已经付过钱的系统里。AWS IAM 会按服务、按动作报告最后访问信息；云身份提供方会为工作负载身份记录登录；你自己的网关则记录了每一次工具调用。规则是机械的。
- 每项能力在授予时就带一个到期日。试点用九十天是个合理默认值，熬过一轮完整复核的能力可以给一年。不带到期日就不授予，而且表单上没有「永久」这个选项。
- N 天未使用，直接吊销。不是标红，不是上报——是吊销，同时通知归属方，并在一周内提供一键恢复。一项没人用的授权，是移除起来最便宜、保留起来最难辩护的东西。
- 用了但从不接近上限的，就往下收。如果审批天花板是 5,000 欧元而实际的 p99 是 180 欧元，那这个天花板就是错的。按计划把限额朝实测用量一档档往下拧；正是在这里，一场权限复核才从「名单又被重新批了一遍」变成爆炸半径的真实缩小。
- 重新授予必须便宜，否则规则会被绕过。如果恢复一项被吊销的能力要三天和两道审批，工程师就会靠排一个每月触碰它一次的定时调用，把所有东西都养活着。把恢复路径做得足够快，囤积就无利可图。
把这套做法与底下真正短命的凭据配对，这样你复核的就是「签发的权利」，而不是躺在保险库里的一个秘密——见给智能体的受限凭据。
受委托的那一半确实有离职事件。把它接起来。
智能体的一部分权限根本就不是它自己的——它持有的是一个代表某位点过「同意」的具体的人的令牌。邮箱访问、一份日历、一个 CRM 席位、一张支付授权书。在这里终止事件是存在的，它就是 HR 早已在发的那一个，而它几乎从来没有连到智能体平台上。
产出扛得住审计师的证据，而不是一张截图。
你会被问到的不是「你们跑不跑权限复核」，而是「拿出证据来：这个智能体的权限在整个期间都与它的用途相符」。有四件产物能回答它，而每一件都是一次查询，不是一份文档。
- 带版本的能力登记册——什么时候存在过什么、限额是多少。按时间点重建就是全部要求；一份当前状态的导出，证明不了三月份的任何事。
- 吊销日志。一场从不移除任何东西的复核，本身就是「复核坏掉了」的证据。「每期移除数」是这个项目最好的单项健康指标，而一个平平的零，比一个很大的数字更该让你担心。
- 例外，带到期日。每个项目都有长期例外；没有边界的例外，正是一次临时提权变成永久的方式。一条没有结束日期的例外，是你自己给自己写下的一条审计发现。
- 覆盖率。在册的活跃智能体能力占全部的比例。「已发现但未登记」这个数字，才告诉你这本登记册描述的是不是现实——与清册在「发现」与「清册」之间划下的是同一道区分。