# 角色变更时的 AI 智能体访问权限交接清单

角色变更是检验 AI 智能体访问权限模型是否真正有效的时刻。团队经常会转移代码仓库权限，却忘了智能体调用生产 API、打开 SSH 会话或触发部署所需的凭据路径。智能体仍然能够工作，但没人说得清谁可以批准它的操作、谁会查看记录，或者凌晨 2 点谁能叫停它。

AI 智能体访问权限交接清单必须转移四项不同的职责：凭据保管、操作批准、审计审核，以及事件期间的处置权限。把这些职责笼统地归为一个“所有权”概念，正是导致开发人员角色变更很久后，离任人员仍在事实上掌控生产路径的原因。

## 角色变更转移的是权限，不只是密钥

团队必须转移批准智能体操作并对其负责的能力，即使凭据本身从未离开安全存储。密钥可以继续保存在同一个保险库中，但它的负责人、允许用途、批准人和审核人都可能发生变化。这些是不同的信息，每一项都需要有明确的记录。

先把经常被压缩成同一个名字的几类人员分开：

- 凭据保管人可以轮换、禁用或替换密钥。
- 服务负责人决定智能体是否应该继续访问该系统。
- 批准人负责在需要批准时接受或拒绝智能体发起的操作。
- 审计审核人员检查智能体实际做了什么，并跟进异常情况。
- 紧急撤销人可以在正常负责人无法联系时停止访问。

小团队经常让一名工程师承担全部五项职责。对于范围有限的开发凭据，这样做可能合理，但要明确记录，并指定替补人员。否则，一次休假、意外离职或权限争议，就会让一名不在场的人员变成难以替代的运营依赖。

不要把代码仓库所有权和操作权限混为一谈。开发人员可能失去仓库的写入权限，但他们之前配置的智能体进程仍然可以访问问题跟踪系统、云 API 或生产主机。反过来，新团队负责人可能拥有仓库，却没有权力批准智能体使用发布凭据。要分别检查这两个层面。

我见过交接失败的情况：接任人员收到了一份 API 名称清单，却不知道每个凭据为什么存在。“部署令牌”这样的记录几乎无法帮助接任者。应写明目标服务、允许的操作、环境、负责人、批准方式和轮换方法。如果没人能用一句话说清某个凭据的用途，就先禁用它，直到有人能够解释清楚。

## 移交责任前先冻结变更

交接进行期间，暂停新的智能体访问权限变更。不断变化的状态会让交接文件在有人签字时就已经过时。

冻结并不意味着让所有智能体运行都停上一周。它意味着在交接期间，任何人新增凭据、扩大权限范围、修改批准设置或授予新设备访问权限，都必须由离任负责人和接任负责人共同记录。冻结窗口应当短暂且明确。对于计划中的角色变更，在日期确定后开始，并在人员失去访问权限前结束。对于突然离职的情况，先撤销权限，再根据记录重建清单。

明确写出边界。清单应包括运行在开发人员设备上的智能体进程、定时自动化任务、调用智能体的 CI 作业，以及存放真实凭据的测试环境。团队经常忘记本地工具，因为它们在云控制台中不可见。但本地访问仍然可以触达外部系统。

一份有用的冻结通知应回答四个实际问题：

1. 哪些凭据和端点属于这次交接范围。
2. 冻结期间谁可以批准例外情况。
3. 当前清单和操作记录存放在哪里。
4. 接任负责人什么时候接受职责。

对于接触生产环境或客户数据的凭据，不要接受“以后再整理”。所谓以后，往往就是人们发现某个智能体仍持有一个没人记得是谁创建的令牌时。短暂冻结的成本，低于在不知道哪些自动化任务会中断的情况下进行紧急轮换。

这里有一个重要区别：撤销个人账户，不等于撤销智能体的权限。凭据可能属于共享服务账户。批准权限可能附加在本地智能体进程上。SSH 公钥也可能独立于离任开发人员的身份提供商账户，为某台主机提供授权。交接必须找出每条路径，而不是只关闭员工账户。

## 建立描述用途的登记表，而不是记录密钥值

交接登记表应在不复制密钥材料的前提下识别凭据。接任负责人需要的是一张运营地图，而不是另一个保护更弱、充满令牌的保险库。

使用不透明标识符、指纹或保险库记录名称。对于 SSH 材料，记录公钥指纹及其获授权的主机。团队可以检查公钥指纹，而不会暴露私钥：

```sh
ssh-keygen -lf ~/.ssh/agent_deploy.pub
256 SHA256:exampleFingerprint agent-deploy (ED25519)
```

实际指纹会有所不同。重要的是，登记表要记录生成的标识符、主机账户以及密钥存在的原因。不要为了让交接材料“完整”而把私钥或 bearer 令牌粘贴进去。这样会制造新的泄露点，也会让轮换更难验证。

针对每个凭据或访问路径，将下面的记录结构复制到团队受保护的运营文档中：

```yaml
access_id: prod-release-api-01
channel: HTTP
service_and_environment: release API / production
allowed_action: create approved release
secret_reference: encrypted-vault record prod-release-api-01
credential_custodian: incoming platform owner
service_owner: release engineering lead
approval_mode: every use
approver_backup: operations manager
audit_reviewer: security duty engineer
emergency_revoker: platform on-call
rotation_method: replace token in service console, then test read-only endpoint
last_verified: 2025-03-08
```

上面的日期和姓名只是占位符。请替换为实际人员和日期，然后像保护运营元数据一样保护这份记录。它不包含秘密，但会告诉攻击者权限掌握在谁手中。

登记表需要记录权限范围，而不只是标签。“云令牌”可能意味着对一个测试账户拥有只读权限，也可能意味着对多个生产账户拥有管理员权限。请让服务负责人确认权限范围，不要只依赖离任开发人员的记忆。供应商控制台会变化，旧集成会长期存在，而某个凭据两年前的名称，往往与它现在能够执行的操作关系不大。

登记表还需要明确的处理结果：保留、轮换、缩小范围或撤销。“转移”不是处理结果。如果凭据当前没有用途，就撤销它。团队常常因为担心轮换带来风险而保留闲置访问权限，但闲置权限更难监督，也更容易被遗忘。

## 批准要求必须对应一位明确的人类决策者

只有当团队明确批准人员要为哪些事情负责时，批准设置才能真正形成控制。“有人会点击允许”不是要求，而是一个等待被匆忙处理的漏洞。

明确智能体是一次运行只需获得一次许可，还是每次使用凭据都需要许可。会话批准表示：“我确认这个智能体进程，并允许它在本次运行期间执行获准的操作。”每次调用批准表示：“我现在已经审核了这一次具体的使用请求。”两者应对的是不同风险。

对于范围受限的工作，可以使用会话批准。反复弹出的提示可能让人形成盲目批准的习惯。例如，修复测试套件的智能体可能需要对开发服务进行一连串读写调用。批准人员仍应知道哪个进程请求了访问，以及授权何时结束。

当单次操作可能造成重大后果时，应使用每次调用批准，例如部署到生产环境、删除数据、修改权限、向组织外发送消息，或使用范围很广的凭据。额外的停顿是有意设计的。如果某项操作太过例行，根本不值得进行人工判断，就缩小凭据范围，或将操作移入经过审核的自动化流程。不要为了消除提示疲劳，就给所有敏感凭据授予宽泛的会话批准。

交接时，用简单明了的语言记录以下要求：

- 哪个人或哪个角色可以批准每一类操作。
- 哪些情况必须逐次调用批准。
- 批准人员在允许操作前必须检查哪些证据。
- 会话授权在什么条件下失效。
- 正常负责人缺席时由谁替代批准。

证据不必复杂，但必须具体，包括目标环境、请求的操作、凭据身份、发起请求的智能体进程和预期结果。批准人员无法根据一条只说“智能体想要访问权限”的泛泛消息做出可靠决定。

一个常见但糟糕的建议，是团队“信任”智能体后就关闭批准。这个建议之所以流行，是因为提示会打断工作。但它是错误的，因为信任智能体生成代码的能力，并不等于授权它使用所有外部凭据。当操作路径范围很窄且测试充分时，可以减少批准。对于后果严重、需要有人说明批准理由的操作，则应保留批准。

## 审计审核必须对应负责人和时间安排

日志的存在本身不会带来问责。交接必须明确谁审核智能体活动、审核哪些内容，以及发现记录无法解释时要怎么做。

NIST 特别出版物 800-53 将 AC-2 中的账户管理与 AU-6 中的审计审核分开。这种区分很适合智能体访问权限。管理凭据的人，可能并不适合判断智能体的使用是否符合已批准的工作。独立审核可以发现错误，也能避免大家默认一切都没问题。

根据访问权限设置审核频率。用于发布的生产凭据，可能需要在每次发布后，以及每次失败或被拒绝的尝试后审核。低影响的开发集成可以按计划审核。不要写“定期”。这个词可以在每次错过会议后继续存在，因为它没有承诺任何具体时间。

审核人员应根据操作记录回答一组简短的问题：

- 哪个智能体进程发起了请求，谁批准了这次运行？
- 它使用了哪个凭据或访问路径？
- 它访问了什么目标，返回了什么结果？
- 请求是否对应某项明确任务或变更记录？
- 是否有被拒绝、重复或异常的操作需要调查？

要求审核人员为异常事件记录处理结论：预期行为、已纠正、已升级或未解决。团队不需要为每次无害的 API 读取都写一份仪式化报告。但当智能体在计划窗口之外访问生产环境，或反复请求一个本不应需要的凭据时，就必须留下清晰的判断。

如果可能发生事件，应在轮换或撤销前保存记录。轮换可以修复未来的暴露，却无法解释过去发生了什么。确保接任审核人员知道记录的保存位置、谁可以导出记录，以及如何验证记录的完整性。只有一名离任工程师能看懂的审计轨迹，是私人日记，不是运营记录。

## 在离职日期前演练撤销流程

撤销计划只有在团队针对一次无害请求进行测试后才算完整。第一次尝试不应发生在事件期间，因为那时所有人都会猜测拒绝结果究竟说明控制措施有效，还是服务本身出了问题。

演练一个经常发生的失败场景。开发人员转到其他团队，失去源代码管理权限。他们原来的智能体配置仍然运行在一台受管理的笔记本电脑上，并使用共享部署凭据。由于凭据属于发布服务账户，而不是开发人员本人，所以它仍然有效。同事让智能体“检查发布状态”，智能体仍然可以调用生产端点。团队以为员工账户被禁用就完成了离职处理，实际上并没有关闭这条共享路径。

应测试真实路径。服务负责人可以安排一次无破坏性的请求，例如在离任授权下向测试目标读取状态。然后根据交接要求，撤销旧授权、禁用凭据或移除允许的路径。再次发起请求，确认三件事：访问失败、失败原因符合预期，以及审计记录能够识别这次尝试。

这项测试发现的不只是被遗忘的凭据。它还能发现过期的本地配置、另一份 SSH 授权副本、使用意外服务账户的自动化任务，以及找不到对应记录的审核人员。

测试范围要小。无需执行破坏性操作来证明撤销有效。只要访问网关正确记录，一次被拒绝的状态调用或一次被拒绝的连接尝试就足够提供证据。记录使用的命令或请求、预期结果、实际结果，以及见证测试的人员。

如果测试失败，不要以“之后再调查”的承诺结束交接。把该凭据视为仍然有效但所有权不明确。升级给紧急撤销人，限制访问路径，并找出所有缓存或重复使用该授权的位置。失败的测试发挥了应有作用，因为它在离任人员仍能回答问题时暴露了这条路径。

## 紧急联系人必须有权限和有效的联系路径

紧急联系人不是目录中的一个字段。他们是在智能体尝试执行不安全操作，或正常负责人无法响应时，可以做出限时决定的人。

为每组敏感访问权限指定一名主要联系人和一名替补联系人。记录事件期间联系他们的方式、他们可以撤销的范围，以及决定是否恢复访问权限的服务负责人。不要只把一个团队邮箱列为紧急联系人。邮箱可以收集消息，却不会承担责任。

用运营层面的语言定义触发条件。例如，智能体执行了未经批准的变更、授权连续失败、一个意外的新智能体进程请求生产凭据，或审计记录无法对应到任何工作。联系人应知道应该暂停所有智能体操作、撤销单个凭据、禁用单个主机账户，还是联系服务负责人。

好的交接也会处理这样尴尬的情况：紧急撤销人正是要变更角色的那个人。在角色变更生效前转移这项能力，并测试接任者是否能够执行操作。不要在聊天中传递共享的“紧急破窗”密钥。这样会破坏归因，而且紧急情况结束很久后，它通常还会留在某个人的历史记录中。

还要写明恢复规则。紧急撤销应该容易执行，但恢复访问权限必须由服务负责人确认范围、审计审核人员检查事件，并由新的凭据保管人接受该凭据。跳过这条规则的团队，往往会为了让被阻塞的任务消失而恢复过于宽泛的访问权限。

## 访问网关应让交接过程清晰可见

本地操作网关可以减少交接失败的地点，但不能替代所有权决定。Sallyport 将凭据保存在加密保险库中，要求先打开保险库才能运行操作，并记录智能体会话和单独的调用，为交接审核人员提供了明确的检查位置。

它对会话授权和每次调用批准的区分，在制定上述要求时很有帮助。接任负责人应决定哪些凭据每次使用都需要重新获得人工判断，而不是沿用离任开发人员出于便利而选择的设置。

对于经过加密并由哈希链保护的审计记录，接任审核人员可以运行下面的离线验证命令：

```sh
sp audit verify
```

成功结果应报告验证已成功完成；失败结果应明确报告验证失败，而不是悄悄把记录当作可信内容处理。将它作为交接证据的一部分运行，并把结果与交接记录一起保存。该命令会验证密文上的链，不需要保险库密钥。当审核人员需要在不获得凭据访问权限的情况下验证记录时，这一点很有用。

不要把网关变成一项综合政策工程。充满各种团队例外的长篇规则文件很快就会过时，也会让交接更难。让决策点保持易懂：保险库是否允许执行任何操作，这次智能体运行是否获得授权，这个凭据是否每次都需要有人批准？然后确保由明确指定的人员负责回答这些问题。

## 签字确认应证明团队可以在没有离任人员的情况下工作

只有在接任团队证明能够控制每条有效访问路径后，才应关闭交接。没有撤销测试、明确的审核人员和有效的升级路径，一份签过字的文件只是手续，不是证据。

对范围内的每组凭据使用下面的收尾清单：

1. 登记表记录了服务、权限范围、保管人、批准人、审核人、替补人员和紧急撤销人。
2. 服务负责人在保留、轮换、缩小范围或撤销中做出了选择，团队也记录了结果。
3. 接任批准人以书面形式接受了会话批准和逐次调用批准的要求。
4. 审计审核人员找到了最近的操作记录，并在可用时验证了完整性检查。
5. 团队用一次无害请求测试了撤销或拒绝，并记录结果。

让离任开发人员只为其披露信息的准确性签字，而不要让他们为角色结束后的未来操作签字。让接任凭据保管人和服务负责人分别接受各自的职责。这样的划分很重要。当之后的事件暴露出一条过期访问路径时，团队可以看出问题究竟来自未披露的凭据、未执行的轮换，还是从未真正接受工作的负责人。

最终测试很简单。请接任人员在不联系离任开发人员的情况下回答：哪个智能体可以访问这个服务，谁可以批准，谁会查看记录，今晚谁能够叫停它？只要有一个答案含糊不清，交接就还没有完成。