智能体在用谁的身份干活 重庆企业的智能体，很多不是 IT 部门装的。业务部门为了方便，自己申请一个模型 key，接上企业微信或表格工具，再让集成商配一个自动化流程，智能体就跑起来了。它用的是谁的账号、能访问哪些系统、离职后怎么停，往往没人说得清。Agent 身份治理听起来像安全部门的事，实际是每个用过智能体的业务部门都该回答的问题。读完本文，你可以拿到一份身份台账的精简字段，先把“谁在跑、用谁的权
智能体在用谁的身份干活
重庆企业的智能体，很多不是 IT 部门装的。业务部门为了方便，自己申请一个模型 key，接上企业微信或表格工具，再让集成商配一个自动化流程，智能体就跑起来了。它用的是谁的账号、能访问哪些系统、离职后怎么停，往往没人说得清。Agent 身份治理听起来像安全部门的事，实际是每个用过智能体的业务部门都该回答的问题。读完本文，你可以拿到一份身份台账的精简字段，先把“谁在跑、用谁的权限”查清楚。
五分之四在 IT 视野之外
2026 年 9 月 30 日，The Hacker News 刊出 Reco 的研究结果，标题说得很直接：五分之四个智能体在没有任何 IT 监督的情况下运行。报道把问题指向智能体的权限——安全团队没有审查过这些权限，也不知道它们能访问哪些 SaaS 数据。这个比例来自厂商的样本和方法，不能直接外推到每一家企业，但它指出的现象在重庆同样常见：业务部门先上线，IT 后知道，安全团队收尾时才发现权限已经铺开。
为什么会出现这种情况？因为智能体的接入门槛很低。过去接一个系统要立项、要接口、要安全评审；现在一个 key、一段脚本、一个低代码平台，半天就能跑通。门槛降低是好事，但身份管理没有跟着降低门槛——业务人员不懂 OAuth、不懂令牌生命周期、不懂权限边界，他们只想把活干完。
身份没管住，会出哪些问题
一是责任分不清。智能体借用某个员工的账号操作，日志里记的是这个员工，出了错却找不到智能体。二是权限撤不掉。员工离职、调岗，账号停了，但智能体用的长期 token 还在配置文件里，继续能访问。三是权限过大。为了方便，直接给管理员账号或全权限 key，智能体能读财务、能改库存、能发邮件。四是横向扩散。一个智能体被提示注入控制，攻击者可以借它的身份访问其他系统。
这四个问题不是理论风险。智能体的特点是一次任务连续调用多个工具，身份一旦被借用，影响面比单次人工操作大。Agent 身份治理的核心，不是给智能体起个名字，而是让它有独立、可撤销、可审计的身份，并且只拿到完成当前任务所需的必要权限。
MCP 认证在往前走
2026 年 10 月 2 日，Supabase 在 Select 2026 大会回顾里提到面向 MCP 的企业级托管认证，并与 Okta 集成。方向很清楚：把企业已有的身份体系接到 MCP 工具层，让智能体访问工具时走统一认证，而不是每个工具发一枚长期 token。对重庆企业来说，这意味着如果已经在用统一身份平台，有机会把智能体的工具调用纳入同一套账号、同一套策略、同一套审计。
但要注意阶段。这类能力还在早期，覆盖的工具和场景有限，配置也不简单。MCP 认证不是打开一个开关就完成，它涉及应用注册、权限范围、令牌刷新、回调地址、日志对接。没有 IT 参与，业务部门自己配不下来；IT 不参与需求，配出来的东西又不好用。身份治理要 IT 和业务一起做。
身份治理的五个动作
独立身份：每个智能体一个身份，不共用员工账号，不共用服务账号。身份要有负责人、用途、有效期。多智能体协同时，每个角色单独身份，方便追溯是哪一步出的问题。
短期凭证：用短期令牌替代长期 key，到期自动续期或重新授权。长期 token 只放在密钥管理系统里，不写进代码、不写进配置文件、不发在群里。令牌泄露时，短期凭证的暴露窗口更小。
权限从紧：按工具授权，不按系统授权。能查库存不等于能改库存，能读客户不等于能导出客户。写操作默认关闭，按任务临时开启，任务结束回收。智能体权限的审批记录要能查到。
可撤销：员工离职、项目结束、供应商更换，相关身份要能在一个地方停掉。撤销动作要有演练，不能等到出事才发现不知道怎么关。撤销后要有降级方案，避免业务直接断掉。
可审计：每次工具调用记录身份、时间、参数摘要、结果状态、任务编号。日志要能按身份、按工具、按数据对象查询，留存时间符合企业制度和监管要求。审计不是事后翻账，平时就要有人看异常。
搬到重庆要改什么
合规口径：等保 2.0 对身份鉴别、访问控制、安全审计有明确要求，智能体身份要纳入同一套体系，不能因为是“新东西”就例外。涉及个人信息的场景，还要考虑必要范围、授权同意、删除机制。生成式人工智能服务面向公众的备案要求，按实际业务对照。
组织口径：重庆不少制造企业有多个工厂、多个法人、多个外包团队。智能体可能由总部建、分厂用，也可能由集成商建、企业用。身份归属要按组织边界划清，跨组织调用要有审批和日志。外包团队离场时，身份要同步回收。
人员变动：离职、调岗、休假、借调，都会影响智能体的身份。人事系统和身份系统要能联动，至少做到离职当天停用。智能体的负责人变更时，权限要重新确认，不能自动继承。
成本与优先级：身份治理的投入不像买模型那样立竿见影，但它决定了后面能不能放心扩张。建议先做台账和撤销演练，这两件事成本低、收益直接；再逐步上短期凭证和工具级授权。
集成商和外包团队也是身份治理的一部分。他们建的智能体，交付时要移交身份、凭证、日志权限，不能只交一个账号密码。合同里写明离场后的回收责任，避免人走了、权限还在。
台账怎么落到系统里
台账不能停在电子表格。可行的做法是把身份信息同步到三个地方：身份提供商，每个智能体一个账号或一个工作负载身份；密钥管理系统，凭证不落地到代码；日志平台，调用记录按身份聚合。三处对得上，台账才是活的。每月自动比对一次：台账里有、身份系统里没有的，标记为待清理；身份系统里有、台账里没有的，标记为未登记。两类都要有人处理。
身份和权限要分开管
身份回答“它是谁”，权限回答“它能做什么”。很多企业把两者混在一起，给一个智能体一个账号，再把账号加进各种群组，权限跟着群组走，时间一长就说不清。建议按“身份—角色—工具权限”三层建模：身份只绑定角色，角色定义工具权限，工具权限按任务临时授予。改权限时改角色，不直接改账号，审计时能看清变更链。
四个常见误区
一是把服务账号当智能体身份。服务账号通常权限大、不过期、多人共用，出了问题无法定位。二是把 API key 写在配置文件里。代码一提交、镜像一打包，key 就跟着扩散。三是只用 IP 白名单。IP 能证明“从哪来”，不能证明“是谁”，智能体换一个出口就失效。四是以为上了 OAuth 就安全。OAuth 解决授权流程，不解决权限过大、令牌泄露、日志缺失。
还有一个误区是“内部系统不用管”。内部系统的数据往往更敏感，智能体一旦被诱导，能把内部通讯录、报价、工艺文件带出去。内部不等于可信，身份治理要一视同仁。
还有一种情况是“测试身份转生产”。测试时用的是一个宽权限账号，上线时图省事直接沿用，测试期的临时权限就变成了生产权限。上线前要做一次权限收口，把测试期加的权限逐项核对，能收的收掉。
三条红线
不让智能体使用管理员账号；不共享长期全权令牌；不在没有审计日志的情况下接入生产系统。三条都是底线，不是建议。AI 不签字、不承诺、不替代判断，身份治理的意义，就是让这句话在系统层面有支撑：谁做的、做了什么、能不能停，都能查得到。
可执行的起步动作
建一张 Agent 身份台账，字段包括：智能体名称、负责人、所属部门、使用场景、所用身份、凭证类型与到期时间、可访问系统与工具、上次调用时间、撤销方式、上次复核时间。先把业务部门自己接的智能体补进去，再补 IT 建的。台账完成后，挑一个离职或项目结束的场景做撤销演练，记录从决定撤销到实际失效用了多久。这个时间，就是企业身份治理的真实水平。
第二周把台账拿给安全和业务一起过一遍，重点看三类：用管理员账号的、凭证长期不过期的、三个月没调用但权限还在的。三类先处理，风险下降会很明显。
资料来源与口径说明
- The Hacker News《Reco Finds Four in Five Agents Run With Zero IT Oversight》，2026 年 9 月 30 日，刊载 Reco 的研究，属厂商安全研究报道。
- Supabase 博客《Supabase Select 2026 recap》，2026 年 10 月 2 日，介绍面向 MCP 的企业级托管认证与 Okta 集成，厂商一手材料。
- KPMG 2026 年相关报告提到，多数美国企业对自主智能体仍不放心，需要人工在环监督，属第三方调研材料，仅作背景。
说明：Reco 的比例来自其自身样本，不能外推为全部企业；Supabase 的能力描述属于厂商自述，实际配置以文档为准。本文不虚构重庆企业案例，台账字段可按企业规模裁剪。