[控场AI]
· 4 分钟阅读· 2,174 字

Agent间SSO跨身份域:Okta Agent SSO揭示的非人类身份联邦

Agent间SSO跨身份域:Okta Agent SSO揭示的非人类身份联邦

Okta推出Agent SSO,揭示非人类身份联邦的协议空白与标准缺位。

文章分析Okta近期推出的Agent SSO功能,探讨当AI Agent代表企业与其他Agent交互时,身份联邦面临的特殊挑战。传统SSO依赖人类在场、浏览器跳转和实时授权,而Agent场景缺失这些锚点,现有SAML/OIDC协议围绕人类设计难以直接套用。Okta的做法是将Agent视为一等身份主体,复用现有身份治理设施签发断言完成跨域信任传递,但多层级委托链的断言验证与有效性判断仍是未解难题。文章指出跨公司Agent身份在唯一标识、权限级联、责任归属上缺乏行业标准,厂商产品先行带来互操作风险。企业应提前将Agent纳入身份清单、设计最小权限委托并保留完整审计链。

当AI Agent开始代表企业与其他企业的Agent直接交互时,身份认证的基石正在被动摇。Okta近期推出的Agent SSO功能,试图回答一个根本性问题:在两个身份域之间,当双方都不是人类时,联邦认证该长什么样?

Agent to agent SSO across identity domains

为什么Agent身份联邦比人类SSO更难

传统SSO解决的是"一个人如何跨域访问资源"的问题——用户在场、有浏览器、有明确的同意动作。而Agent to Agent的SSO场景中,发起方是一个自动化程序,它可能代表某个组织的业务逻辑去调用另一个组织的Agent服务。这里缺失了人类SSO中天然存在的几个锚点:没有交互式的登录界面、没有用户实时授权、也没有"这个身份背后是谁"的直观判断。

据Okta对Agent SSO的定位,其核心思路是将Agent视为一等身份主体,为其颁发可验证的凭据,并在跨域时通过身份联邦协议完成信任传递。但问题在于,现有的SAML、OIDC等联邦协议都是围绕人类用户设计的,Agent的身份生命周期、委托链、权限边界都需要新的表达方式。

SAML与OIDC是当前主流的身份联邦协议。SAML(安全断言标记语言)基于XML,通过身份提供方(IdP)向服务提供方(SP)签发断言来传递认证与授权信息,常用于企业级单点登录。OIDC(OpenID Connect)构建在OAuth 2.0之上,使用JSON Web Token(JWT)传递身份信息,更适配现代Web与移动应用。两者的共同前提是:存在一个人类用户,其在IdP完成认证后,浏览器携带令牌或断言跳转至目标域。Agent场景下没有浏览器重定向、没有用户会话,断言的签发与验证必须改为机器对机器的直接交换,这要求协议支持非交互式的信任建立与凭据轮换。

Okta Agent SSO的实际做法与局限

Okta的Agent SSO方案本质上是在既有身份平台上扩展出Agent身份类型,让Agent可以像用户一样被纳入策略管理、审计日志和访问控制。跨域场景下,它依赖身份提供方之间的联邦信任关系,由源域为Agent签发断言,目标域据此做出授权决策。

这套做法的价值在于复用成熟的身份治理基础设施——企业不需要为Agent另建一套认证体系。但它的局限同样明显:当Agent的委托关系变得多层(Agent A代表用户调用Agent B,Agent B再调用Agent C),断言链条如何保持可验证且不膨胀?目标域如何判断源域对Agent的授权是否仍然有效?这些在Okta的发布中并未给出完整答案。

委托链(Delegation Chain)指一个主体代表另一个主体行事的层级关系。在Agent场景中,用户授权Agent A,Agent A再授权Agent B,形成链式委托。每一层委托都需附带可验证的凭据,证明当前Agent确实获得了上游主体的授权。问题在于,若每层都附加完整断言,令牌体积会随层级线性增长(断言膨胀);若只传递摘要,则目标域难以独立验证整条链的完整性。现有OAuth的Token Exchange(RFC 8693)规范提供了部分思路,允许令牌在传递中变换受众与权限,但尚不支持任意深度的委托链验证,这正是Okta方案未覆盖的空白。

标准缺位:跨公司Agent身份的核心难题

Okta Agent SSO的推出,恰好暴露了跨公司Agent身份领域尚未完成的标准建设。当前行业在几个关键问题上没有共识:Agent身份的唯一标识如何跨域解析、Agent的权限委托能否级联、以及当Agent行为出现争议时责任如何归属。

这些问题不是单一厂商能解决的。Okta提供了产品化的实现,但跨组织互操作需要的是开放标准——类似OAuth之于授权、OIDC之于身份。Agent身份联邦的标准化进程仍在早期,厂商产品先行、标准跟进是现实路径,但也意味着早期采用者会面临互操作风险。

Agent身份的唯一标识需要解决跨域解析问题:同一Agent在不同身份域中可能拥有不同的本地标识,目标域如何确认“这个标识就是源域中那个Agent”?类似人类身份中的联邦标识(如eduPersonPrincipalName)或去中心化标识符(DID),Agent也需要一种可全局解析且可验证的标识方案。目前行业尚未统一,部分提案尝试用可验证凭据(VC)绑定Agent的公钥与元数据,但跨厂商互认机制仍缺失。标识不统一将直接阻碍跨公司Agent调用的信任建立,也是标准缺位中最基础的一环。

对企业实践的启示

对于正在部署Agent的企业,Okta Agent SSO释放的信号很明确:Agent身份治理需要提前规划。实践中应关注三点:一是将Agent纳入身份清单管理,避免出现影子Agent;二是审慎设计Agent的委托权限,尤其是跨域调用时的最小权限原则;三是保留完整的Agent行为审计链,为未来标准落地后的迁移留出空间。

Agent间SSO不会简单复制人类SSO的路径。身份联邦的下一章,需要为"非人类主体"重新设计信任的语法。

#Agent SSO#身份联邦#Okta#Agent身份#跨域认证#身份治理#非人类身份
分享:

相关推荐