员工离职权限治理，不是在人事系统点“离职”就结束。企业常见遗留包括业务系统账号仍启用、共享群组未退出、客户或项目仍归属原员工、API Token 继续运行、定时任务没有新负责人。Agent 适合做跨系统核对，但删除和转移必须受控。
从一个人员对象展开七类清单
| 类别 | 核对内容 |
|---|---|
| 身份账号 | 统一登录、邮箱、IM、VPN、云平台 |
| 业务角色 | CRM、ERP、财务、项目、审批权限 |
| 群组与空间 | 部门群、项目群、知识库、云盘 |
| 凭据 | API Token、密钥、共享账号、机器人 |
| 设备 | 电脑、手机、门禁、证书与本地数据 |
| 业务对象 | 客户、商机、项目、待办、审批代理 |
| 自动任务 | 定时任务、订阅、通知、集成流程 |
清单必须结合岗位、部门和实际授权生成，不能假设同岗位所有人的权限完全相同。
先完成交接，再执行不可逆动作
客户、项目、知识和待办需要明确新责任人；个人创建的自动任务要决定转移、停用还是重建；业务证据按规则保留。没有完成交接时直接删除账号，可能让后续找不到来源和处理人。
高风险动作应按影响分批确认。禁用登录、撤销高权限和轮换共享凭据可以优先；数据删除、邮箱处置和文件所有权转移要按企业政策执行。
写后回读证明真正生效
调用“禁用用户”接口成功，不代表所有旧会话和令牌立即失效。Agent 应重新查询账号状态、角色列表、有效令牌、群组成员和资源归属；无法通过 API 验证的系统进入人工核对队列。
写后回读方法见Agent 写后为什么必须回读，连接器撤销见AI 连接器怎么管。
把例外留给有权人判断
长期顾问、返聘、停薪留职、诉讼保全和特殊审计可能需要不同处理。Agent 只能根据明确规则分流，不能凭“离职”标签自动抹除全部数据。
验收时随机抽取离职人员，从人事终态反查所有连接系统，确认登录不可用、敏感权限已撤、共享凭据已轮换、业务对象有新责任人、自动任务已处置、必要证据仍可审计。需要连接组织、审批、知识与业务系统，可继续了解企业知识中枢与钉钉服务。
离职时间决定动作顺序
立即离职、正常交接、合同到期和内部转岗的处理不同。系统应以生效时间编排动作：高权限和外部访问何时停止，邮件与文件何时转移，客户和项目何时换负责人。提前全部禁用会阻断交接，延后过久又扩大风险。
对于内部转岗，不应照搬离职流程。保留新岗位需要的基础账号，撤销原部门和原项目权限，再按新角色重新授权，避免权限只增不减。
共享凭据是最容易漏掉的角落
写在脚本、浏览器、机器人、自动化平台和团队密码库中的凭据，不一定挂在个人账号下。离职清单应根据代码仓、连接器、定时任务和最近使用记录生成轮换候选。轮换前先确认依赖，避免一个密钥变更让整条业务链停摆。
业务归属转移不等于改写历史
客户和项目需要新的当前负责人，但历史订单、审批、回款和操作记录仍应保留原事件责任。系统要区分“当前由谁负责”和“当时由谁完成”，不能批量把历史都改成接手人。
建立入转调离同一套生命周期
离职核对暴露的问题，往往源自入职和转岗时没有统一授权模型。长期应把岗位基线权限、临时项目权限、个人授权和高风险例外分开；入职按需授予，转岗做差异，项目结束自动复核，离职完成收口。
每次流程结束生成可读报告：执行了什么、哪些由人确认、哪些仍待外部系统处理、何时复查。没有终态回读的“已完成清单”不能作为真正验收依据。
