AI 代理离职清单：实现受控退出

员工离职是少数几种会让访问控制与时间赛跑的情况之一。普通的账户禁用流程不足以应对 AI 代理，因为有价值的工作往往通过本地进程、无人值守任务、共享 API 凭据、SSH 材料以及员工身份之外复制的配置来完成。

把离职处理看成一次受控的权限转移，而不是 IT 清理工作。你需要停止新的操作，找出已经在执行的工作，替换共享权限，并在有人删除能够解释事件经过的证据之前保存记录。

禁用身份不会撤销通往生产环境的所有路径

禁用目录账户只会停止那些在使用时确实查询该目录的访问路径。它不会撤销本地配置文件中的 API 令牌、代理工作区中加载的 SSH 私钥、此前签发的云访问令牌，也不会撤销 CI 任务注入的共享服务凭据。

之所以容易混淆，是因为在仪表板中，人员、代理进程和凭据常常都显示在同一个员工姓名下。它们是不同的对象，需要采取不同的措施：

• 人员身份说明谁完成了身份验证。
• 本地代理进程说明当前能在员工计算机上执行什么操作。
• 凭据说明远程服务会接受什么请求。
• 会话或任务说明哪些工作可能已经在进行。
• 审计记录说明你日后能够证明什么。

混淆这些概念会造成一种常见故障。人力资源在 09:00 将员工标记为离职。IT 在 09:05 禁用单点登录。09:20，一台尚未收回的笔记本电脑上的计划代理任务启动。它使用环境中保存的共享部署令牌，修改了生产环境设置。每个参与团队都可以如实说自己移除了员工账户，但没有任何团队移除代理实际使用的权限。

在离职工单开头写下一个固定问题：「如果员工的正常登录停止工作，哪些操作仍可能成功？」不要接受「账户已禁用」作为答案。

NIST SP 800-53 将相关控制放在不同控制族中是有原因的。AC-2 涵盖账户管理，IA-5 涵盖身份验证器管理，AU-9 涵盖审计信息保护。把三者压缩成一个复选框的团队，通常会在事件发生后才发现遗漏的工作。

在收回笔记本电脑前冻结操作路径

先停止远程权限，因为收回设备可能需要数小时，而通电的笔记本电脑可以继续运行。执行离职流程的人应通知安全负责人和各服务负责人，然后暂时暂停归属于离职员工或其工作站的自动操作。

第一轮检查应覆盖以下路径：

1. 如果身份提供商、云平台、代码托管平台或特权访问系统支持，撤销活动的远程会话。
2. 禁用或隔离员工拥有的已注册构建 runner、计划代理任务和远程开发会话。
3. 根据运营流程允许的范围，将设备移出受信任设备、VPN 和管理访问范围。
4. 暂停能够部署、修改基础设施、发送消息或写入客户系统的无人值守任务。
5. 在员工失去对设备的监管之前收回工作站，或将其置于受管理的网络限制之下。

不要一开始就删除本地文件。如果离职存在争议、情况异常或与安全问题有关，应按照事件响应流程保留设备状态。仓促擦除会破坏 shell 历史记录、代理日志、本地配置、任务队列和时间戳，而这些信息可能用来判断某项操作是否经过授权。

对于正常的计划离职，安全负责人可以决定沿用常规设备归还和重装规则。这一决定应写入工单，不应只留在某个人的记忆里。

代理进程边界是一个很有用的控制点。终止本地运行的代理前，记录可执行文件路径、父进程、进程标识符、启动时间、工作目录和代码签名主体。在 macOS 上，操作人员可以这样收集基本的进程快照：

ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent'

# Output shape:
# 8421   611 alice  Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release

这条命令本身不能构成证据，但它能为调查人员提供带时间范围的线索，也能避免「有一个代理在运行」这种模糊说法成为完整记录。

建立权限清单，而不是软件清单

已安装的 AI 工具列表无法告诉你谁能够修改某项服务。应盘点每条权限路径，包括可能不被称为 AI 的工具。员工可能通过终端、编辑器扩展、CI runner、本地脚本或远程环境使用代理。路径比标签更重要。

每个凭据或身份关系占一行。如果一个令牌可以访问三项服务，应在权限范围栏中列出它带来的三项后果，而不是把它们埋在备注里。

最难发现的是共享权限。直接向服务负责人提问：员工是否知道一个在账户失效后仍会继续有效的令牌？他们是否管理过机器人账户？设备能否使用 SSH 密钥连接？是否有任务以通用身份运行？今天之后谁会收到该任务的告警？

不要让离职员工成为这份清单的唯一信息来源。他们可以提供帮助，但代码仓库、秘密存储、authorized-keys 文件、CI 配置、服务所有权记录和审计日志必须相互印证。人们会忘记在故障期间创建的令牌，也会忘记一个两年前从测试 runner 变成生产基础设施的任务。

按依赖顺序轮换共享凭据

只要离职人员可能读取、复制、导出共享凭据，或在可靠的身份绑定撤销路径之外使用它，就应轮换该凭据。这包括 API 密钥、basic-auth 密码、webhook 秘密、部署令牌、数据库密码、SSH 密钥、云访问密钥和恢复代码。

「同时轮换所有凭据」听起来果断，但这是一个常见的错误建议。它会制造一份看起来很 impressive 的秘密变更清单，却也会破坏未知依赖，让故障排查陷入混乱，并使团队在压力下恢复旧秘密。应按一个仍然保留明确替代路径的顺序轮换。

对每个凭据按以下顺序操作：

1. 指定服务负责人和使用该凭据的确切调用方。
2. 创建服务所支持的最小权限范围替代凭据。
3. 更新已知调用方，并证明它们能使用替代凭据正常工作。
4. 撤销旧凭据，然后测试它确实失败。
5. 记录替代凭据的保管人、创建时间、权限范围和撤销结果。

失败测试很重要。「轮换完成」往往只意味着有人创建了新令牌并更新了一个应用，并不代表旧令牌已经停止工作。发出一个旧凭据原本允许的、无害的身份验证请求。记录服务预期返回的拒绝结果，例如 HTTP 401 或 403，不要把秘密粘贴到工单中。

对于 SSH 访问，从每个目标主机的 authorized-keys 来源以及任何中央访问系统中移除离职人员的公钥。然后找出使用同一私钥的自动化任务。如果代理使用了共享 SSH 身份，应生成新的密钥对，在目标主机上替换公钥，更新获准的调用方，并废弃旧公钥。只从工作站移除密钥，对已复制的密钥不起作用。

不要在交接过程中通过聊天或电子邮件发送替代凭据。让新负责人通过获批准的秘密管理机制获得或使用它。轮换的目的，是减少无法核实的副本数量。

共享账户必须有明确姓名的负责人

服务账户可以合理存在，但没有指定操作人员的共享账户，实际上是在掩盖所有权问题。交接必须指定一名人员，由其对账户用途、权限范围、费用、恢复路径和未来凭据轮换负责。

要把运营责任与凭据本身分开。员工离开后，发布机器人可能仍需继续部署，但这不意味着接替者应继承前员工的个人令牌或使用其本地配置。只要服务允许，就为机器人建立独立身份，仅授予它所需的权限，并让新负责人对其负责。

写一份简短的交接记录，回答以下五点：

• 该账户支持什么服务或工作流？
• 它能访问哪些环境并执行哪些操作？
• 目前哪些系统会调用它？
• 谁可以修改其凭据或恢复账户？
• 什么时候会有人检查它是否仍然需要这些访问权限？

这也是团队发现代理默认设置被伪装成便利做法的地方。本地配置可能要求代理使用通用部署身份，因为最初的开发者没有时间建立专用身份。不要以保持连续性为由保留这个捷径。重启工作前，先将其替换为有明确负责人的访问路径。

在保留任务清除记录前保存证据

保留能够让你重建权限和操作过程的记录，不要依赖离职员工的解释。保存离职工单、访问权限清单、身份禁用事件、会话撤销记录、轮换事件、CI 任务历史、代理运行记录、端点设备处理决定和服务审计导出文件。如果系统时钟不同，还要记录时区和时钟来源。

保存证据不等于截取几张屏幕截图。截图会丢失字段、隐藏筛选条件，而且通常很难验证。尽可能以原生格式导出原始记录，为收集的文件保存哈希，限制案件组的访问权限，并记录每个副本由谁处理。

下面这份收集记录足够简短，便于使用，也足够具体，便于审计：

Case: OFF-2025-041
Collected by: security-operator
Collected at: 2025-03-12T09:37:16Z
Source: build-service job history export
Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z
File: build-jobs.json
SHA-256: <recorded digest>
Storage: restricted evidence repository
Reason: employee exit and agent authority review

保持原始导出文件不变。如果调查人员筛选或标注了内容，应将其保存为单独的工作副本。这种简单的分离比复杂的取证工具更能避免争议：人们可以检查分析结果，同时不会悄悄修改源记录。

NIST SP 800-92 将日志管理描述为生成、传输、存储、分析和处置的过程。离职处理的薄弱点通常在处置环节。较短的默认保留期限可能会清除唯一一条能够证明代理是在访问权限变更之前还是之后执行操作的运行记录。对政策允许保留的记录设置保留锁定，然后通过正常流程解除锁定。

让代理授权可以按进程撤销

开发者对某个代理进程的批准，不应变成对其计算机上所有进程的全面许可。进程可能被替换，从不同工作目录重新启动，或在员工离开后由编辑器扩展调用。授权记录需要明确标识进程，并提供立即撤销路径。

网关可以在这里发挥作用，但前提是它拒绝把凭据交给代理。Sallyport 将 API 和 SSH 凭据保存在加密的本地保险库中，默认按会话为新的代理进程授权，并分别记录会话和单独操作。

在离职处理中，导出或保留相关会话和活动记录，撤销实时会话，并在转移设备前锁定保险库。这个顺序能建立一个有意义的边界：代理无法再发起新的外部调用，同时其先前调用的记录仍可供审查。

不要把按会话批准误解为批准每一项有后果的操作。代理可能确实需要一个会话来读取代码仓库，但每个会改变生产环境的凭据都可能需要在每次使用时确认。应把更严格的控制放在滥用后会迫使团队启动事件响应的凭据上，而不是放在无害的只读调用上，否则用户会因频繁审批而疲劳。

审批疲劳是设计失败。如果人们每次收到常规请求都要处理提示，就会停止阅读提示。如果一次提示悄悄覆盖了对无关生产系统的访问，那么提示范围就太宽。好的授权会建立清晰边界，让操作人员事后能够解释发生了什么。

检查正在运行的工作和延迟触发器

撤销账户并不能可靠地停止远程服务已经接受的工作。检查排队中的构建、远程 shell、自动化计划、代码仓库工作流分发、软件包发布任务、基础设施计划以及稍后能够启动工作的消息队列。

对于每项正在运行或排队的工作，决定是取消、在监控下让它完成，还是转交给新负责人。决定应取决于操作内容、影响范围以及任务能否重现。拥有明确变更记录的部署可以允许其完成。能够修改访问控制或移动数据的任务通常应先停止，直到负责人确认意图。

取消前先保存标识符。如果服务会在保留期限后删除任务详情，仅保存任务地址并不是好的证据。保存任务 ID、触发身份、提交或任务引用、开始和结束时间、使用的权限以及结果。如果任务在离职处理中失败，应注明失败是否由撤销操作引起。否则，未来调查人员可能会把访问控制成功误认为运营故障。

还要检查延迟执行。cron 条目、launch agent、CI 计划、云事件规则和代码仓库工作流，都可能在团队以为离职流程已经结束后恢复活动。定期任务应转交给受管理的负责人，或直接禁用。让它继续以一个无人负责的账户运行，会让下一次故障既可预见又难以诊断。

只有独立人员能够验证结果时才关闭流程

进行变更的人不应是唯一宣布离职处理完成的人。请安全同事、服务负责人或经理验证最重要的项目：前员工的身份无法登录，旧共享凭据已失效，没有仍归属于前负责人的计划代理工作，证据收集内容可读取且受到保护。

使用一份列出已验证事实的关闭声明，不要写模糊的「已完成」：

Former identity: disabled and active sessions revoked
Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked
Agent work: 2 scheduled jobs transferred, 1 queued job canceled
Evidence: exports and collection hashes stored under case OFF-2025-041
Exceptions: none
Verified by: service owner and security reviewer

如果某个凭据无法立即轮换，就保持工单打开，并记录补偿性限制、责任人和截止日期。「以后再做」不是控制措施。防火墙限制、禁用工作流或临时暂停服务都可以成为控制措施，前提是有人验证它们，并且知道何时失效。

最先值得做的改动很简单：在现有的人力资源离职工单中加入权限清单和证据保留决定。这两个字段会在笔记本电脑消失、令牌继续有效或日志保留任务删除代理操作唯一记录之前，迫使团队进行正确的讨论。