2026 年 8 月 · 6 分钟阅读

关键定义
Agent SSO Okta 于 2026 年 8 月 24 日宣布正式可用的 SSO 扩展:基于开放的 Cross App Access 协议,把兼容的 AI Agent 注册为身份体系中的一等身份,用身份托管的短时令牌替代静态 API 密钥,对 Agent 到应用、API 与 MCP 服务器的连接实施集中治理。
Cross App Access(XAA) 由 Okta 主导、多家 AI 平台与 SaaS 厂商采纳的开放 OAuth 扩展协议,为 Agent 到应用、应用到应用的连接提供企业级身份授权;已被 Model Context Protocol 正式纳入其『企业托管授权』扩展。
8月24日Okta宣布Agent SSO正式可用:基于开放的Cross App Access协议,把AI Agent注册为Universal Directory中的一等身份,与人类员工一起治理,用短时令牌替代静态API密钥。但只有34%的组织对Agent施加与人类员工相同的安全控制。
当 Agent 开始替你订差旅、改工单、查客户记录时,它拿什么身份去访问企业系统?过去最常见的答案是硬编码 API 密钥或宽泛的 OAuth 授权——密钥长期有效、范围过大、谁在用不可见。Okta 在发布材料中给出的数据是:只有 34% 的组织对『数字劳动力』施加与人类员工相同的安全控制,其余 Agent 像匿名网络流量一样运行,没有集中可见性、管理监督或生命周期审计轨迹。
这正是 Agent SSO 要解决的起点。Okta 表示,Agent SSO 把开放的 Cross App Access(XAA)标准直接带入被 2 万多家客户使用的身份产品中,让组织把 Agent 建模为一等身份,由集中策略统一治理——就像当年 SSO 把人类访问决策集中到身份提供方一样,Agent 授权也从单个应用层上移到企业身份提供方。
XAA 是 OAuth 的扩展,已被 MCP 正式纳入其『企业托管授权』扩展,由 Okta 最初主导、被 Anthropic、Zoom、Slack 等 25 家以上早期采用者采纳。当一个支持 XAA 的 Agent(例如 Anthropic Claude)连接企业应用时,Agent SSO 会把它注册为 Universal Directory 中的一等身份,与人类员工并列可见;管理员可以像治理人类员工一样分配、监控、更新其安全策略。
Okta 给出的产品定位是回答两个问题:『我的 Agent 在哪里?』——通过把每个受支持 Agent 注册为一等身份,跨平台集中可见;『它们能连什么?』——用身份治理的短时令牌替代硬编码凭据和宽泛授权,确保 Agent 在最短权限策略下只能连接被许可的应用、API、工具和 MCP 服务器。Okta Integration Network(OIN)提供开箱即用的集成,包括 Anthropic (Claude)、Asana、Atlassian、Canva、Datadog、Figma、Glean、Linear、Notion、Slack、Supabase 等。
第三方分析(quasa.io,8 月 26 日)提醒不要把 Agent SSO 理解成『治理了所有 Agent』。覆盖率取决于两端都支持 XAA:请求方 Agent、目标应用/API/MCP 服务器以及连接角色都必须兼容,否则仍需要其他集成、控制或传统凭据。Agent SSO 对核心 SSO 套餐客户不额外收费,但它建立的是一层身份与授权基础,而不是对整个 Agent 生命周期的监督——取得令牌后 Agent 在范围内做什么,不在 Agent SSO 的判定范围内。
与之衔接的是 4 月已 GA 的 Okta for AI Agents:负责更广泛的 Agent 发现、生命周期治理、访问评审、遥测与运行时控制。企业应把 Agent SSO 视为起点而非终点——先解决『谁能连』,再解决『连接后能做什么』。
把 Agent 当一等身份,而不是一个 API key
每个 Agent 应有独立身份、独立生命周期与最小权限。Okta 调研显示 58% 的高管把 AI 治理列为与 Agent 相关的头号安全担忧,但仅有 34% 落实了与人类员工相同的控制——优先级与实践之间存在明显落差。
用短时令牌缩小长期暴露面
即使尚不接入 XAA,也应把静态密钥替换为按需签发的短时凭据,并对 Agent 可访问的资源做白名单化,防止一个 Agent 被攻破后横向扩散到整个环境。
区分『连接治理』与『行为治理』
Agent SSO 解决的是连接层的身份与授权;运行时行为、影子 Agent 发现与生命周期退役仍需更完整的 Agent 治理体系。两者都要投入,缺一层都不完整。
OOMeta AI
OOMeta 的 AI 治理平台帮助企业建立 AI Agent 清单、身份与访问基线、运行时监控与事件响应流程,把『Agent 一等身份』这类供应商能力落成组织内可执行的治理机制。
预约诊断会参考来源:
· Okta 官方发布(2026-08-24):Okta brings first-class identity to AI agents with Agent SSO
· Okta 调研数据(34%):AI Agents at Work 2026
· 独立分析(2026-08-26):Okta Agent SSO Went GA August 24, but Coverage Is Limited
· Okta for AI Agents GA(2026-04-28):Okta for AI Agents is Now Generally Available
普通 SSO 在身份提供方集中管理人类用户的登录访问;Agent SSO 把同样的模式延伸到 AI Agent——把 Agent 注册为 Okta Universal Directory 中的一等身份,与人类员工并列管理,让身份策略直接约束 Agent 到应用、API 和 MCP 服务器的连接。
基于 Cross App Access 协议,Agent SSO 用身份治理的短时令牌取代硬编码凭据和宽泛的 OAuth 授权:令牌只覆盖被许可的应用、API、工具与 MCP 服务器,并在最短权限策略下按需签发,从而缩减长期静态凭据的暴露面。
不能。它只覆盖兼容 XAA 的连接:请求方 Agent、目标资源与协议都必须支持相应流程。Okta 与第三方分析都指出,覆盖率取决于生态支持,未被 XAA 覆盖的 Agent 仍需 Okta for AI Agents 等更完整的治理产品来发现与管理。
Okta 的调研显示,仅 34% 的组织对『数字劳动力』始终施加与人类员工相同的安全控制。原因在于历史上把 Agent 接入企业应用需要碎片化的点对点方式,使其像匿名网络流量一样运行,缺乏集中可见性、管理监督与生命周期审计轨迹。
Agent SSO 是基础层,回答『Agent 在哪里』和『能连什么』;Okta for AI Agents 是更完整的产品,回答『能做什么』——提供未托管 Agent 的发现、全生命周期治理与运行时精确控制。两者互补而非替代。
BCG提出『企业AI控制面』:当Agent铺满全公司,平台级治理已经不够用
BCG 8月14日发布《企业AI控制面:CIO治理与加速AI Agent指南》:当企业跨多平台、多业务部门部署成百上千个Agent时,逐平台治理导致重复投入、成本失控与安全风险。EACP在平台之上统一身份、资产注册、运行时策略与『黄金路径』部署,把治理变成最快的上云路径,号称让合规Agent交付快10倍。
Agent 闯祸谁来担责?加州 AB 316 与行政令 EO 14409 把责任钉回企业,连 CISO 都可能被个人追责
美国 AI Agent 责任规则收紧:加州 AB 316 禁止『AI 是独立法律实体、自主致害』的抗辩;白宫 EO 14409 指示司法部优先起诉 AI 未经授权入侵;保险商把 AI 责任排除出 CGL 与 Tech E&O 保单。CSO Online 梳理了从公司到 CISO/CIO 个人的责任链条。
按能力分级治理:Snyk 分析 3,044 家企业,Agent 治理的下一个纪律是『按模型能力』而非『按用途』
Snyk 2026《Agentic AI 采用现状·卷二》分析 3,044 家企业与约 139 万代码仓库:33% 已采用 Agent 化架构,50.3% 同时运行 Agent 与 MCP;仅一半组织能在代码层追溯到训练数据。报告提出『能力分级治理』——按模型自主能力(ECI 评分)而非供应商或用途配置不同控制。
跨组织 Agent 治理真空:所有框架都假设“单一所有者”,澳大利亚 AISI 首次点名
澳大利亚 AI 安全研究所(AISI)首发报告揭示:NIST、OWASP、新加坡等 16 个主流 Agent 治理框架都建立在“单一组织控制所有 Agent”的假设上,跨组织交互的风险没有责任主体,也超出所有框架范围。