停用 AI 助手後，還要關閉哪些服務、收回哪些權限？

简介： 企业AI试点结束≠权限自动失效。入口关闭、订阅停用后，服务身份、API凭据、事件订阅等仍可能持续生效。76%“闲置Agent”凭据60天未用却仍有效，暴露退出管理盲区：需明确责任主体、分系统回收权限、区分暂停与终止、保障业务交接与审计追溯。

企业结束一个 AI 试点，通常很容易找到一个看得见的动作：关掉入口，停止订阅，告诉团队暂时不用了。

但在业务系统看来，这些动作未必意味着同一件事。那个助手对应的身份可能仍然存在，访问凭据可能仍然有效，原来接收事件的地址也可能继续收到请求。

10月22日，Arrakis Security 发布新闻稿，介绍其客户环境中数千个 Agent、持续12周的匿名生产遥测结果。

按新闻稿所用的“active agents”（活跃 Agent）口径，其中76%已60天未运行，但凭据仍可使用；公告没有进一步解释这一分类。这是厂商对自身客户样本的观察，完整报告方法尚未取得，不能据此推算整个行业，也不能认定这些权限已经被滥用。

这里的“未运行”不代表管理员已经停用或卸载了助手。闲置与正式退场需要分别判断。但它提出的问题值得每个接入 AI 的团队回答：业务已经不再需要这项工作时，谁来决定原来的授权是否还应该继续存在？

没有人再使用它，并不代表没有东西再调用它。

设想一个明确的假设场景：一家零售企业试用库存助手，让它读取三个门店的库存，根据缺货情况生成调拨建议，并在店长确认后提交调拨申请。它还订阅了库存变动事件，每晚会自动生成一份汇总。

试点一个月后，团队决定结束试用。产品负责人关闭了聊天入口，采购停掉了模型套餐，大家开始评估另一套方案。

这些动作完成了各自负责的收尾，却没有天然覆盖库存系统中的服务身份、调拨申请权限、事件订阅和夜间任务。入口不再出现，只能说明员工不能从那里发起对话。是否还有其他路径能启动同一套流程，需要另外核对。

即使模型已经不能调用，也可能有不依赖模型的定时步骤、待重试请求或下游流程继续运行。反过来，一条事件能唤醒流程，也不代表它必然能够越过库存系统的权限检查。

因此，“助手已经停用”需要说明停掉了什么。模型、界面、任务调度、业务连接和服务端授权，分别由不同的系统掌握，任何一处显示关闭，都不足以替其他环节作出承诺。

暂停要保留恢复的条件，退出要结束原来的委托。

库存助手暂时不用，也可能完全合理。企业每季度盘点一次，或者等待旺季再启用，长时间没有运行本身并不能证明授权不合理。

60天可以是一次复核的线索，不能直接变成所有助手的删除期限。是否继续保留，要看原来承担什么业务、下一次何时需要、负责人是否仍然认可，以及保留期间还有哪些可执行路径。

可恢复的暂停，应当保留明确的恢复条件。例如，试点暂停到下季度评估，期间不接收新的自动任务，保留配置和历史记录；恢复前重新确认门店范围、业务负责人和所需权限。暂停期间是否保留某项访问能力，也应有具体理由和期限。

正式结束则意味着原来的业务委托已经终止。为了以后可能再次使用，可以保存模板、配置说明和经过适当处理的经验，但没有必要因此默认保留全部有效凭据。

重新接入有一点成本，长期保留权限也有成本。选择前者还是后者，可以由业务判断；关键是把“以后方便”变成一项有人负责的决定，而不是无人处理的默认状态。

恢复时，旧配置也不能直接证明今天仍然适合使用。三个门店的管理关系可能已经变化，原来的确认人可能调岗，调拨申请的流程也可能更新。保存一份能够重建流程的说明，与保留一条无需复核就能继续行动的通道，承担的责任并不相同。恢复应该重新核准必要条件，不能自动复活已经结束的委托。

退出登录同样需要区分。它可能只结束当前会话；授权服务器是否同时撤销令牌、业务系统是否关闭服务身份，要看具体实现与约定。即使撤销了刷新令牌，已经签发的访问令牌是否立即失效，也取决于各接收端的校验和撤销机制。已有 OAuth 标准也分别讨论令牌撤销、有效状态查询和闲置刷新令牌的期限，没有替企业规定所有业务共用的退场日期。

真正容易消失的是负责人。

试点开始时，责任通常相当清晰。业务负责人提出需求，技术人员建立连接，安全或系统管理员批准权限，采购负责套餐。

结束时，大家却可能各自完成了自己的动作：业务说不再使用，技术说入口已关，采购说费用已停。最后仍然有效的那部分授权，恰好落在几项工作之间。

问题因此不只是少了一个删除按钮。企业需要有人对“这项委托是否继续成立”作出决定，也需要相应系统的管理者执行决定，并留下能够核对的结果。

在库存助手的例子里，业务负责人应当确认试点结束以及尚未完成的工作如何交接。库存系统管理员处理服务身份和操作范围，集成维护者处理事件订阅与调度。一个人可以承担多项职责，但每项职责都需要落到实际能完成它的身份和系统。

如果原负责人离职，服务身份不会自然跟着离职。组织应当能够找到接任者；无法找到时，至少要把相关连接列为责任待确认，按既定策略限制后续使用。不能因为没人愿意承认还在使用，就把它认作已经安全退出。

这种责任也不适合只交给创建助手的人。试验者可以离开项目，企业对业务系统的授权仍然存在。谁能批准继续保留，谁就应当承担相应的复核责任。

保留决定还应当允许复查。需要保留的人能够说明下一次用途、范围和期限，负责执行的人能够找到对应连接，后来的管理员才不必依靠猜测维持它。责任有明确落点，权限才不会仅仅因为曾经开通过，就一直存在。

撤权只能处理权限，不能抹去已经发生的业务。

假设试点结束时，库存助手已经向库存系统提交了一笔调拨申请，但还没有收到明确结果。此时撤销它的后续访问权限，并不能据此判断这笔申请没有提交成功。

如果业务系统已经受理，后面的审批或出库可能由业务系统继续完成；如果请求尚在队列里，则要看队列的控制方式以及执行时是否重新校验。不能把所有在途任务都归为“关掉助手以后自然消失”。

正常退出应当处理这段交接：从哪个时间起不再接受新任务，已有任务允许完成、取消还是转交，谁负责查询结果。一个尚未核实的请求，应当通过原任务标识和业务记录查清，不能为了得到一个确定答案就重新提交。

有些任务无法安全取消，只能等待结果；有些可以取消，但取消请求本身也需要得到确认。记录里保留“结果待核实”，会比笼统写成“全部停止”更便于接手。

如果调拨单已经创建，甚至商品已经出库，撤权也不会把库存自动改回去。后续是否撤销单据、退回商品、调整账目，需要依照业务规则，由仍有相应权限的人处理。

这就是授权收回与业务补救的区别：前者约束此后的行动资格，后者处理已经形成的后果。两件事可能都需要做，但不能让其中一个状态代替另一个。

若已发现凭据泄漏等紧急情况，处置顺序又会不同，可能需要先阻断相关访问，再追查在途任务和影响。正常退场允许有序交接，并不意味着异常情况下也必须等所有工作收尾后才能撤权。

免费的闲置权限，也有持续成本。

一条不再调用的连接，可能没有明显的模型费用，却仍然需要维护：密钥到期要处理，业务接口升级要确认，负责人变更要交接，权限复核时要解释它为何存在。

当企业有几十个试点，每个试点留下几条这样的连接，后来的人就要反复判断：这是正在等待旺季的服务，还是已经结束却没人收尾的试验？贸然关闭可能影响业务，继续保留又无法解释必要性。

成本往往出现在不确定性上。没有留下结束决定和交接记录，下一次清理就需要重新找人、翻聊天、查日志。所谓“先留着，以后再说”，只是把今天的决定推给更缺上下文的人。

保留也并非总是不经济。一个每季度运行的助手，如果有明确负责人、限定范围和定期复核，保留必要连接可能比反复重建更合适。真正需要比较的，是持续维护和暴露的代价，与未来恢复所节省的代价。

因此，评估 AI 试点的投入时，也应该估算退出成本。接入只需十分钟、退场却需要逐个系统找管理员的方案，便利性并没有覆盖完整生命周期。权限和业务身份越混杂，后面的收尾通常越难解释。

退出应该成为接入时约定的交付。

对于库存助手，团队在开始试点时就可以约定结束日期，指定负责人，记录它使用哪些业务身份、连接和自动触发方式，说明结束后如何处理任务与记录。

这不要求先建立一套庞大平台。即使只有一份简短登记，也应当让接手的人看懂：哪些授权属于这个试点，哪些连接与其他业务共享，什么可以独立撤销，什么必须先迁移。

如果几项自动化共用一个管理员凭据，删除试点配置只能减少一个使用入口；凭据继续有效，也可能无法确认是否存在其他副本。需要根据实际情况把依赖迁移到可区分的身份，再撤销或轮换原凭据，不能凭一次界面删除就宣告全部完成。

退出验收同样要看接收系统的结果。平台显示已发送撤销请求，可以证明动作已经发起；相关授权是否失效，还需要结合授权端状态、业务系统的检查机制和适当的验证确认。

在安全的测试条件下，可以核对旧身份的只读或专用测试请求是否被拒绝，事件入口是否停止接收，以及是否仍有未结任务。不要为了证明不能调拨，就向真实库存反复提交写操作。

不同系统可能存在状态传播或缓存窗口。退出记录应说明验证时间、已覆盖范围和仍待确认的部分，使下一位负责人知道从哪里继续。无法接入某个业务系统的撤权机制，就明确记录需要它的管理员处理，而不是把平台侧的关闭扩写成全局保证。

权限结束以后，必要的业务记录和审计证据仍可能需要保留。保留什么、保留多久、由谁访问，应遵守对应的业务与数据规则。审计所需记录与不再需要的私密缓存、凭据副本应分别处理，不能把密钥当成普通日志长期保存。为了避免留权限而删除全部历史，同样会让尚未解决的问题失去依据。

一个退出得清楚的库存助手，应当让接手者知道：原委托已经结束，哪些后续访问已被拒绝，哪些任务完成了交接，哪些结果还需要处理，以及未来重新启用必须重新确认什么。

这也是我们讨论 Agent 进入业务系统时关心的责任连续性。ACC 提供能力范围、风险和主体要求等声明方式；BailingHub 的公开实现把可信调用上下文、执行控制与回执连接起来，业务系统保留最终授权判断。这些已有机制可以成为生命周期设计的基础，本文讨论的跨系统退出协调、触发器下线和完整退场验收，仍需要各接收系统与组织流程共同实现。

当企业能够清楚结束一项委托，下一次接入 AI 时，才能更准确地知道自己交出了什么，也知道这些责任将怎样收回。