员工离职后，怎样撤销 Agent 里的账号、资料和工具权限

员工离职后，撤销 Agent 里的权限不应只停用一个登录账号。旧会话、知识缓存、下载链接、工具授权、共享凭据和排队任务都可能继续提供访问。应以人员标识为线索建立回收清单，并通过合成用户演练撤销后的拒绝。本文是工程核对方法，不执行任何真实账号停用，也不替代企业人事与数据管理流程。

先确定撤销范围与生效时间

由已授权的管理流程提供离职或调岗事件，明确人员内部 ID、组织、回收时间、资产接手人和保留例外。不能根据聊天传闻直接停用同名员工。区分立即禁用、到指定时间禁用、只移除某角色和转交资产，执行人员在操作前确认对象与范围。批量回收应有逐项预览，避免错误映射让在职员工被停用。

盘点身份提供方、Agent 应用、知识平台、业务工具、通知渠道与管理后台，每处列账号或授权的别名、负责人和回收入口。个人持有的 API 密钥、OAuth 授权与共享服务账户分别处理：停用个人账号不必然撤销全部接口授权，共享凭据也不能因一人离职直接删除而影响其他业务。需要轮换共享秘密时，按消费者清单安排切换与验证。

旧会话与令牌要单独验证

关闭登录入口后，已登录浏览器仍可能持有应用会话，工具服务也可能接受未过期令牌。应检查本地会话撤销、刷新授权、访问令牌和后台代理任务的处理方式。OAuth 令牌撤销 RFC 7009定义撤销机制，并提到实际传播可能有延迟；是否级联撤销相关令牌取决于实现与策略，不能一概承诺点一下即刻全系统失效。

下载离职权限回收核对表。合成用户先用旧会话查询公开和受限资料，再执行经批准的停用，随后在原浏览器、工具入口和历史链接分别尝试。每个位置记录撤销时间、首次拒绝时间与实际证据。测试只用演示资料和模拟工具，不用真实离职员工的凭据反复登录；需要真实核实时由授权管理员按企业流程操作。

知识与缓存不仅是账号问题

部门角色撤销后，检索过滤、文档源权限、缓存和引用链接都要反映新范围。对话历史中曾经出现的受限片段是否继续展示，由企业策略决定并落实；不能允许已撤权用户靠提问“继续上一条”取到旧缓存。下载文件已经落到终端时，系统侧删除链接无法证明副本消失，应把终端和文件交接交给对应管理流程，不作无法验证的彻底清除承诺。

资料资产与资料访问权也要分开。员工上传的企业文档可能需要转交给资料负责人，不能一停账号就把业务知识全删掉；私人或不应继续保留的材料则按批准范围处理。每个对象记录接手人、版本、访问范围与处置依据，检索索引和附件副本同步核对。模型记住一个姓名或组织并不会让它自动更新真实权限，必须依靠系统层变更。

排队任务不应继续借旧授权写入

离职前已生成草案但尚未确认的动作，应按规则失效、转交或重新申请。已批准但尚未发送的动作，执行前仍要核对当前授权与确认有效性；转交给新负责人后，需要新的权限与具体动作确认，不能把原人的批准改名挪用。正在执行、结果未知的任务先核对目标事实，不要因停用账号就忽略可能已经完成的业务修改。

服务账户与人员授权之间保持可追踪关系，审计记录不能只出现机器人。撤销高风险工具的可用范围，关闭个人创建的外部回调和临时维护入口。任何删除、转交或凭据轮换都由具有对应管理权限的人确认，Agent 可以整理清单和草案，但不从“员工已离职”推导有权处理其所有资产。特别例外要注明到期时间与批准人。

用拒绝证据结束回收

验收至少包含新登录失败、旧会话失败、受限检索失败、工具调用失败、历史下载链接按策略失效和待处理任务已处置。也要证明在职接手人仍能完成获准工作，避免回收造成业务中断。用受控追踪号连接各系统证据，日志不保存真实令牌或私密资料。接口或缓存有传播延迟时，记录实际最长窗口并安排复查，不把未完成项写成已关闭。

回收清单应能由另一位管理员复核，缺少回收入口的系统标为待改造，不能仅凭供应商口头承诺。恢复备份或重新导入身份映射时还要防止旧权限复活，保留必要的停用事实与最新权限基线。人员调岗也适用同样方法，只是回收范围不同；定期演练能发现单纯账号列表看不到的残余授权。

接手人员的权限不能通过复制离职员工的全部角色建立，应按新岗位重新授予需要的范围。资产转交与权限授予分别审批，确认后再验证新负责人能完成必要任务，同时原身份无法继续使用历史会话和工具入口。

相关背景见流程自动化专题和项目运维问题，身份交接可读统一登录数据流。需要梳理企业 Agent 的回收链路，可通过定制咨询提供系统清单、身份来源与资产规则，明确传播验证和接手责任。