切换深色模式
AI Agent 身份认证调研：给 Agent 办“身份证”，也管住它手里的权限
调研基线：2026-08-23
资料范围：Agent 自身身份、用户委托、工具/MCP 访问、Agent-to-Agent 认证、凭证管理与审计。
资料原则：优先采用厂商官方文档、正式标准和协议规范；Preview、Internet-Draft 与推断均单独标注。
导读：本文要解决什么
小傅哥的技术文章通常先说“本章诉求”，再从一个能运行的场景入手，接着讲流程、架构和工程实现。本文参考这种组织方式，重点借鉴 AI Agent 业务流程与系统架构 和 给 MCP 服务加上安全认证 的讲解思路。
不过要先说明：博客用于帮助理解和动手实践，厂商能力、协议状态和安全结论仍以本文链接的官方资料为准。
读完本文，应该能够回答下面五个问题：
- 为什么普通 API Key 和服务账号不够保护 AI Agent？
- 用户身份、Agent 身份、运行环境身份到底有什么区别？
- Agent 代表用户办事和自主运行，认证链路有什么不同？
- Microsoft、Google、AWS、阿里云等厂商分别解决到了哪一层？
- 如果公司要落地，系统要拆成哪些模块，先做哪几步？
先看一个典型场景：公司上线了“采购 Agent”，它能读取邮件、查询合同并创建付款单。为了省事，开发者给它配置了一个拥有采购系统全部权限的长期 API Key。某天，供应商邮件里藏了一段提示注入，诱导 Agent 把其他供应商合同上传到外部地址。
这个事故里，Agent 很可能已经“认证成功”了，但系统依然不安全，因为它没有回答：
- 这次到底是哪个 Agent、哪个版本在执行？
- 它是在替谁办事，用户是否真的有权读取那些合同？
- 本次任务只是处理一张发票，为什么能读取全部供应商数据？
- 为什么邮件中的一句话可以绕过业务权限？
- 密钥泄露后，能否只停掉这个 Agent，而不影响所有系统？
所以，本文研究的不是“怎么给接口加一个登录校验”，而是怎么把 Agent 的身份、委托、权限、凭证和审计连成一条完整安全链路。
0. 先说结论
AI Agent 的身份问题，表面上是“怎么登录”，实际上是：
一个会自主做事的程序，怎样证明“我是谁、替谁办事、最多能办到什么程度”，并且在出错时能立即叫停、事后能还原？
这才是最核心的问题。单独给 Agent 一个 API Key，只解决了“门能不能打开”，没有解决“它为什么能开、能进哪间房、能拿什么、出了事算谁的”。
目前比较靠谱的解法可以浓缩成五句话：
- 每个生产 Agent 单独办身份，不要和开发者、项目或其他 Agent 共用账号。
- 让运行环境自动证明身份，用托管身份、OIDC 联邦或 SPIFFE/X.509，尽量不保存长期密钥。
- 把“用户是谁”和“哪个 Agent 在执行”同时带下去；后台任务则只使用 Agent 自身权限，不能冒充用户。
- 每次只发一张短期、专用的通行证，只允许访问指定工具、指定资源和指定动作。
- 最终权限判断交给网关和业务系统，不要让大模型自己决定自己有没有权限。
截至本次调研，Microsoft、Google、AWS、Alibaba Cloud 已提供专门的 Agent Identity 产品或一等身份模型；OpenAI 已提供服务账号和工作负载身份联邦，并能把外部 OIDC/SPIFFE/X.509 身份换成短期访问令牌；Salesforce 主要以专用 Agent User 和现有权限体系承载；Anthropic 的公开开发文档主要呈现 API Key、用户 OAuth 与 MCP Token，独立 Agent 主体通常需要依赖运行所在云或企业自建 IAM。
各家路线已经出现明显差异：
- Google 的 Agent Identity 使用 SPIFFE ID、自动 X.509、mTLS 与 DPoP 绑定，防 Token 重放设计最完整。
- Microsoft 把 Agent 建模为特殊 Service Principal，并用 Blueprint 管理同类 Agent；Attended 使用 OBO，Unattended 使用应用权限。
- AWS 强在“Agent 身份 + 用户身份绑定的 Workload Access Token + Token Vault + Gateway/Policy”，适合多工具和跨 SaaS 场景。
- Alibaba Cloud 已推出 Workload Identity、Workload Access Token、OIDC IdP、Token Vault 和 OBO，方向与 AWS 相近，但区域和集成成熟度需按项目复核。
- OpenAI 的工作负载身份联邦已支持 OIDC、SPIFFE JWT-SVID 和 X.509（Beta），适合消除调用 OpenAI API/Codex 所需的长期凭证；下游工具授权仍由应用或 MCP OAuth 流负责。
1. 六个最核心的问题，以及怎么解决
| 核心问题 | 传统做法为什么不够 | 推荐解法 | 最低验收标准 |
|---|---|---|---|
| 1. 到底是谁在做事？ | 共用 API Key 只能看见“某个应用调用了”，分不清具体 Agent 和版本 | 每个生产 Agent 独立身份，并关联定义、版本和本次运行 | 日志能回答“哪个用户让哪个版本的 Agent 做了什么” |
| 2. Agent 是替用户办事，还是自己办事？ | 直接复用用户 Token 会让 Agent 看起来就是用户；共用服务账号又会越权 | 明确区分“代表用户”和“自主运行”两条授权链 | 代表用户时同时保留 user + agent；自主任务不得伪造 user |
| 3. Agent 最多能做什么？ | OAuth scope 往往太粗，Prompt 中的限制也不可靠 | 取用户权限、Agent 权限、任务范围三者的交集，再加金额/路径/条数等硬限制 | 任一条件不满足，工具或资源服务器必须拒绝 |
| 4. 怎么证明来的真是这个 Agent？ | Bearer Token 被偷后，拿到的人通常也能使用 | 工作负载身份、短期 Token；高价值场景使用 mTLS/DPoP 等持有证明 | Token 被复制到别的运行环境后不能继续使用 |
| 5. Agent 怎样使用外部工具又看不到密钥？ | 把 API Key/Refresh Token 放进环境变量、提示词或沙箱，容易被读取和外传 | Credential Broker/Token Vault 代管，按需换取目标资源短期凭证 | 模型上下文、工具输出和代码沙箱中找不到长期凭证 |
| 6. 出错后能不能停、能不能查？ | 共享账号只能整批停用，日志也无法还原委托链 | 独立生命周期、撤销、Kill Switch、双主体审计和审批证据 | 能单独停用某个 Agent/版本，并还原一次完整动作链 |
1.1 真正的授权边界
可以把 Agent 最终得到的权限理解成一个交集：
text
本次允许做的事
= 用户本来有的权限
∩ Agent 被授予的权限
∩ 本次任务明确委托的范围
∩ 当前风险策略允许的范围任何一项为空，都应该拒绝。Agent 不能因为“很聪明”就扩大权限，也不能把用户权限和自己的额外权限相加。
1.2 用一个转账例子讲清楚
用户说：“把这张已审批发票付掉。”安全系统不应该只检查“Agent 有付款 API 的 Token”，还要逐项确认：
- 当前用户能否支付这个账户的发票；
- 运行的是不是已发布、未被禁用的付款 Agent；
- 本次委托是否只针对这张发票，而不是所有供应商；
- 金额、收款账户是否与审批时看到的一致；
- 是否达到二次确认或双人审批门槛；
- 下游支付系统是否再次验证这些条件。
这说明：认证只是确认来者身份，真正保护资产的是每次动作前的确定性授权。
2. 先把参与者分清：Agent 认证不是一个 Token 的问题
2.1 六类主体
| 主体 | 作用 | 典型标识 |
|---|---|---|
| 人（Human Principal） | 发起、委托或批准任务的人 | OIDC sub、员工 ID、客户 ID |
| Agent 定义（Agent Definition） | “这个 Agent 是什么”的版本化配置 | Agent ID、版本、发布者、模型/提示/工具清单 |
| 本次运行（Agent Instance） | Agent 为完成一次任务启动的具体实例 | run/session/task ID、短期实例 ID |
| 运行环境身份（Workload Identity） | 承载 Agent 的进程、Pod、函数或 VM 的机器身份 | SPIFFE ID、托管身份、IAM Role、Service Principal |
| 工具和资源（Tool/Resource） | 被访问的 MCP、API、数据库或 SaaS | OAuth resource/aud、资源 ARN/URI |
| 委托和审批（Delegation/Approval） | 谁允许 Agent 在什么边界内行动 | scope、用途、期限、交易约束、审批证据 |
关键点：Agent Definition、运行实例和承载工作负载不是同一个概念。生产系统至少要能从审计日志中把三者关联起来。
2.2 四条认证链
text
用户 → Agent：用户登录，Agent 服务验证用户身份与会话
运行时 → 身份平台：运行环境证明“我是这个 Agent/工作负载”
Agent → 工具：用 Agent 自身凭证或 user+agent 委托凭证访问 MCP/API
Agent → Agent：调用方 Agent 依据对方 Agent Card/元数据取得目标受众凭证认证回答“请求者是谁”；授权仍需回答“这个主体此刻能否对这个资源做这个动作”。
2.3 两种运行模式
| 模式 | 适用场景 | 推荐身份 | 不能做的事 |
|---|---|---|---|
| 代表用户运行（Attended / OBO） | 用户正在交互，访问用户数据 | 用户委托 + Agent 执行者身份 + 目标资源短期 Token | 不能把 Agent 的额外权限叠加给用户 |
| 自主运行（Unattended / Autonomous） | 定时任务、后台处置、跨时长工作流 | Agent 自身独立身份 | 不能冒充某个用户，也不应复用个人 Token |
若两种模式共用同一个“超级 Agent 账号”，即使登录正确，也无法实现可靠的最小权限与责任归属。
3. 厂商横向比较
3.1 总表
| 厂商/平台 | Agent 主体模型 | 无长期密钥 | 用户委托 | 工具/外部资源 | 关键特点 | 本次判断 |
|---|---|---|---|---|---|---|
| Microsoft Entra Agent ID + Foundry | 特殊 Service Principal；Blueprint 管理一类 Agent | 是，推荐 Managed Identity/Federated Credential | OAuth OBO，Token 同时表达用户与 Agent | Entra Token、MCP/A2A audience、RBAC/Graph 权限 | 身份生命周期、条件访问、治理体系完整 | 第一梯队 |
| Google Cloud Agent Identity | 每 Agent 唯一 SPIFFE Principal + X.509 | 是，禁止长效 SA Key/不可 impersonate | Auth Manager 管理 OAuth 委托 | mTLS、DPoP、IAM/PAB、Agent Gateway | 强证明持有与防重放 | 第一梯队；部分组件 Preview |
| AWS Bedrock AgentCore Identity | Agent Workload Identity（ARN）+ user-agent 绑定 Token | 是，IAM/SigV4、运行时自动 Token | OAuth/OBO、RFC 8693、用户 JWT 绑定 | Token Vault、Gateway、Cedar Policy、Secrets Manager | 跨 SaaS 凭证代理与策略执行突出 | 第一梯队，核心已 GA |
| Alibaba Cloud Agent Identity | Workload Identity（ARN）+ Workload Access Token | 是，可用 RAM Role/OIDC，Vault 管长期凭证 | OIDC 用户上下文、OBO | Token Vault、RAM、ActionTrail、OAuth/API Key Provider | 国内云原生 Agent 身份产品较完整 | 快速成熟；核验区域/配额 |
| OpenAI API / Codex | Platform Service Account 或 Workspace User/Service Account | 是，WIF 换短期 OpenAI Token | 工具 OAuth 由应用/MCP 流承担 | OIDC、SPIFFE JWT-SVID、X.509 Beta；Remote MCP Token | 消除访问 OpenAI 的长期 Key 很强；下游委托需组合设计 | 平台身份成熟，Agent 端到端需自建 |
| Salesforce Agentforce | 专用 Agent User / 登录用户上下文 | Agent 用户无密码；API 客户端常用 OAuth client credential/JWT | Employee Agent 继承用户上下文；服务 Agent 常用 Agent User | Profile、Permission Set、FLS、Sharing、Named/External Credential | 与业务对象/记录级权限深度融合 | 业务应用型强，通用工作负载身份较弱 |
| Anthropic API / Claude Code | API Key/Workspace；Claude Code 用户 OAuth；可借助 AWS/GCP 身份 | Anthropic API 公开文档仍以 Key 为主 | Claude Code/MCP 支持用户 OAuth | MCP 可传授权 Token；企业可部署到 Bedrock/Vertex | 模型层与运行平台解耦 | 需依赖云 IAM 或自建 Agent Identity |
“第一梯队”是本资料基于公开能力覆盖度的工程判断，不是厂商官方评级。
3.2 Microsoft：Agent 是目录中的特殊主体
Microsoft Entra Agent ID 把 Agent Identity 定义为特殊 Service Principal，并引入 Agent Identity Blueprint 作为同类 Agent 的治理模板。Blueprint 持有或联合运行时凭证，具体 Agent Identity 本身不持有密码；生产推荐使用 Managed Identity 的 Federated Identity Credential，避免 Client Secret。
两条运行路径：
- Attended：OAuth 2.0 OBO。用户 Token 进入 Agent Service，换取同时携带 Agent 身份与用户委托权限的下游 Token。
- Unattended：Client Credentials/Application-only。Agent 依靠自己的 RBAC、Graph Application Permissions 或其他策略访问资源。
Foundry 的开发期 Agent 可共享项目身份；发布后自动获得独立身份，需要重新给新 agentIdentityId 分配权限。MCP/A2A 连接必须配置目标 audience，下游验证 Agent Token 并执行 RBAC。
工程评价：
- 优点：Agent 与普通应用/用户可区分；Blueprint 适合大规模创建、撤销和策略继承；与 Entra 条件访问、治理、Graph、Azure RBAC 衔接自然。
- 风险点：开发期共享身份可能掩盖 Agent 间权限差异；发布换身份后权限迁移容易遗漏；
audience应指向受保护资源而非 MCP URL。
官方资料：Agent identity concepts in Microsoft Foundry、Microsoft Entra Agent ID、Agent identities overview。
3.3 Google：Agent 有自己的证书，Token 被偷也难以重放
Google Cloud Agent Identity 为每个 Agent 分配绑定资源生命周期的 SPIFFE ID，并自动管理 X.509 证书。与普通 Service Account 相比，Agent Identity 默认不共享、不可被 impersonate、开发者不能创建长期 Service Account Key。
关键机制：
- Agent 作为 IAM Principal，可直接加入 Allow/Deny Policy；PAB 限制其可达资源上界。
- 访问 Google Cloud API 时生成绑定 Agent X.509 证书的 Access Token。
- 通过 Agent Gateway 时叠加 mTLS 与 DPoP，降低 Bearer Token 被窃取后重放的风险。
- Agent Identity Auth Manager 代理 API Key、OAuth Client 与用户委托 Token；日志同时显示 Agent 与用户。
- Agent Runtime 的 Agent Identity 已具备生产可用形态；Auth Manager、部分 Gemini Enterprise 集成在调研时仍需核对 Preview/GA 状态。
工程评价：
- 优点：工作负载强证明、每 Agent 独立 Principal、Token 防重放、凭证不暴露给 Agent 的设计最系统。
- 风险点：跨云/非 Google 工具最终仍依赖 Auth Manager 或对方 OAuth；SPIFFE 信任域、证书和 DPoP 的排障复杂度较高。
官方资料：Agent Identity overview、Vertex AI Agent Engine identity setup、Google Cloud IAM 2026 updates。
3.4 AWS：把用户和 Agent 绑在一起，再由保险箱代管凭证
Amazon Bedrock AgentCore Identity 给 Agent 分配 Workload Identity。Runtime/Gateway 验证入站用户 JWT 后，取得 Agent 的 Workload Identity，生成同时绑定用户与 Agent 的 AWS-signed opaque Workload Access Token。该 Token 只用于访问 AgentCore 一方服务，例如出站 Credential Provider，不能直接当作外部 API Token。
出站访问由 Credential Provider 处理：
- 用户委托：Authorization Code 或 OBO Token Exchange，Token/Refresh Token 存入 Vault。
- Agent 自主：OAuth M2M、IAM/SigV4，或从受管凭证提供方取得 API Key。
- 工具网关：AgentCore Gateway 统一认证；AgentCore Policy 在模型代码外以 Cedar 执行细粒度规则。
用户 JWT 路径会验证签名、发行者和过期时间。平台也提供调用方自报 userId 的兼容路径，但官方明确指出该字符串不可由平台验证，只适合已有可信上游或开发场景。
工程评价：
- 优点：用户—Agent 凭证绑定、跨 SaaS OAuth、Token Vault、网关授权组成端到端闭环；Agent 可运行在 AWS、自托管或混合环境。
- 风险点：不要把不可验证的
userId当生产身份；Vault 中 Refresh Token 仍是高价值资产；下游授权必须继续执行，不能只信 Gateway 已认证。
AgentCore 于 2025-10 已 GA，OBO Token Exchange 于 2026-04 宣布 GA。官方资料：Workload access token、OAuth access token、AgentCore GA、OBO GA。
3.5 Alibaba Cloud：工作负载身份、用户委托和凭证保险箱
Alibaba Cloud Agent Identity 提供每个 Agent/自动化工作负载的 Workload Identity（账户内唯一 ARN），并签发短期 opaque Workload Access Token。在用户—Agent 场景中 Token 同时封装 Workload Identity 与 End-user Identity，用于从 Token Vault 获取目标资源凭证。
平台支持：
- OIDC 兼容 IdP，包括 RAM、企业 IdP、Okta、Entra ID 等；
- OAuth 2.0 Credential Provider 与 API Key Credential Provider；
- KMS 加密的 Token Vault；长期凭证不应直接进入 Agent 代码；
- Just-in-time 凭证注入、RAM Policy 和 ActionTrail 审计；
- Agent 代表用户访问工具的 OBO 模式。
Model Studio 传统模型/Agent API 仍大量使用 Workspace API Key，Key 默认长期有效，虽然支持 IP/模型范围以及 60 秒临时 Key。高代码 Agent Identity 集成示例仍要求 DashScope API Key，说明“模型入口完全无 Key”和“下游工具无 Key”目前不是同一成熟度。
工程评价：
- 优点：国内厂商中已公开形成较完整的 Agent 身份、用户委托、Vault 和审计模型。
- 风险点：文档显示部分 Agent Identity 示例仅在中国（北京）区域，实际可用地域、GA 状态和服务配额必须在采购/设计时重新核验；不要把传统 Workspace API Key 误认为 Agent 独立身份。
官方资料：What is Agent Identity、Bailian high-code integration、Model Studio API Key。
3.6 OpenAI：先解决“谁可以安全调用 OpenAI”
OpenAI API 接受 API Key，也接受通过 Workload Identity Federation 获得的短期 Access Token。外部工作负载先从其 IdP 取得短期 OIDC JWT、SPIFFE JWT-SVID，或在 Beta 路径使用 X.509 证书；OpenAI 验证后，根据映射规则将其映射到 Platform Project Service Account，并返回短期 OpenAI Token。
重要边界：
- 这解决的是“Agent/工作负载如何安全调用 OpenAI API 或 Codex”，不是自动解决所有下游 SaaS 授权。
- Service Account Mapping 可以进一步收窄 Token 权限，但不能超过目标 Service Account 自身权限。
- Remote MCP 调用可由应用提供 OAuth Access Token；OAuth 授权流仍由应用处理。
- 不支持 WIF 时，使用项目级 Service Account Key，并放入服务端 Secret Manager；不要在浏览器、客户端或模型上下文中暴露。
工程评价：
- 优点：可直接接受多云 OIDC、Kubernetes、GitHub Actions、SPIFFE 等工作负载来源，适合统一消除 OpenAI 长期 Key。
- 风险点：Agent 自身、用户委托与工具权限仍需企业自己的 IAM/Authorization Server/MCP 设计；X.509 WIF 当前为 Beta。
官方 OpenAI 文档：Workload identity federation、API authentication。
3.7 Salesforce：给 Agent 一个专用业务用户
Agentforce 的核心身份模型是“Agent 在某个 Salesforce User Context 中运行”：
- Service/External Agent 通常绑定专用 Agent User，以 Profile、Permission Set、Field-Level Security、Sharing Rule 和 OWD 控制数据访问。
- Employee Agent 可在登录用户上下文中执行，继承用户权限并把动作归因到该用户。
- 专用 Agent User 无密码，不能被普通交互登录；创建时给予最小基础权限，再按动作所需逐项扩展。
- Agent API 入站通常使用 External Client App 的 OAuth Client Credentials 或其他 JWT Access Token；
bypassUser决定使用 Agent User 还是 Token 对应用户。
工程评价：
- 优点：对 CRM 对象、字段、记录和 Sharing 的控制非常细，适合业务 Agent；Agent User 的权限和审计与现有 Salesforce 管理体系一致。
- 风险点：面向匿名/已识别但未登录客户时，识别出的 Contact ID 不等于访问控制主体；若仍以 Agent User 访问，必须用服务端过滤、动作条件和记录级规则防止横向越权。
官方资料：Configure Service Agent Access、Agent API authentication、Agentforce DX environment。
3.8 Anthropic：模型 API 身份与 Agent 运行身份分开建设
Anthropic API 的公开示例以 x-api-key 为主要认证方式；Claude Code 可通过 Anthropic Console/Claude 账户 OAuth 登录，也可使用 Amazon Bedrock 或 Google Vertex AI，从而继承 AWS/GCP 的工作负载身份能力。Claude Code 对远程 MCP 支持 OAuth 2.0，Token 可安全存储和自动刷新；Messages API 的 MCP Connector 由调用方提供远程 MCP 的授权 Token。
工程评价：
- 优点：容易与 MCP、Bedrock、Vertex AI 或企业 LLM Gateway 组合。
- 风险点：公开产品文档没有呈现与 Entra/Google Agent Identity 等价的 Anthropic 原生“每 Agent 一等 Principal + 用户/Agent 双主体 Token”模型。直接使用 Anthropic API 时，企业应在网关或运行平台实现独立 Agent 身份、短期凭证、用户委托和下游授权。
官方资料：Claude Code setup and authentication、Claude Code MCP、MCP Connector。
4. 协议与标准现状
4.1 可用于生产的基础标准
| 标准 | 用途 | 状态/注意事项 |
|---|---|---|
| OAuth 2.0 + Security BCP | 用户授权、客户端访问资源 | 成熟；不要使用 Password/Implicit 等旧流 |
| OpenID Connect | 用户/工作负载身份声明与发现 | 成熟；严格验证 iss、aud、签名、exp |
| RFC 8693 Token Exchange | 逐跳换取下游 Token、表达 impersonation/delegation | Proposed Standard；适合 OBO，但委托策略仍由实现定义 |
| RFC 8707 Resource Indicators | 指定目标资源 | 防止发出可用于过多资源的 Token |
| RFC 9728 Protected Resource Metadata | 资源服务器发布授权服务器位置 | MCP 授权发现的核心 |
| RFC 9449 DPoP / mTLS | Token 绑定与防重放 | 优于裸 Bearer；需要密钥与代理链支持 |
| SPIFFE X.509-SVID/JWT-SVID | 跨平台工作负载身份 | 稳定标准；优先 X.509-SVID，JWT 需严格 audience/短 TTL |
4.2 MCP：解决 Agent 怎么安全连接工具
MCP 2025-11-25 授权规范将受保护 MCP Server 建模为 OAuth Resource Server，要求：
- MCP Server 实现 RFC 9728 Protected Resource Metadata；
- Client 通过资源元数据发现 Authorization Server；
- Authorization Server 支持 OAuth 2.1 安全实践；
- Client 必须使用 PKCE，能用时使用
S256； - 通过
WWW-Authenticate提供精确 scope 指引； - 客户端注册优先既有注册、Client ID Metadata Document，再考虑 Dynamic Client Registration。
注意：MCP 解决的是连接和授权发现框架，不会自动替企业定义“这个 Agent 为何能删这条记录”。业务授权仍在 MCP Server/下游服务执行。
4.2.1 从教学示例升级到生产方案
小傅哥在《给 MCP 服务加上安全认证》中演示了使用 Spring Authorization Server、Spring Resource Server 和 client_credentials 给 MCP 服务增加 Token 校验。这个例子非常适合先把 OAuth 链路跑通，但如果用于生产 Agent，还需要继续补齐下面这些能力：
| 教学阶段做法 | 能解决什么 | 上生产前还要补什么 |
|---|---|---|
| URL 中携带 API Key | 快速接入已有 MCP 服务 | Key 移出 URL 和配置文件，放入 Vault；优先换成短期 Token |
| 一个 OAuth Client 调用 MCP | MCP 不再允许匿名访问 | 每个生产 Agent 使用独立身份，避免所有 Agent 共用 Client |
client_credentials | 适合 Agent 以自己身份执行后台任务 | 涉及用户数据时改用授权码 + PKCE 或 OBO，并保留 user + agent |
| Resource Server 验证 Access Token | 能确认 Token 合法、未过期 | 继续验证 issuer、audience、scope，并执行租户、对象、字段和参数级授权 |
| Agent 拿到 Token 后直接调用 | 完成最短调用链 | 引入 Token Broker/Vault，按目标资源即时签发，避免长期凭证进入 Agent 上下文 |
| 通过认证即可调用工具 | 挡住未登录请求 | 网关和工具仍要判断“本次任务是否允许这个具体动作” |
可以简单理解为：博客示例完成了“门口装锁”，生产方案还要补房间门禁、访客单、保险柜、监控和紧急断电。
4.3 A2A：解决 Agent 怎么声明自己的连接方式
A2A 的 Agent Card 可声明 API Key、HTTP Bearer、OAuth 2.0、OIDC、mTLS 等 Security Scheme。客户端先发现认证要求，再在协议外取得凭证，并在每次请求中携带。A2A 明确把 Agent 当作标准企业应用，身份语义不由协议本身统一定义。
因此 A2A 能描述怎么认证，但不等于建立跨组织 Agent 信任。生产还需：可信 Agent Registry、发布者/软件供应链证明、目标 audience、每个操作的服务端授权、委托链限制和审计关联。
规范：A2A Protocol specification。
4.4 Agent 专用授权标准仍在演进
IETF OAuth 工作组/社区正在讨论 Agent Authorization Profile、Agent Authorization Use Cases、Identity and Authorization Chaining、Transaction Token 等方向。它们试图补齐：
- 同时表达用户、Agent、上游 Agent 与执行实例；
- 多跳委托不丢失身份/授权链；
- 把“任务目的、交易参数、人工批准证据”绑定到一次动作；
- 在不同信任域间逐跳收窄权限。
截至基线日期，相关 Agent Authorization 文档仍是 Internet-Draft，没有正式标准地位，不应把草案私有 Claim 当成长期兼容承诺。可跟踪：IETF Agent Authorization use cases and gap analysis。
5. 推荐企业框架图
这张图最重要的地方不是组件名称，而是三条边界：人先登录、Agent 再证明自己、每次工具调用还要重新授权。
图 V-1：5. 推荐企业框架图 · 可编辑 Mermaid 源码
5.1 一次完整调用是怎么走的
图 V-2：5.1 一次完整调用是怎么走的 · 可编辑 Mermaid 源码
5.2 代表用户和自主运行的区别
图 V-3：5.2 代表用户和自主运行的区别 · 可编辑 Mermaid 源码
5.3 Token 中至少要能关联什么
若使用 JWT，建议至少能验证或关联：
json
{
"iss": "https://id.example.com",
"sub": "user:alice",
"aud": "https://payments.example.com",
"exp": 1787462400,
"jti": "unique-token-id",
"scope": "invoice.read payment.prepare",
"act": { "sub": "agent:invoice-assistant:prod" },
"task_id": "task-...",
"agent_version": "sha256:..."
}示例表达 Agent 代表用户行动；自主任务可把 Agent 放在 sub，不再伪造用户。RFC 8693 定义了 act 的 Actor 语义，但 task_id、agent_version 等扩展字段仍需由企业协议明确。不要因为 Claim 在 Token 中就默认可信；授权服务只接受受信发行者签名且符合明确 Schema 的声明。
5.4 一次工具调用的授权条件
text
允许 = 用户有权访问资源
AND Agent 身份处于启用状态
AND Agent 版本/运行环境受信
AND 委托包含该目标资源与动作
AND Token audience 精确匹配工具
AND 任务目的、参数、金额/条数/路径在边界内
AND Token/审批未过期、未撤销
AND 风险策略未要求更强认证或人工确认5.5 把框架落到工程模块
如果要自己建设，可以按下面的职责拆分。模块不一定非要做成七个微服务，但安全边界必须清楚。
text
agent-security-platform
├── identity-entry # 验证用户登录、租户和会话
├── agent-registry # 登记 Agent、版本、Owner、状态和风险等级
├── workload-identity # 验证 Pod/函数/VM，给运行中的 Agent 证明身份
├── token-broker # OBO、Token Exchange、目标 audience 短期 Token
├── credential-vault # 保管 API Key、Client Secret、Refresh Token
├── policy-center # 判断 user + agent + task + resource + action
├── tool-gateway # MCP/A2A/API 入口、参数限制、审批和限流
└── audit-center # 串起用户、Agent、任务、工具、策略和结果| 模块 | 一句话职责 | 绝对不能依赖什么 |
|---|---|---|
| Identity Entry | 证明当前用户是谁 | 不能信前端自己传来的 username/userId |
| Agent Registry | 证明这个 Agent 是谁、谁负责、哪个版本可运行 | 不能只登记一个自然语言名称 |
| Workload Identity | 证明请求来自受信运行环境 | 不能靠写死在镜像里的 Secret |
| Token Broker | 给本次任务换一张短期、专用通行证 | 不能把入口 Token 原样透传所有下游 |
| Credential Vault | 代管外部系统长期凭证 | 不能把明文凭证返回给模型或代码沙箱 |
| Policy Center | 对每次动作做确定性判断 | 不能让大模型输出“允许”作为授权结果 |
| Tool Gateway | 在工具执行前强制认证、授权和参数限制 | 不能只看工具名，不检查参数和目标资源 |
| Audit Center | 还原谁让谁在什么边界内做了什么 | 不能只记录最终 HTTP 调用者 |
5.6 每次请求都要带一份安全上下文
下面不是标准协议，而是一份便于工程团队对齐的数据结构示例。它可以进入策略判断和审计，但敏感凭证本身不能放进来。
json
{
"tenant_id": "tenant-a",
"user": {
"subject": "user:alice",
"auth_time": "2026-08-24T09:00:00+08:00",
"auth_level": "phishing-resistant"
},
"agent": {
"id": "agent:invoice-assistant",
"version": "2026.08.24-1",
"workload_id": "spiffe://example.com/agent/invoice-assistant"
},
"task": {
"id": "task-123",
"purpose": "pay-approved-invoice",
"expires_at": "2026-08-24T09:15:00+08:00"
},
"request": {
"resource": "invoice:20260824-001",
"action": "payment.prepare",
"amount": 3200,
"currency": "CNY"
},
"approval_id": "approval-789"
}策略服务拿到它以后，做的不是“问模型是否安全”，而是执行清楚、可测试的规则：
text
如果用户无权支付该发票 → 拒绝
如果 Agent 版本未发布或已停用 → 拒绝
如果任务目的不是 pay-approved-invoice → 拒绝
如果金额或收款账户与 approval-789 不一致 → 拒绝
如果金额达到二次确认门槛 → 要求再次确认
其余情况 → 签发只允许 payment.prepare 的短期 Token5.7 一条生产调用链的验收方式
不要只测“正常请求能返回 200”，还要反向验证安全边界：
- 换成另一个用户，确认不能读取原用户数据；
- 换成另一个 Agent，确认同一个 Token 不能复用；
- 修改 Token 的
audience，确认工具拒绝； - 把 Token 复制到未受信运行环境，确认 mTLS/DPoP 场景下不能重放；
- 修改金额、收款账户或资源 ID，确认原审批立即失效；
- 停用 Agent 或版本，确认新请求在分钟级内失败；
- 查看日志，确认能串起 user、agent、task、approval、tool 和 result。
6. 选型与落地建议
6.1 已在单一云上
- Azure/Microsoft 365 为主：优先 Entra Agent ID + Managed Identity/FIC + OBO + Azure RBAC/Graph Permission。
- Google Cloud 为主：优先 per-agent Agent Identity；对高价值工具启用 mTLS/DPoP，使用 PAB 限制资源上界。
- AWS 为主且跨 SaaS 多：优先 AgentCore Identity + Gateway + Policy；用可验证用户 JWT 路径，不用裸
userId作为生产证据。 - Alibaba Cloud/国内部署：评估 Agent Identity + RAM Role/OIDC/OBO；逐区域验证功能，不要默认 Bailian API Key 已被完全替代。
6.2 多云或自建
- 用 SPIFFE/SPIRE 或云 Workload Identity 给运行时签发短期身份。
- 企业 Authorization Server/STS 通过 RFC 8693 把工作负载身份换成目标资源 Token。
- 用户交互使用 Authorization Code + PKCE；Agent 后台任务使用自身工作负载身份。
- 用统一 Credential Broker/Vault 代理 SaaS OAuth 与历史 API Key。
- 在 MCP/A2A/HTTP 入口部署 Policy Enforcement Point；策略服务基于 user、agent、task、resource、action、risk 判定。
- 对高风险动作使用交易级确认，确认页面展示实际收件人、金额、资源和不可逆影响。
6.3 迁移顺序
| 阶段 | 改造目标 | 验收证据 |
|---|---|---|
| 1 | 清点所有 Agent、Key、Service Account、工具与 Owner | 资产台账和责任人完整 |
| 2 | 每个生产 Agent 独立 Principal | 日志可区分 Agent，不再共享万能账号 |
| 3 | 长期 Key → 托管身份/WIF/短期 Token | 运行环境无静态主密钥 |
| 4 | 区分自主与用户委托 | Token/日志同时可追踪 user 与 agent |
| 5 | 目标受众与逐跳换 Token | 错 audience、超 scope、过期 Token 均被拒绝 |
| 6 | 授权外移到网关/下游资源 | Prompt Injection 不能绕过策略 |
| 7 | 审批、撤销、Kill Switch、持续访问评估 | 分钟级停用，历史动作可还原 |
7. 常见错误
- 用用户 Token 直接透传所有下游，导致 Agent 与用户无法区分、Token audience 错误和混淆代理问题。
- 所有 Agent 共用一个 Service Account/API Key，权限只能越堆越大。
- 把“用户已识别”误当“以用户权限执行”；CRM Contact ID、聊天用户名或请求字段不是可验证身份。
- 把 OAuth Scope 当完整业务授权；
files.write并没有说明可写哪一个租户、目录或金额。 - 把 Key/Vault Secret 放进模型上下文、工具返回值、代码沙箱或可检索记忆。
- 只在 Agent Prompt 中写“不要执行危险操作”，却不在工具或下游服务强制授权。
- 多 Agent 链条中递归透传上游全部权限，没有每跳 audience、scope 和 TTL 收窄。
- 只记录最终 API 调用者，不记录 user、agent、run、delegation、approval 和模型/提示版本。
- 把 Preview 或 Internet-Draft 当稳定兼容层，未设计回滚与替换方案。
8. 评审清单
身份
- [ ] 每个生产 Agent 是否有独立、可禁用、可审计的 Principal？
- [ ] Agent Definition、版本、实例和宿主 Workload 是否可关联？
- [ ] 是否使用运行时证明/工作负载联邦，而不是长期 Secret？
- [ ] 开发、测试、生产是否处于不同信任域或至少不同身份边界？
委托与 Token
- [ ] Attended 与 Unattended 是否使用不同授权路径？
- [ ] 能否同时识别用户与 Agent，而非只保留一个
sub？ - [ ] Token 是否短期、目标受众绑定、scope 最小且可撤销？
- [ ] 多跳调用是否逐跳换 Token，并阻止权限扩张/无限递归？
- [ ] 是否优先使用 mTLS/DPoP/PoP 防止高价值 Token 重放？
工具与授权
- [ ] MCP/A2A Server 是否验证 issuer、signature、audience、expiry、client/agent？
- [ ] 业务权限是否由 Gateway/Tool/Resource 强制执行？
- [ ] 读写工具是否拆分，参数是否有金额、条数、路径、域名硬限制？
- [ ] 高风险动作是否绑定用户可理解的确认内容与 step-up？
- [ ] Agent 是否无法读取长期凭证和 Refresh Token？
生命周期与审计
- [ ] Agent Owner/Sponsor、到期时间、用途、数据范围是否登记？
- [ ] 发布新版本/复制 Agent 时是否重新评估身份和权限？
- [ ] 能否单独停用 Agent、委托、Token、工具和某个版本？
- [ ] 日志是否包含 user、agent、run/task、tool、resource、action、decision、approval、result？
- [ ] 是否测试错 audience、过期/撤销、Prompt Injection、跨租户、重复执行和审批绕过？
9. 最终结论
现阶段没有一个单一协议能包办 Agent 身份安全。可落地的组合是：
text
OIDC/Passkey（人）
+ Workload Identity / SPIFFE / Managed Identity（Agent 运行时）
+ OAuth Token Exchange / OBO（委托）
+ audience/resource/scope/PoP（短期凭证约束）
+ IAM/Policy Gateway/下游 ACL（确定性授权）
+ Vault/Approval/Audit/Lifecycle（治理）如果只能先做三件事，优先级应是：
- 给每个生产 Agent 独立身份，停用共享万能账号；
- 以工作负载联邦和短期 Token 取代长期 Key，并严格绑定目标资源；
- 把授权放到 Agent 代码之外，审计同时记录用户与 Agent。
说到底，Agent 身份安全不是“再发一个 Token”，而是让每一次动作都能回答清楚：谁让哪个 Agent，基于什么授权，对哪个资源做了什么；系统能不能拒绝、撤销并追责。
建议每季度复查：各厂 GA/Preview 状态、MCP 当前规范版本、A2A 规范、IETF OAuth Agent Authorization 与 Transaction Token 进展。