正在加载，请稍候
企业智能体该用谁的凭证调接口？三种身份模式的差别不在安全强度，而在出事那天你能不能说清谁批准、谁执行。
10 月 8 日谷歌云发布企业级智能体时，给它配的是独立企业邮箱、独立日历与 Drive 空间；它在 Workspace 里执行操作留下的审计记录归到自己名下，而不是某个员工名下（钛媒体，2026-10-09）。厂商正在替你回答一个你早晚要自己回答的问题：这个智能体用谁的凭证去调接口。
共享服务账号把权限集中在一个长期凭证上，日志里只留下服务账号的名字，你既分不清是哪个智能体在动数据，也说不清是谁授权的。这类账号通常有三个特征：凭证有效期以年计、权限只增不减、依赖它的流程没人敢停。真正的代价不在平时，而在事故调查那天——日志里只有 service-account-01，接下来的问题一个都答不上来。
更少被讨论的是，权限边界过宽本身会变成攻击路径。安全厂商 Silverfort 的研究者 Noa Ariel 披露，Entra 里用于管理智能体身份的内置管理角色，可以被用来给租户内任意服务主体添加 owner——包括与智能体无关的应用；拿到 owner 之后就能签发新的客户端密钥，冒充目标服务主体（CSA 研究笔记，2026-04-28）。结论很直接：智能体身份的管理权限要单独最小化，不要复用现有的应用管理员角色。站内此前也整理过一份企业智能体安全的补法清单，凭证与身份正是其中最容易被跳过的一层。
企业智能体的身份只有 3 种落法：共享服务账号、专属身份、代表用户委托，差别不在安全强度，而在事故责任能否归到具体一方。下表按 5 个维度拆开对比。
| 维度 | 共享服务账号 | 专属身份 | 代表用户委托 |
|---|---|---|---|
| 日志里的行为主体 | 服务账号名，分不清是哪个智能体、哪次任务 | 智能体身份本身 | 用户与智能体两条线都在 |
| 权限最小化 | 只能按系统整体授权，scope 容易越滚越大 | 可只授予它需要的工具与资源 | 上限等于该用户已有的权限 |
| 吊销路径 | 一改就牵连所有依赖它的流程 | 停用或删除该身份即可 | 撤销用户授权或该次委托 |
| 事故爆炸半径 | 最大，共用者一起被牵连 | 限定在自身的 scope 内 | 与用户权限等同 |
| 适用场景 | 存量系统的过渡期 | 后台常驻、无人值守的长任务 | 需要「以我名义」办事的助手 |
微软官方文档把这层区别写得很直白：普通服务主体是为「静态、确定性的工作负载」设计的，直接用自身凭证运行；赋予智能体的身份则增加了一层委托模型——由 blueprint 代表每个智能体获取令牌，支持一对多的 blueprint 关系，要求指定一名 sponsor，并生成专属的审计条目（Microsoft Learn，2026-04-30）。「要求指定 sponsor」这条最能说明厂商的判断：智能体不是一条配置，而是一个有人负责的对象。同一份文档还区分了两类责任人——owner 负责技术管理，sponsor 对它的用途与生命周期决策负责（Microsoft Learn）。
判断标准可以简化成一句话：出事那天，你要能答出「谁批准的、谁执行的、谁付的钱」。哪个模式能让你答全，就用哪个。
2026 年 10 月这轮发布里，身份与权限是被厂商单独列出的产品能力，而不是留给客户自己拼的安全配置。谷歌云在 Gemini at Work 2026 的官方发布说明中，把「身份与策略管理、授权与权限控制、安全沙箱、网络网关」与「多模型编排、Smart Routing、实时支出上限」并列为发布项（Google Cloud 官方博客，2026-10-08）。同一篇公布的规模数据也解释了治理为什么会被前置：过去一年有近 500 家客户各自处理超过 1 万亿 token，近 90% 的财富 100 强客户在使用 Gemini Enterprise。
委托模式不只是纸面概念。Gemini Enterprise 在 10 月 6 日的版本说明里开放了 federated query 模式（预览版）：通过 MCP，使用每个用户自己的凭证就地查询 AlloyDB、BigQuery、Cloud SQL、Spanner，不把数据复制进数据仓（Gemini Enterprise 版本说明，2026-10-06）。这是 delegated access 在生产产品里的落脚样本——权限跟着人走，而不是跟着一个共享账号走。
专属身份这一路，谷歌的做法是把它做进 Workspace：独立企业邮箱、独立日历与 Drive、独立通讯录条目，操作进入审计记录而不是记在员工名下；代码在隔离环境运行，网络出口经 Agent Gateway 受企业策略约束，并可设置项目级实时支出上限。支出上限为什么值得单独设，站内算过一笔账：智能体进企业的第一笔失控账通常出在用量上。需要说清楚的是，该产品目前面向企业客户开放私有预览，尚未公布正式商用时间与定价（钛媒体，2026-10-13）。
微软的对应物是把智能体做成 Entra 里独立于普通应用身份的目录对象——在服务主体基础上新增一种子类型，由专属管理员角色维护，该能力目前处于预览阶段（Microsoft Learn）。三家指向同一结论：身份正在从基础设施的配置项，变成智能体能否通过企业采购评审的前提条件。
下面这份清单是我们在 AI 应用与定制开发交付中使用的参考项，不是已完成的客户项目复盘，你可以按自己的系统改造：
本站案例库截至今日已发布的交付案例共 7 个，其中人工智能方向 2 个、企业服务 2 个、教育培训 2 个、文旅消费 1 个。这个样本量不足以支撑任何行业结论，写出来只是为了一件事：身份与授权属于「可交接运维」清单里的项目，不属于上线之后再补的安全配置。我们在给企业做 AI 应用与软件定制开发交付时，倾向把身份模式的选择提前到需求评审，而不是留到安全加固阶段（了解我们的交付方式）。
从专属身份起步最省事：它不需要改造现有用户体系，只要能被单独停用、日志能落到它自己身上，就比共享服务账号安全一个量级。等出现「必须用我的权限办事」的需求，再为特定场景加委托模式。
不是。委托身份让智能体的权限上限等同该用户的权限，用户权限越宽风险越大；它的真正价值在归因——能同时说清谁批准、谁执行。用在读多写少的助手场景最合适，用在能删数据的后台任务上要慎重。
把智能体身份与员工个人身份解耦，责任人用角色而非某个具体的人挂靠，离职时只更换 sponsor、不停智能体。反过来，如果它拿的是员工个人凭证，那人一走，凭证就成了无人认领的悬空权限。
先看现有 IAM 能不能做到三件事：单独发凭证、单独停用、单独归因。做不到再考虑专用能力，并且要注意 Entra 这类身份服务目前仍处于预览阶段，不建议作为唯一依赖。