AI 智能体有了自己的账号，负责人离职后谁来关权限？
当智能体能以自己的身份收邮件、改文档、调用系统，企业需要把“谁让它干、能干到哪、谁来停”说清楚。
新变化：它开始像一个独立账号
Google Cloud 在 2026 年 10 月的产品公告中介绍了团队使用的 coworker agent：它可以有自己的 Workspace 账号，包含邮箱、日历、Drive 和公司目录身份。Google 称，这类智能体以自己的身份行动，访问范围随团队分享和群组成员关系而定；其动作也可归到智能体身份的审计记录。这是Google 对自家产品能力的描述，不能据此推断所有智能体产品都有这些功能，也不能推断它们在中国企业已可购买或部署。
“给 AI 一个邮箱”本身不是目标。邮箱、文件和接口权限一旦跟着智能体长期存在，人员调岗、离职或项目停用时，就会出现一个具体问题：人走了，谁负责处理还在运行的账号和授权？
用一张账号卡管住试点
下面是本站给企业试点的检查建议，不是通用行业标准。用一个真实但已脱敏的业务流程填写，空白处先由业务负责人和现有 IT／安全管理员一起核实。
- 谁负责：写业务负责人和接替人。智能体可以有独立身份，但不能没有人对它的任务和权限负责。
- 它能碰什么：逐项列出邮箱、文件夹、系统接口及读写权限。不要把“能读资料”和“能改数据、发消息”混成一个授权。
- 谁批准关键动作：列出对外发送、删除、修改业务记录等动作的审批人和触发条件；在授权测试环境里验证规则是否真的生效。
- 到哪里查记录：确认谁发起了任务、智能体以什么身份调用了什么系统、谁批准了操作。只看聊天记录无法替代系统的权限与操作日志。
- 怎么暂停和交接：负责人调岗、离职或试点结束时，谁能暂停任务、撤销授权、处理账号里的文件和日程，并保留必要的历史记录？让管理员在测试环境演示一遍。
为什么要把“停用”写进上线条件
Microsoft Entra Agent ID 文档把智能体身份与普通员工、应用身份区分开：有些智能体按任务动态创建和销毁，退役时需要避免遗留凭据和权限。Alibaba Cloud Agent ID Guard 文档则分别讨论“谁能调用智能体”和“智能体能调用哪些下游服务”，强调调用链要能追溯。这些是不同厂商的产品文档，功能边界各不相同；它们共同提示买方核对身份、授权、调用链和撤销机制。
例如，一个活动协调智能体由市场经理创建，能读取活动日历并在团队群里回复。经理调岗后，如果没有接替人，群成员与文件分享范围可能继续变化。这是一个假设情境，不是已发生的客户案例。试点时应实际测试：换负责人后原授权是否继续有效，管理员能否暂停，历史动作还能否查到。
下次看演示，直接问这三句
“负责人调岗时，谁能看到并撤销它的权限？”
“现在暂停它，邮件、文件、日程和操作记录分别怎么处理？”
如果供应商暂时做不到独立身份，也可以先在低风险流程试点，但要明确谁的账号在执行、权限如何隔离、异常时如何停用。相关的供应商现场验货问题检查的是交付能力；内部准备清单检查负责人和验收条件。本文补上智能体账号从启用到停用的交接问题。