OpenID Foundation 在 2025 年 10 月 7 日正式发布了 33 页的白皮书《Identity Management for Agentic AI》，并于 10 月 29 日更新至 arXiv 预印本平台（编号 2510.25819v1）。这份由 Tobin South 主编的报告向正处于狂热中的大模型落地潮泼了一盆冷水：当前行业普遍倚重的 Model Context Protocol（MCP）和 OAuth 2.1 框架，根本无法承载高度自主的智能体系统。
白皮书给出的核心判断非常明确：现行的身份与访问控制协议均建立在单一人类用户即时点击的静态假设之上。一旦智能体脱离单信任域，进入长程异步执行、跨域调用或多用户共享环境，现存的安全机制便全面出现断层失效。整个行业正试图用上一代的门禁钥匙，去管理具备自主决策能力的下一代数字劳动力。
MCP的连接幻觉：工具接通了，下游授权链却断了
许多开发者误以为只要让大模型跑通 MCP 协议、给接口套上 OAuth 2.1 认证，就能安全调用外部工具与企业数据。这是一种普遍的技术错觉。白皮书明确指出，现有 OAuth 2.1 机制仅适用于单信任域内的同步操作，即员工在内部系统里让助手查询报表，或者个人用户实时授权大模型读取一次本地文件。
当任务演变为跨信任域的工作流时，裂痕随之暴露。MCP 协议目前仅仅规范了语言模型与工具服务端的管道连接，并没有解决端到端的完整授权链。MCP 客户端到服务端的身份认证，与服务端进一步访问下游第三方 API 所需的授权，属于截然不同的信任边界。
在缺乏统一标准的前提下，当前大部分团队选择让智能体直接冒充用户（User Impersonation）。智能体拿着人类的高权限令牌，以人类的名义向各路服务发送请求。这种做法直接击碎了企业的审计线索：日志记录显示某项高危数据更改由某位工程师完成，实际上却是后台智能体根据模型推理自行做出的非确定性决策。
- 风险.若不从冒充模式切换为可验证的显式委托授权（On-Behalf-Of），一旦智能体遭遇提示词注入攻击，下游系统将无法实施任何边界拦截。
递归委托与授权疲劳：最小权限原则在工程上击穿
当智能体自主拆解任务并衍生出多个子智能体（Sub-agents）协同作业时，安全架构的崩塌速度进一步加快。白皮书将这种级联传递称为递归委托。
理论上，系统可以通过 OAuth 2.0 Token Exchange 进行中心化权限降级，或者采用能力令牌（capability tokens）实现离线权限衰减。但在多层调用的动态网络中，整条链条的实时撤销（Revocation）在现有工程框架下几乎不可行。如果顶层主任务已经被人类终止，散落在外部各类微服务甚至跨云节点里的子任务，往往因为缺乏统一状态广播机制而继续执行，直至持有凭证自然过期。
为了弥补协议维度的不足，许多产品设计了人机协同机制，要求关键操作弹窗让用户确认。然而在高频运行的场景下，这迅速演变成授权疲劳。面对一分钟内弹出的十几次确认窗口，普通员工甚至专业运维都会产生反射性通过的心理惯性。安全防御如果只靠用户的耐心维系，最小权限原则在实际业务场景中就不复存在。
与此同时，白皮书还揭示了一个容易被忽略的协同盲区：多人共享智能体。当一个研发团队在同一个代码库或协作频道中使用同一个智能体时，团队成员在企业内的权限等级并不相同。现存的 OAuth 与 OpenID Connect 协议完全是围绕单一人类用户设计的，根本没有成熟机制去规范一个既代表主管又代表实习生的共享智能体，越权读取敏感资产与数据泄露的风险由此成倍放大。
三维割据：从Google A2A到微软Entra的控制权博弈
面对失序的现状，科技巨头并非没有动作，但各自的着力点截然不同，整个行业呈现出清晰的三层分工与割裂状态。
巨头正在通信与凭证层面跑马圈地，开放标准的缺失将让企业陷入新的孤岛。
通信层面上，Google 推出了 A2A 协议，核心在于通过 Agent Card 规范智能体端点的功能声明与传输格式。A2A 解决的是智能体之间如何打招呼、如何发送结构化任务，并不负责下游资源的细粒度访问控制。开源社区与安全专家的分歧恰恰在此：协议开发者倾向于只要连通即可，而安全架构师清楚，握手合法绝不等于后续动作合理。
控制层面上，两大公有云巨头正加速收缴企业控制权。微软推出了 Entra Agent ID，专门对智能体调用 Microsoft Graph 权限与高危目录角色施加显式隔离，将智能体纳入统一的条件访问管理；AWS 则主打 Bedrock AgentCore Identity，侧重于工作负载身份的颁发，以及混合云与第三方工具凭据的安全存储。这两家方案的目的高度一致：用完善的受管控制平面绑紧企业客户，形成高壁垒的云生态合规闭环。
最后则是以 OpenID Foundation 为代表的标准层。白皮书明确提出要依托企业安全身份互操作工作组（IPSIE），推动基于现有标准拓展出针对智能体的开放 Profile 规范。标准机构最警惕的，正是云厂商自建封闭的专有 Agent 身份体系。
- 建议.企业安全团队在采购智能体服务时，应优先考察其是否支持 SSO、SCIM 自动化生命周期管理及原生 Token Exchange，切忌将核心业务授权深度绑定在单一云厂商的私有标识方案中。
未来的技术演进必须让智能体获得独立于人类工作负载的身份凭证，并在每次调用中附带可被各方实时验证的授权范围证明。智能体赛道的竞逐已经越过单纯展示推理能力的阶段，谁能先在底层的身份与授权架构上打好补丁，谁才能真正推开企业级规模化落地的大门。