Agent-to-Agent SSO Across Identity Domains: The Non-Human Identity Federation Revealed by Okta Agent SSO

When AI agents begin interacting directly with agents from other companies on behalf of their enterprises, the cornerstone of identity authentication is being shaken. Okta's recently launched Agent SSO feature attempts to answer a fundamental question: what should federated authentication look like between two identity domains when neither party is human?

Why Agent Identity Federation Is Harder Than Human SSO

Traditional SSO solves the problem of "how a person accesses resources across domains"—the user is present, there's a browser, and there's an explicit consent action. In the Agent-to-Agent SSO scenario, however, the initiator is an automated program that may be calling another organization's agent service on behalf of some business logic. Several anchors that naturally exist in human SSO are missing here: there's no interactive login interface, no real-time user authorization, and no intuitive judgment of "who is behind this identity."

According to Okta's positioning of Agent SSO, its core approach is to treat agents as first-class identity subjects, issue them verifiable credentials, and complete trust transfer through identity federation protocols when crossing domains. The problem is that existing federation protocols such as SAML and OIDC are all designed around human users, and an agent's identity lifecycle, delegation chain, and permission boundaries all require new ways of expression.

SAML and OIDC are the current mainstream identity federation protocols. SAML (Security Assertion Markup Language) is based on XML and conveys authentication and authorization information through assertions issued by an identity provider (IdP) to a service provider (SP), commonly used for enterprise single sign-on. OIDC (OpenID Connect) is built on top of OAuth 2.0 and uses JSON Web Tokens (JWT) to convey identity information, making it better suited to modern web and mobile applications. The common premise of both is that there is a human user who, after authenticating with the IdP, has their browser carry a token or assertion and redirect to the target domain. In the agent scenario there is no browser redirect and no user session, so assertion issuance and verification must change to direct machine-to-machine exchange, which requires protocols to support non-interactive trust establishment and credential rotation.

What Okta Agent SSO Actually Does and Its Limitations

Okta's Agent SSO solution essentially extends the existing identity platform with an agent identity type, allowing agents to be brought into policy management, audit logs, and access control just like users. In cross-domain scenarios, it relies on federated trust relationships between identity providers, with the source domain issuing assertions for the agent and the target domain making authorization decisions based on them.

The value of this approach lies in reusing mature identity governance infrastructure—enterprises don't need to build a separate authentication system for agents. But its limitations are equally obvious: when an agent's delegation relationships become multi-layered (Agent A calls Agent B on behalf of a user, and Agent B then calls Agent C), how can the assertion chain remain verifiable without bloating? How can the target domain determine whether the source domain's authorization for the agent is still valid? Okta's release does not provide complete answers to these questions.

Delegation Chain refers to the hierarchical relationship in which one subject acts on behalf of another. In the agent scenario, a user authorizes Agent A, and Agent A then authorizes Agent B, forming a chained delegation. Each layer of delegation must carry verifiable credentials proving that the current agent has indeed been authorized by the upstream subject. The problem is that if complete assertions are attached at every layer, token size grows linearly with the number of layers (assertion bloat); if only digests are passed, the target domain struggles to independently verify the integrity of the entire chain. The existing OAuth Token Exchange (RFC 8693) specification offers some ideas, allowing tokens to change audience and permissions during transfer, but it does not yet support verification of delegation chains of arbitrary depth—precisely the gap that Okta's solution leaves uncovered.

The Absence of Standards: The Core Challenge of Cross-Company Agent Identity

The launch of Okta Agent SSO happens to expose the standard-building work that remains unfinished in the field of cross-company agent identity. The industry currently has no consensus on several key issues: how an agent's unique identifier is resolved across domains, whether an agent's permission delegation can cascade, and how responsibility is attributed when an agent's behavior becomes disputed.

These problems cannot be solved by a single vendor. Okta provides a productized implementation, but cross-organizational interoperability requires open standards—similar to what OAuth is for authorization and OIDC is for identity. The standardization process for agent identity federation is still in its early stages; vendors shipping products first with standards following is a realistic path, but it also means early adopters will face interoperability risks.

The unique identifier of an agent identity needs to solve the cross-domain resolution problem: the same agent may have different local identifiers in different identity domains, so how does the target domain confirm that "this identifier is that agent in the source domain"? Similar to federated identifiers in human identity (such as eduPersonPrincipalName) or decentralized identifiers (DID), agents also need an identifier scheme that is globally resolvable and verifiable. The industry has not yet unified on this, and some proposals attempt to bind an agent's public key and metadata using verifiable credentials (VC), but cross-vendor mutual recognition mechanisms are still missing. Non-uniform identifiers will directly hinder trust establishment for cross-company agent calls, and this is the most fundamental piece of the standards gap.

Implications for Enterprise Practice

For enterprises currently deploying agents, the signal from Okta Agent SSO is clear: agent identity governance needs to be planned in advance. In practice, three points deserve attention: first, bring agents into identity inventory management to avoid shadow agents; second, carefully design agents' delegation permissions, especially the principle of least privilege for cross-domain calls; third, retain a complete audit trail of agent behavior to leave room for migration once future standards land.

Agent-to-agent SSO will not simply replicate the path of human SSO. The next chapter of identity federation requires redesigning the grammar of trust for "non-human subjects."

One-line Summary

Okta launches Agent SSO, revealing the protocol gaps and missing standards in non-human identity federation.

Paragraph Summary

The article analyzes Okta's recently launched Agent SSO feature, exploring the unique challenges identity federation faces when AI agents interact with other agents on behalf of enterprises. Traditional SSO relies on human presence, browser redirects, and real-time authorization, but the agent scenario lacks these anchors, and existing SAML/OIDC protocols designed around humans cannot be directly applied. Okta's approach treats agents as first-class identity subjects and reuses existing identity governance infrastructure to issue assertions and complete cross-domain trust transfer, but assertion verification and validity judgment for multi-layered delegation chains remain unsolved. The article points out that cross-company agent identity lacks industry standards on unique identifiers, permission cascading, and responsibility attribution, and that vendors shipping products first brings interoperability risks. Enterprises should bring agents into identity inventories in advance, design least-privilege delegation, and retain complete audit trails.