智能体停用了，钥匙该交给谁

一、七成多的智能体，两个月没跑过

一份 2026 年 10 月公开的安全报告里，有一个数字值得停下来看：在被抽查的已启用智能体（能自己调用工具、替人跑完一段任务的程序，下面都这么叫它）中，76% 超过 60 天没有运行过，但这些智能体的密钥仍然有效。

两个月没跑，多半是项目停了、试用结束了，或者换了一个新版本。人走了会办离职，账号会停；智能体停了，却很少有人想到去把它的钥匙收回来。

二、停用的智能体，为什么还开着一把钥匙

智能体通常不是一个人。

它要有自己的账号、密钥，才能读文档、查数据库、发消息。很多团队在搭的时候，直接拿一个现成的服务账号，或者某个员工的密钥先用起来。

项目上线那几天，这样最快。项目结束以后，那个账号还在，密钥还能用，只是没人再提起它。

一个常见的场面是：客服机器人、报表机器人、发邮件的脚本，三个东西共用一个服务账号。某天要停其中一个，才发现停不了。停账号，另外两个也停；不停，那个已经不用的一直开着。

三、人和机器用的是两套离职流程

人的离职有流程：交卡、停账号、转交工作。机器的离职没有。

HR 的系统里没有「智能体」这一栏，资产清单里也常常没有它。它既不算员工，也不算服务器，夹在两套流程中间。

一份 2026 年的身份报告调查了 508 家千人以上企业的 IT 与安全负责人：95% 已经在运行能自主执行任务的智能体，47% 说机器身份数量已经超过员工人数，只有 22% 能完整看到这些身份。

看不清，就收不回来。

四、一个智能体要回答四个问题

它是谁，代表谁，能碰什么，到哪天为止。

它是谁，指它有没有独立身份，而不是借某个人的账号。代表谁，指它替哪个部门、哪个业务跑任务，出了事找谁。能碰什么，指它能读哪些数据、调用哪些接口。到哪天为止，指它的授权什么时候到期，谁来续。

这四个问题答不上来，它就不该被放进生产环境。

五、独立身份不是为了好看，是为了能单独停

如果智能体借用的是某个员工的账号，停它就会连带停掉那个人；反过来，那个人离职，智能体也跟着断。

更麻烦的是日志。出了事，你看到的是员工账号在操作，分不清是人还是程序。

给智能体单独发一个身份，日志里就能分开；停用时也只动它一个，不影响别人。

六、权限按任务给，按到期收

一个只负责整理会议纪要的智能体，不需要数据库的写权限；一个只读内部文档的助手，不需要发消息的权限。

授权时把范围写窄，把期限写短，到期自动失效，比事后追查有效。

Gartner 在 2026 年 11 月公开的 2027 年趋势里，把「AI 智能体身份」列进了十大方向，并预测到 2028 年，25% 的企业安全事件会追溯到智能体被滥用。它给的原因很直接：机器权限没有管好，还在用管人的老办法管机器。

七、谁建、谁批、谁收，三个名字要写下来

建的人通常是写代码的，批的人通常是业务负责人，收的人通常是运维或安全。三件事可以是一个人做，但名字要落到一张表上。

没有名字，就没有人对「它还开着」这件事负责。等安全扫描报出来，往往已经开了半年。

八、盘点先做一张表，字段不用多

身份名称、归属部门、用途、能访问什么、最后使用时间、到期日。

最后使用时间这一栏最有用。超过 60 天没调用，就进入待确认；超过 90 天，默认停用，要用再申请。

这张表不需要买新系统，先用表格跑一个季度，比等工具上线快。表放在共享盘，由运维或安全每季度拉一次；新增智能体时，建的人先填一行，再申请权限。

九、停用分三步，顺序不能反

先停调用，再收权限，最后删身份。

先停调用，是让它跑不起来；再收权限，是把能打开的门一扇扇关上；最后删身份，是把这个名字从系统里去掉。

反过来做，先删身份，可能留下还在跑的定时任务，日志也对不上。

停调用之前，先看有没有正在跑的长任务。有，就等它跑完，或者手动终止，再收权限。

每一步留一条记录：什么时候停的、谁批的、有没有正在跑的任务被中断。

十、员工离职时，顺手查他名下的智能体

很多智能体是员工自己搭的，用的是自己的账号授权，或者挂在自己的项目下。人走了，智能体还在替他跑。

离职清单上加一行：名下有没有智能体、有没有还在用的密钥、要不要转交。

这一行不增加多少时间，但能挡住最常见的一类遗留。

十一、第三方平台上的智能体，也要算进名单

在 SaaS 平台、自动化平台上搭的智能体，身份不在公司目录里。停用公司账号，不等于平台上的智能体也停了。

采购或续约时问一句：这些智能体用什么身份运行、能不能导出清单、成员离职后怎么处理。

合同里写上退出时的数据与身份清理，比事后找客服快。

十二、日志要能回答「它上次做了什么」

不只是「它登录过」。

记录调用时间、调用了哪个接口、读了哪些数据、结果成功还是失败。出了事，能还原它碰过什么；平时，也能看出它是不是在做职责之外的事。

日志保留期限和访问权限，按数据的敏感程度定。不要把所有日志都留给所有人看。

十三、出了事，先查哪几个字段

智能体名、用的哪个身份、能访问什么、最后一次调用是什么时候、结果是什么。

先停这个身份，不要先停整个平台。停平台会波及正常业务，也会让日志断掉，后面更说不清。

它的调用记录和配置先留着，别急着删。删掉以后，它碰过什么、跑过几次，都只能靠回忆。

十四、续期不是点一下同意

到期前一周提醒，续期时重新回答四个问题：还在用吗、用途变了吗、权限还要这么多吗、负责人还是不是这个人。

四个问题里有一个答不上来，就先不续。连续两次没人确认，默认停用。

续期记录要留档。它证明的不是「批过」，而是「到期时有人重新看过」。

十五、小团队先做三件事

第一件，把现在在跑的智能体列出来，超过 20 个就先列前 20 个，写上归属人和最后使用时间。

第二件，给每个智能体定一个到期日，最长 90 天，到期前一周提醒续期。

第三件，员工离职清单加一行「名下智能体与密钥」，由直属负责人确认。

这三件事不花钱，但能把「没人用的智能体还留着钥匙」这一类问题先收掉。

十六、这套做法跟站内几篇的分工

「智能体的权限，加上去谁收回来」讲的是权限怎么加、怎么减；「谁能进你的系统，这份名单谁签过字」讲的是人的入口名单；「智能体跑起来，谁按得下停止键」讲的是出事时怎么停；「接了第二家模型，中间那一层谁来管」讲的是模型入口怎么收口。

这一篇只讲一件事：智能体不用了，它的身份和钥匙怎么收。

十七、最后一条：机器的离职手续，也得有人办

人会退休、会跳槽、会换岗，系统里有一整套动作等着他。智能体不会提离职，它只会在某一天不再被调用，然后安静地留在名单外。

把它当成一个需要入职、也需要离职的成员，给它身份、给它期限、给它一个负责的人。做到这三样，再谈它能替公司做多少事。