Agentic SSO: what Auth 3.0 means when the user is an AI agent

The short answer

Agentic SSO — Auth 3.0 — is identity and authorization designed for the case where the “user” is an AI agent acting under delegated human authority. Human SSO answers one question: who is the human. Agentic SSO answers a chain: who delegated what authority, to which agent, for which app, for which action, with what proof at execution time.

What is agentic SSO?

Agentic SSO is single sign-on rethought for a world where the entity holding the credential is not a person. The shorthand “Auth 3.0” is our framing for the third iteration of the problem: Auth 1.0 was a password per app. Auth 2.0 was federated human identity — OAuth, OIDC, “log in with Google”, SAML for the enterprise. Both versions share one assumption: the credential holder is the actor, and the actor is a human who can read a consent screen.

Agents break that assumption in both directions. The credential holder (an agent runtime) is not the authority (the human who deployed it), and the actor can issue a refund at 3 a.m. without anyone reading anything. Auth 3.0 is what you get when humans, teams, agents, apps, delegations, approvals, signed execution, audit, and authority tokens are designed together instead of bolted on one at a time.

Why doesn’t human SSO cover AI agents?

Traditional auth answers exactly three questions:

• Who is the human?
• What app session does the human have?
• What role does the human hold?

Those answers are necessary and stay necessary. But they describe a session, not an action. When an agent calls issue_refund, the session-shaped answer is “the API key belongs to the workspace” — which tells you nothing about whether this agent was delegated the authority to refund money right now, and leaves no evidence either way. The common workaround — give the agent a broad API key, a hardcoded allowlist, or direct tool access — is fragile the moment agents can send messages, issue refunds, change settings, update customer records, or run admin actions.

What are the 9 questions an AI-native app has to answer?

This is the Auth 3.0 problem, stated as a checklist. For every consequential action, an AI-native app needs an answer to:

1. Which agent is acting?
2. Which human or workspace delegated authority to that agent?
3. Which app is the agent allowed to use?
4. Which action is being requested?
5. Is the action allowed, approval-gated, or blocked?
6. Was approval current at execution time?
7. Was execution signed?
8. Can the app verify action-bound authority without trusting raw API responses?
9. Is there audit evidence for the whole chain?

Score your current stack against this list. A Clerk session answers none of them. A god-mode API key answers none of them. Most production agent deployments today answer between zero and two.

What does the Auth 3.0 chain look like?

One chain, nine links, each one a verifiable fact rather than an assumption:

Workspace
  -> Human identity and role
      -> Agent identity
          -> App
              -> Action permission
                  -> allow / ask / block
                      -> approval if needed
                          -> signed execution
                              -> audit evidence

The model separates five things that human auth collapses into one “logged-in user”:

• Human identity — the person or team member.
• Agent identity — the specific AI runtime, holding its own revocable token (not the human’s session, not a shared key).
• Delegated authority — the explicit permission matrix from human to agent to app to action.
• App authority — what the app can verify before it executes, via action-bound authority claims and JWKS, instead of trusting whatever the agent’s HTTP client says.
• Audit evidence — who delegated, what the agent requested, what was decided, who approved, what was signed.

How is this different from Clerk, Auth0, and MCP?

It’s a third corner, not a replacement for the other two:

Clerk and Auth0 authenticate humans. MCP connects agents to tools. Auth 3.0 is delegated authority — the verified chain from a human, through an agent, to an app, down to a single action.

The three compose rather than compete, which is why there are two product shapes:

Product	Best for	Auth posture
Arc AI Auth	Existing SaaS teams that already have users and auth	Keep Clerk/Auth0/Okta/custom. Add Arc for agent authority.
Arc Auth 3.0	New AI-native apps starting from zero	Arc’s human auth foundation plus Arc-native agent identity, delegation, approvals, signed execution, and audit.

Same authority engine in both. The only difference is where human login starts.

What exists today, and what’s on the roadmap?

To be precise about claims — the agent-side primitives exist in Arc today: an agent registry with revocable agent tokens, human-to-agent delegations, a per-action allow / ask / block permission matrix, an approval workflow for ask actions, signed execution delivery, action-bound authority claims with JWKS and OIDC-like metadata, app-side verification helpers, and an audit trail with export and verification. These are the parts generic human-auth providers do not solve.

What Arc does not provide yet: Google or Apple login, full enterprise SSO, OAuth/OIDC provider certification, or a mature passkey/MFA/account-recovery surface. Arc has OIDC-like metadata and JWKS for authority verification, but it does not claim full OIDC provider status. The full Arc Auth product — scoped, revocable identity for agents as a standalone offering — is the next item on the roadmap. Human login polish can wait; modeling agent authority can’t.

FAQ

What is Auth 3.0? Auth 3.0 is identity and authorization where humans, teams, agents, apps, delegations, approvals, signed execution, and audit are designed together. Auth 1.0 = a password per app. Auth 2.0 = federated human SSO (OAuth/OIDC/SAML). Auth 3.0 = delegated authority, for the case where the actor is an AI agent rather than the human who authorized it.

Is agentic SSO the same as OAuth for agents? No. OAuth grants an app access on a user’s behalf with scopes minted at consent time. Agentic SSO adds what OAuth doesn’t model: a distinct revocable agent identity, an explicit human → agent → app → action delegation, per-action allow / ask / block decisions, approvals that must be current at execution time, signed execution, and audit evidence for the chain.

Can I keep Clerk or Auth0 and still get agent authentication? Yes. That is exactly the Arc AI Auth posture: your existing provider keeps answering “who is the human,” and Arc layers agent identity, delegation, approvals, signed execution, and audit on top. You only take Arc’s human-auth foundation if you’re starting an AI-native app from zero.

Does Arc support Google login, passkeys, or enterprise SSO for agents’ owners today? Not yet — no Google/Apple login, no full enterprise SSO, no OAuth/OIDC certification, no mature passkey/MFA surface. Those are roadmap. The agent-side primitives (registry, revocable tokens, delegations, allow/ask/block, approvals, signed execution, audit) exist in Arc today.

---

Arc Auth — scoped, revocable identity for agents — is next on the Arc roadmap. Join the newsletter for early access →