AI Agent跨应用访问：三大身份厂商8天内收敛同一架构模式

一个耐人寻味的巧合

2025年8月下旬到9月初,短短八天内,身份认证领域的三家重量级厂商——Okta、Auth0 和 Descope——不约而同地推出了名为 Cross App Access(跨应用访问) 的能力。这种密集的产品发布节奏并非偶然,它揭示了整个行业对同一个技术难题达成的共识:随着 AI Agent 大规模进入企业系统,传统的身份与访问管理(IAM)架构已经无法满足需求。

AI Agent 的定义与企业场景

AI Agent(人工智能代理)是指能够感知环境、自主决策并执行任务的智能系统。与传统的聊天机器人或自动化脚本不同,AI Agent 具备三个核心特征:自主性(无需人类持续干预)、反应性(能实时响应环境变化)和目标导向性(围绕明确目标规划行动路径)。在企业场景中,典型的 AI Agent 包括:智能客服代理(自主处理客户咨询、升级复杂问题)、数据分析代理(定期抓取多源数据生成报告)、IT 运维代理(监控系统健康度并自动修复故障)等。这些 Agent 的共同特点是需要跨越多个企业系统(CRM、ERP、邮件、日历等)获取数据并执行操作,这与传统的单一应用访问模式形成鲜明对比。随着 GPT-4、Claude 等大语言模型的能力提升,Agent 正从实验室走向生产环境,但身份管理体系的滞后成为其规模化部署的最大障碍。

身份认证领域三巨头背景

Okta 是全球最大的身份管理平台之一,成立于 2009 年,服务超过 17000 家企业客户,市值曾超过 400 亿美元。Auth0 于 2013 年创立,专注于为开发者提供身份验证和授权 API,2021 年被 Okta 以 65 亿美元收购,但仍保持独立品牌运营。Descope 是该领域的新锐力量,2022 年成立后迅速获得 5300 万美元融资,专注于无代码身份认证解决方案。三家公司虽然定位略有差异,但都在企业级身份管理市场占据重要地位,它们的同步动作具有强烈的行业风向标意义。

IDaaS 市场格局与竞争态势

IDaaS(Identity as a Service,身份即服务)是云计算时代身份管理的主流模式,将传统的企业身份基础设施(如 Active Directory)云化为 SaaS 服务。根据 Gartner 2024 年报告,全球 IDaaS 市场规模已超过 150 亿美元,年增长率达 30%。市场呈现「双寡头+长尾」格局:Okta 和微软(Azure AD/Entra ID)占据超过 50% 的市场份额,Ping Identity、ForgeRock 等传统玩家守住企业级市场,Auth0(被 Okta 收购但独立运营)主攻开发者友好路线,Descope、WorkOS 等新锐则以无代码、快速集成为差异化卖点。值得注意的是,这次三家同步发布 Cross App Access 的厂商定位各异:Okta 面向大型企业、Auth0 聚焦开发者生态、Descope 主打敏捷场景,但它们都在 Agent 访问模式上达成一致,说明这一需求已跨越客户规模和行业边界,成为全行业的共同痛点。未来竞争的焦点将从「谁提供更多功能」转向「谁能更好地支持 Agent 生态」和「谁能建立跨厂商互操作标准」。

说个细节,真正重要的不是哪家厂商最终胜出,而是这些产品底层共享的两层访问模式。这一模式的生命力,将远远超过任何单一厂商的市场地位。

为什么 AI Agent 打破了原有的访问模型

传统 IAM 的核心假设正在失效

过去二十年,企业身份管理的核心假设是:访问系统的主体是人。用户登录、获得令牌、访问应用,权限围绕「谁在操作」来设计。OAuth、SAML、SSO 等一整套体系,本质上都是为「人类用户 + 应用」这一双层关系服务的。

IAM 架构演进历程

身份与访问管理(Identity and Access Management, IAM)经历了三个主要发展阶段。第一阶段(1990-2000年代)是目录服务时代,以 LDAP 和 Active Directory 为代表,用户身份集中存储在企业内部。第二阶段(2000-2010年代)是联合身份时代,SAML、OAuth 2.0 等协议出现,实现了跨组织的单点登录(SSO)。第三阶段(2010年至今)是云原生身份时代,以 Okta、Auth0 为代表的 IDaaS(Identity as a Service)兴起,身份管理完全云化、API 化。如今 AI Agent 的出现,正在推动 IAM 进入第四阶段——代理身份(Agentic Identity)时代,这是一个从「人类中心」向「人机协同」转变的关键节点。

联合身份管理的历史脉络

联合身份管理(Federated Identity Management)的概念可追溯到 2001 年 Liberty Alliance 项目,由 Sun Microsystems 牵头,旨在建立跨组织的身份互操作标准。此后 SAML 2.0(2005年)成为企业 SSO 的事实标准,而 OAuth 2.0(2012年)和 OpenID Connect(2014年)则在消费互联网领域占据主导。这些标准的共同基因是「用户在场授权」——用户通过浏览器重定向完成身份验证和授权。AI Agent 的出现是对这一基因的根本性挑战,因为 Agent 需要在用户不在场的情况下持续行动,这正是推动两层访问模式诞生的历史动力。

但 AI Agent 的出现打破了这个假设。当一个自主运行的 Agent 需要代表用户去调用多个应用、访问跨系统的数据时,问题就出现了:Agent 究竟是「用户」还是「应用」?它既不完全是人,也不是传统意义上的服务账户。这种模糊的身份定位,让现有的 IAM 框架左右为难。

服务账户与 Agent 身份的本质差异

传统企业 IT 中的服务账户(Service Account)是为机器间通信设计的非人类身份,典型场景包括定时任务、批处理作业和微服务间调用。服务账户通常拥有固定的凭证(如 API Key 或客户端证书)、静态的权限集、以及明确的所有者(通常是某个运维团队)。AI Agent 与服务账户看似类似——都是非人类实体访问系统资源——但存在根本差异。首先,Agent 是代表特定用户行动的,其权限应随用户身份动态变化,而服务账户的权限是预设的、与特定用户无关。其次,Agent 的行为路径是动态的、不可完全预测的——一个分析 Agent 可能根据数据结果决定是调用 Slack 还是创建 Jira 工单,这种自主决策能力超出了服务账户的设计边界。最后,Agent 的权限需要精细的时效性和可撤销性,而传统服务账户的凭证往往长期有效,成为安全隐患。这些差异正是两层访问模式试图弥合的鸿沟。

跨应用场景带来的连锁难题

设想一个典型场景:企业内的 AI 助手需要读取用户的日历(应用 A)、汇总邮件(应用 B),再据此在项目管理工具(应用 C)中创建任务。在旧模型下,这意味着 Agent 需要分别持有三个应用的凭证,权限边界模糊,审计困难,一旦某个环节泄露,整个链条都会被波及。

OAuth 与 SAML 的局限性

OAuth 2.0 和 SAML 是现代身份认证的两大基石协议。OAuth 2.0 设计于 2012 年,核心理念是「授权委托」——允许第三方应用在用户授权下访问受保护资源,典型场景是「使用 Google 账号登录」。SAML(Security Assertion Markup Language)则更早,诞生于 2005 年,主要用于企业间的单点登录,通过 XML 格式交换身份断言。但这两个协议都基于一个核心假设:访问主体是人类用户,且用户在授权时在场(present)。AI Agent 打破了这个假设——Agent 需要在用户离线时持续运行、跨多个应用自主决策,这种「长期委托+自主执行」的模式,是 OAuth 和 SAML 设计时未曾考虑的场景,因此需要全新的访问控制范式。

RBAC、ABAC 与 Agent 权限模型的演进

传统企业权限管理主要采用两种模型:RBAC(基于角色的访问控制)和 ABAC(基于属性的访问控制)。RBAC 通过预定义角色(如管理员、编辑者、查看者)分配权限,简单直观但缺乏灵活性;ABAC 则基于用户属性、资源属性、环境上下文等动态条件做出授权决策,更为精细但实施复杂度高。AI Agent 场景对权限模型提出了新要求——既需要 RBAC 的清晰角色定义(Agent 代表的用户角色),又需要 ABAC 的动态评估能力(根据 Agent 的实时行为和上下文调整权限)。两层访问模式中的细粒度 Scoping 本质上是 RBAC 和 ABAC 的融合实践,同时引入了时间维度(令牌时效)和行为维度(操作类型限制),形成了更适合 Agent 场景的新型权限范式。

企业 AI Agent 部署的安全威胁模型

AI Agent 的规模化部署引入了一系列新的安全威胁向量,这也是推动两层访问模式出现的重要驱动力。主要威胁包括:提示注入攻击(Prompt Injection)——攻击者通过操纵 Agent 处理的输入数据来改变其行为,例如在邮件中嵌入恶意指令,诱导 Agent 将敏感数据发送到外部;凭证泄露与权限升级——如果 Agent 持有多个应用的长期凭证,一旦被攻破就会导致多系统同时沦陷;过度授权(Over-Privileging)——为求便利将 Agent 配置为管理员权限,违反最小权限原则;供应链攻击——Agent 依赖的第三方插件或工具可能被植入恶意代码。两层访问模式通过短期令牌、细粒度 Scoping 和实时策略检查来缓解这些威胁,但企业仍需建立 Agent 行为监控、异常检测和紧急撤销机制作为补充防线。OWASP 在 2024 年发布的《LLM 应用安全 Top 10》中,已将 Agent 相关的安全风险列为重点关注领域。

这正是三家厂商试图解决的核心问题——如何让 AI Agent 在跨应用协作时,既能高效完成任务,又能保持清晰的权限边界和完整的可审计性。

底层的「两层访问模式」解析

模式结构拆解

Cross App Access 之所以能被三家独立实现,是因为它们都收敛到了同一个抽象结构——两层访问模式。

这一模式可以拆解为两个核心层次:

• 第一层:身份与授权层。明确界定 Agent 代表哪个用户、在什么范围内行动。这一层解决「Agent 是谁、代表谁」的问题,将 Agent 的身份与其背后的人类主体绑定,同时施加精确的权限约束。
• 第二层:应用间访问层。在获得授权后,Agent 通过标准化的访问通道调用各个目标应用,而不是分散持有每个应用的独立凭证。这一层解决「Agent 如何安全地跨应用行动」的问题。

这种分层设计的巧妙之处在于:第一层确保了安全可控,第二层确保了灵活高效,两者的组合恰好覆盖了 AI Agent 场景下身份管理的核心需求。

两层访问模式的技术实现

两层访问模式在技术上通常通过以下机制实现:第一层使用「委托令牌」(Delegated Token)机制,将用户身份、授权范围、时效性等信息编码在 JWT(JSON Web Token)中,Agent 持有该令牌作为「代表用户行动」的凭证。关键创新是引入了「范围限定」(Scoping)——不同于传统 OAuth 的粗粒度 scope,Agent 令牌可精确到「只能读取特定项目的日历」或「仅能创建不超过 5 个任务」。第二层则建立在「令牌交换」(Token Exchange)机制之上,Agent 用第一层的委托令牌,通过身份提供商(IdP)动态换取目标应用的访问令牌,而不是预先存储所有应用凭证。这种设计既保证了 Agent 的灵活性,又确保了每次跨应用访问都经过身份提供商的审计和策略检查,实现了「零信任」原则在 Agent 场景的落地。

令牌交换（Token Exchange）机制详解

令牌交换是 OAuth 2.0 Token Exchange(RFC 8693)定义的标准流程,允许一个实体用已有的安全令牌换取另一个令牌,以访问不同的资源或服务。RFC 8693 于 2020 年正式发布,最初的设计动机是解决微服务架构中的身份传播问题——当一个微服务需要代表用户调用另一个微服务时,如何安全地传递身份上下文。在 AI Agent 的跨应用场景中,Token Exchange 的工作流程如下:Agent 首先从身份提供商获取一个「主令牌」(Subject Token),该令牌编码了用户身份和 Agent 的委托关系;当 Agent 需要访问目标应用时,它将主令牌提交给身份提供商的 Token Exchange 端点,请求换取该应用的专用访问令牌;身份提供商验证主令牌的有效性、检查 Agent 是否有权访问目标应用、评估当前安全策略后,颁发一个范围受限、短期有效的新令牌。这一机制的安全优势在于:Agent 永远不直接持有目标应用的凭证,每次跨应用访问都被身份提供商实时审计和策略管控,即使 Agent 被攻破,攻击者也只能获得短期、窄范围的令牌,无法横向移动到其他系统。然而,RFC 8693 在 Agent 场景下仍存在一些尚未完全解决的问题:标准没有定义 Agent 身份的注册和生命周期管理流程;对于 Agent 行为的细粒度授权(如限制调用频次、限制数据量)缺乏原生支持;多级委托链(用户→Agent→子Agent)的信任传递机制尚不成熟。三家厂商的 Cross App Access 实现均在 RFC 8693 基础上做了扩展,补充了 Agent 注册、行为策略绑定等能力,但这些扩展目前尚未标准化,未来可能成为 IETF 或 OpenID Foundation 新标准的素材。

JWT 与现代身份令牌技术

JWT(JSON Web Token)是一种开放标准(RFC 7519),用于在各方之间安全地传输信息。它由三部分组成:Header(头部,声明令牌类型和签名算法)、Payload(载荷,包含声明信息如用户 ID、权限、过期时间)、Signature(签名,防止篡改)。JWT 的核心优势是自包含性——令牌本身携带了所有必要的身份和授权信息,接收方无需回调认证服务器即可验证有效性,这使其特别适合分布式系统和微服务架构。在 AI Agent 的两层访问模式中,JWT 扮演关键角色:第一层的委托令牌用 JWT 编码用户身份、Agent ID、授权范围(scopes)、时效性(exp 字段)等信息,并用身份提供商的私钥签名。Agent 持有该 JWT 后,在第二层访问目标应用时,将 JWT 提交给身份提供商进行令牌交换,换取特定应用的访问令牌。这种设计既保证了安全性(JWT 签名防伪造、过期时间限制风险窗口),又提供了灵活性(Payload 可携带细粒度权限元数据),是现代身份架构的基石技术。

零信任架构与 Agent 安全

零信任(Zero Trust)是近年来网络安全领域的核心范式转变,由 Forrester 分析师 John Kindervag 于 2010 年提出,核心理念是「永不信任,始终验证」(Never Trust, Always Verify)。传统的安全模型基于「城堡与护城河」——企业网络边界内的访问被默认信任,边界外的访问被阻断。但随着云计算、远程办公和 SaaS 应用的普及,这一边界已经模糊。零信任要求对每一次访问请求(无论来自内部还是外部)都进行身份验证、设备验证和权限检查,并基于最小权限原则授权。在 AI Agent 场景中,零信任尤为关键:Agent 长期运行、跨多系统访问、可能被攻击者劫持,因此必须对其每次跨应用操作都进行动态验证。两层访问模式中的「令牌交换」机制正是零信任原则的体现——Agent 不持有长期凭证,每次访问都需通过身份提供商换取短期令牌,确保每个访问行为都经过实时的策略评估和审计记录。

独立收敛本身就是最有力的验证

三家厂商在极短时间内独立收敛到同一架构,本身就是这套模式合理性的最有力证明。当不同团队面对相同约束、独立设计,却得出高度相似的结论时,往往说明这不是某家公司的巧思,而是问题本身决定的最优解结构。

换句话说,即便未来 Okta、Auth0、Descope 中某一家在商业上占据主导,或者出现全新的挑战者,这套两层模式很可能会作为事实标准延续下去——厂商会更迭,模式会沉淀。

对企业和开发者的实际影响

Agent 访问管理走向标准化

对于正在部署 AI Agent 的企业而言,这次密集发布是一个明确的信号:Agent 访问管理正在从各家自研走向行业标准化。这意味着企业在选型时,应当更关注底层模式的兼容性,而非被单一厂商的功能清单所绑定。

重新设计 Agent 权限架构

开发者和架构师需要意识到,将 AI Agent 简单地当作「一个拥有超级权限的服务账户」来接入,是危险且短视的做法。围绕「代表用户行动的 Agent」重新设计权限模型——明确授权范围、确保可追溯、支持可撤销——将成为未来企业 AI 基础设施的必修课。

Agent 可观测性与审计合规

在 AI Agent 大规模进入企业系统后,可观测性(Observability)和审计合规成为不可忽视的维度。与传统的人类用户操作不同,Agent 的操作频率高、决策链复杂,且单次任务可能跨越数十个系统调用。欧盟《人工智能法案》(EU AI Act,2024 年正式生效)明确要求高风险 AI 系统必须具备完整的日志记录和可追溯能力;美国 NIST 在 2024 年发布的 AI 风险管理框架(AI RMF 1.0)也强调 AI 系统需具备透明性和可审计性。两层访问模式天然支持审计需求——每次令牌交换都经过身份提供商,形成完整的操作日志链。但企业仍需关注:Agent 的决策过程(为什么选择调用 A 应用而非 B 应用)能否被记录和解释、Agent 在多系统间传递的数据是否符合数据驻留法规(如 GDPR 的跨境数据传输限制)、以及 Agent 的异常行为是否能被实时检测和阻断。

跨厂商互操作性值得期待

由于三家厂商共享底层模式,未来出现跨厂商互操作协议的可能性大大增加。这对企业是好消息:它降低了厂商锁定的风险,也为构建真正开放的 AI Agent 生态奠定了基础。

新兴标准：MCP 与 A2A 协议

除了三家身份厂商的 Cross App Access 方案,AI Agent 生态中还涌现出两个重要的互操作标准。MCP(Model Context Protocol,模型上下文协议)由 Anthropic 于 2024 年底提出,旨在标准化 AI 模型与外部工具/数据源的交互方式,为 Agent 提供统一的工具调用接口。Google 则在 2025 年推出了 A2A(Agent-to-Agent)协议,专注于解决不同 Agent 之间的通信和协作问题。这两个协议与身份认证层面的两层访问模式形成互补关系:MCP/A2A 解决的是 Agent 的能力扩展和协作通信问题,而两层访问模式解决的是 Agent 在执行这些操作时的身份验证和授权问题。未来成熟的 Agent 基础设施很可能同时需要这三层:身份层(两层访问模式)、能力层(MCP)和协作层(A2A),共同构成 AI Agent 的基础设施栈。

多 Agent 协作中的信任链挑战

当前讨论主要聚焦于单个 Agent 的跨应用访问,但企业实际部署中正快速出现多 Agent 协作场景——例如一个编排 Agent(Orchestrator Agent)调度多个专业 Agent 分别完成数据采集、分析和报告生成任务。这种多 Agent 架构引入了信任链传递问题:用户授权给编排 Agent,编排 Agent 是否有权将部分权限委托给子 Agent?子 Agent 的行为是否仍在原始用户的授权范围内?这类似于密码学中的证书链信任模型,但复杂度更高——因为 Agent 的行为是动态的、非预定义的。目前业界正在探索的方案包括:层级化委托令牌(每次委托都缩小权限范围)、Agent 信任评估(基于 Agent 的历史行为打分)以及基于意图的授权(不是授权具体操作,而是授权目标意图,由策略引擎判断具体操作是否符合意图)。Google 的 A2A 协议在这一方向上有初步探索,但成熟方案仍有待行业共同定义。

结语

八天,三家厂商,同一个模式。这场看似巧合的产品竞赛,实际上勾勒出了 AI Agent 时代身份管理的清晰轮廓。谁赢得市场并不是最重要的——真正持久的,是那套被反复验证、独立收敛的两层访问模式。对于所有正在或即将拥抱 AI Agent 的组织来说,理解这一底层逻辑,比追逐任何单一产品都更有价值。

核心要点

• 2025年8月-9月,Okta、Auth0、Descope 三家身份认证厂商在八天内同步推出 Cross App Access 能力,标志着行业对 AI Agent 访问管理难题达成共识
• AI Agent 打破了传统 IAM「访问主体是人」的核心假设,其「长期委托+自主执行+跨应用协作」的特性让 OAuth/SAML 等现有协议捉襟见肘
• 三家厂商独立收敛到相同的两层访问模式:第一层(身份与授权层)明确 Agent 代表谁、权限范围;第二层(应用间访问层)通过令牌交换实现安全跨应用调用
• 该模式通过委托令牌(JWT)、细粒度权限范围(Scoping)和动态令牌交换机制,将零信任原则落地到 Agent 场景,避免 Agent 持有长期凭证
• 对企业的影响:Agent 访问管理走向标准化,应关注底层模式兼容性而非厂商功能清单;需重新设计权限架构,避免将 Agent 当作超级服务账户;同时需关注 Agent 可观测性和审计合规要求
• 独立收敛验证了两层模式是问题的最优解,未来可能演化为跨厂商互操作标准,降低厂商锁定风险
• AI Agent 基础设施正在形成三层栈:身份层(两层访问模式)、能力层(MCP 协议)和协作层(A2A 协议),三者互补共同支撑 Agent 生态
• 多 Agent 协作场景引入信任链传递挑战,层级化委托令牌和基于意图的授权是未来重要探索方向