Executive summary
For more than two decades, enterprise single sign-on (SSO) was engineered around a fundamental assumption: the entity authenticating is a human sitting in front of a screen with a browser, capable of typing credentials, acknowledging biometric prompts, and completing multi-factor authentication (MFA) challenges.
The explosion of autonomous AI agents, copilots, and machine-to-machine integrations has shattered this paradigm. Today, non-human identities (NHIs) outnumber human employees by more than 10 to 1, yet the vast majority are managed using unmonitored "service accounts" backed by static, long-lived API keys.
To prevent catastrophic identity sprawl, enterprises must evolve from Human SSO to Agent SSO. Powered by Cross-App Access (XAA) and open token exchange standards, Agent SSO establishes a governed, secretless control plane that treats AI agents as first-class directory citizens bound to verified human owners.
Why traditional human SSO fails for autonomous AI agents
Applying human authentication workflows to autonomous software agents introduces three critical architectural failures:
1. The interactive prompt barrier
Human SSO relies on interactive browser handshakes (SAML 2.0 assertions and OIDC authorization code flows) paired with out-of-band MFA pushes. Autonomous AI agents execute in backend runtimes, headless containers, and asynchronous tool loops where human interaction is impossible at runtime.
2. The "black box" attribution problem
When engineers cannot use Human SSO for an automation script or AI copilot, they default to creating a generic service account (for example, svc-jira-bot@company.com). When this account executes actions, downstream audit logs only record the service account name. If an agent modifies a sensitive record or extracts data, SecOps teams cannot determine which human initiated the prompt or which AI model executed the API call.
3. Permanent, over-privileged blast radius
Unlike human sessions that expire after inactivity, service accounts rely on static API tokens or client secrets stored in plaintext configuration files. Because developers build agents to handle diverse tasks, these tokens are routinely granted broad administrative privileges, creating persistent targets for credential scrapers and prompt-injection attacks.
Defining Agent SSO: The three core architectural pillars
Agent SSO does not mean giving an AI agent its own username and password. Instead, it introduces an identity-brokered delegation architecture built on three pillars:
Pillar 1: First-class non-human directory registration
In an Agent SSO framework, autonomous agents are registered directly in Universal Directory as distinct non-human entities. Each agent profile contains metadata that tracks.
The human owner (sponsor): The authenticated employee or team accountable for the agent's behavior.
Permitted tool catalog: The specific downstream applications and APIs the agent is authorized to interact with.
Lifecycle expiration: Automatic deactivation policies linked to project end-dates or the departure of the human sponsor.
Pillar 2: Dynamic token exchange through Cross-App Access (XAA)
Instead of relying on hardcoded API keys, Agent SSO leverages OAuth 2.0 Token Exchange (RFC 8693). When an AI agent needs to perform an action on behalf of a human:
The agent presents the initiating user's authenticated identity context to the Identity Provider (IdP).
The IdP evaluates organizational policies and dynamically mints a short-lived (5–15 minute), audience-bound access token.
The token contains only the minimal permissions required for that specific downstream API call (for example, aud: "salesforce.com", scope: "leads: read"), reducing standing privileges.
Pillar 3: Cryptographic dual-attribution telemetry
Agent SSO tokens embed dual-identity claims defined by open identity standards:
sub (subject): The identity of the human user who prompted the action.
act (actor): The identity of the AI agent executing the tool call.
This cryptographic chain of custody helps ensure that every downstream system logs both actors, satisfying SOC 2, HIPAA, and ISO audit requirements without manual correlation.
Architecture comparison: Human SSO vs. service accounts vs. Agent SSO
Capability | Traditional Human SSO | Legacy service accounts | Agent SSO with Cross-App Access |
Identity principal | Human employee | Generic shared account | Registered AI agent principal |
Credential type | Passwordless/Okta FastPass biometrics | Static, long-lived API keys/secrets | Dynamic, short-lived ephemeral tokens |
Authentication flow | Interactive SAML/OIDC browser redirect | Hardcoded point-to-point basic/bearer auth | On-demand Token Exchange (RFC 8693) |
Scope of access | Broad role-based permissions (RBAC) | Over-privileged permanent admin rights | Dynamic downscoping per tool call (least privilege) |
Audit attribution | Human user only | Service account only (No human context) | Dual-Attribution (sub = Human, act = Agent) |
Offboarding Lifecycle | Automated via HR-driven LCM | Manual cleanup (frequently orphaned) | Automated JML linked to human sponsor |
Threat Response | User session logout/password reset | Manual API key rotation across codebases | Sub-second Universal Logout via SSE/CAEP |
How Cross-App Access solves non-human identity sprawl
- Reducing the "Secret in the Code": With Cross-App Access and Token Vault patterns, developers do not embed API keys in prompt templates, code repositories, or local environments. Authentication is brokered entirely through the identity plane.
- Constraining the AI Blast Radius: If an AI agent experiences prompt injection, the attacker cannot pivot to other enterprise systems. The agent's token is strictly audience-bound to a single downstream service and expires within minutes.
- Automated lifecycle governance: When an employee leaves the company, Lifecycle Management (LCM) automatically disables their profile in Universal Directory. Because all of their sponsored AI agents are tied to their identity, agent delegations are instantly revoked, helping prevent orphaned autonomous processes.
- Instant Containment (The universal kill switch): If an agent exhibits anomalous behavior or excessive API queries, Identity Threat Protection leverages Shared Signals and Events (SSE / CAEP) to revoke all active delegated tokens across Salesforce, Google Workspace, and Jira in sub-second response times.
Immediate action checklist for IAM and security leaders:
- Audit unmanaged service accounts: Identify all shared accounts with names containing bot, service, script, or sync and map their active API token lifespans.
- Establish non-human identity registration: Require engineering teams to register all internal copilots and third-party AI tools in Universal Directory with a designated human sponsor.
- Mandate Cross-App Access for multi-app agents: Enforce RFC 8693 token exchange for any AI agent or microservice that accesses downstream SaaS platforms on behalf of human workers.
- Implement dual-attribution logging: Verify that your security information and event management (SIEM) pipeline ingests both the sub and act JWT claims to maintain complete audit visibility across agentic workflows.
Take control of non-human identity security
Ready to secure non-human identities across your enterprise? Learn more about Okta Workforce Identity.
