智能体有了权限后，企业还缺一张“身份退役卡”

一个客服智能体上线时，团队通常会认真讨论：它能读哪些知识库、能否查询订单、什么情况必须转人工。但六个月后，如果业务负责人换岗、活动页面下线、连接器被新系统替代，这个智能体的权限会发生什么？最容易被忽略的风险，不是它申请权限的那一刻，而是它已经不再承担原任务，却仍像一个“在职员工”保留着通行证。

8月26日，AWS Partner Network 发布 SailPoint 面向 Amazon Bedrock AgentCore 的智能体身份治理实践。文章将现实问题说得很直白：自主智能体会访问敏感数据、动态请求权限并执行动作，但传统 IAM 多为人类用户和服务账号设计，难以天然覆盖跨系统、可自主行动的智能体。其方案强调持续发现、明确所有者、定期访问复核和必要时撤销权限。

我更愿意把智能体看成一份“会变动的数字岗位”：它不仅要有开通单，也必须有转岗、复核和退役机制。

一、权限正确，不等于身份还有效

企业常把权限治理理解为一次配置：给智能体限定工具、角色和数据范围。这个动作当然必要，但它回答的是“它此刻能不能访问”。身份治理还要回答另一层问题：“它是否仍应存在、仍由谁负责、仍在为哪个业务目标工作？”两者一旦脱节，最小权限也可能变成长期闲置权限。

SailPoint 在 8 月的产品说明中引用自身调研称，97%的 AI 智能体可访问敏感数据，而仅 21% 的组织对管理其安全风险“高度有信心”。这组数据是供应商引用的调研结果，不能外推为普遍行业比例；但它提示了一个实务盲点：企业知道“系统里有多少员工账号”，未必同样清楚“有多少智能体、挂着谁的责任、最后一次复核是什么时候”。

二、给每个智能体补齐四个生命周期节点

第一是发现：不只登记正式项目，也把试验脚本、IDE 助手连接和 MCP 工具纳入视野。第二是归属：每个智能体必须同时有业务负责人和技术负责人；前者确认任务还存在，后者维护模型、工具和运行质量。第三是复核：把权限、数据来源、触发频率、近期调用证据与业务指标放到同一次复核中。第四是退役：业务取消、负责人离开、连接器替换或风险异常时，应有冻结、迁移、删除凭证和留存审计记录的固定顺序。

这不是为了给每个小工具增加审批负担。恰恰相反，若企业把低风险的试验智能体也纳入轻量登记，就能避免它们在本地配置、共享密钥和临时授权中“野生长大”。正式投入生产后，再随风险等级增加审批、凭证轮换、人工确认和退役门槛。治理不该以一个巨型表单开场，而应随着智能体的影响面逐步升级。

三、退役不是删除机器人，而是收回一组关系

真正难的不是停掉一个运行实例，而是清理它与组织之间的关系：谁是它的委托人，哪些知识或客户数据仍需保留，哪些 API 令牌要立即失效，哪些自动化流程要改由人或新智能体承接。AWS 的案例也强调，对智能体身份应保留名称、角色、权限和关联资源等元数据；这说明退役对象从来不是单一账号，而是一张跨数据、工具、职责和业务流程的关系网。

因此，企业可以在退役前问三句话：它最近一次真正完成的业务价值是什么？停掉它会断开哪些受控动作？留存的知识、日志和凭证分别由谁接手？只有这三句话有答案，停用才不是一次盲目的关机，而是一次可恢复、可追溯的岗位交接。

STARBOX视角：把“身份退役卡”放进日常运营

在 STARBOX 的组织—BOX—智能体三层里，我会新增一张“身份退役卡”。组织层定义智能体的业务委托人、技术负责人、复核周期、风险等级与停用触发条件；BOX 层沉淀任务目标、知识来源、工具授权、调用证据、交接对象和保留规则；智能体层只在当前有效的身份与权限内行动。DDABC 则把人工接管、低使用率、越权拒绝、负责人变更和停用原因回写，让“什么时候该退役”从临时判断变成可学习的运营信号。

这张卡并不替代此前的授权接力或过程权限卡：授权接力解决“它替谁访问”，过程权限解决“它在任务走到哪一步还能做什么”，身份退役卡解决“它还是否应继续作为一个组织角色存在”。三者合在一起，才让智能体从一次性项目变成可被持续经营的生产力资产。

结语

企业部署智能体的速度会越来越快，但真正成熟的标志，不是目录里新增了多少个 Agent，而是组织能否平静地回答：它们分别为谁工作、何时复核、什么条件下应该退出。为智能体补上一张身份退役卡，往往是把“能跑起来”推进到“能长期放心运行”的关键一步。