Why existing identity protocols fail for agents
OAuth 2.0 and OpenID Connect were designed for human users signing into conventional applications. Autonomous LLM-based agents don't fit either half of that sentence. They are not humans — they have model identity, provider identity, instance identity, and capability surface. They are not conventional applications — they act on behalf of users through delegation chains that may include other agents.
The current protocols have no constructs to represent any of this. The result is that every team deploying agents today is improvising their own identity model — custom JWT claims, ad-hoc delegation tokens, service-to-service workarounds. None of it interoperates.
OIDC-A is a proposal for what the standard version of this should look like.
What OIDC-A adds
OIDC-A extends OpenID Connect Core 1.0 with four new concept families.
1. Agent identity claims
A set of JWT claims that describe the agent itself, not the user it represents:
agent_type— the class of agent (e.g., "llm", "traditional", "hybrid").agent_model— the specific model identity (provider-specific or vendor-neutral).agent_provider— the organization running the model.agent_instance_id— a stable identifier for the deployed instance.
These claims are emitted by an agent-aware authorization server and travel with the access token.
2. Delegation chains
When a user authorizes an agent to act on their behalf, and that agent in turn invokes another agent, the authority flows along a chain. Existing OAuth has no first-class representation of this — and the lack of it is the root cause of many "who actually authorized this call" audit failures.
OIDC-A defines a delegation_chain claim: an ordered list of principals through which authority flowed, each with its own type and identifier. The end of the chain is the acting agent; the start is the human (or system) that initiated the authorization.
3. Attestation and integrity
Agents should be able to prove not just who they are but what they are — that the model weights haven't been swapped, that the runtime hasn't been tampered with, that the capability surface is what the caller thinks it is.
OIDC-A proposes attestation claims backed by strong client authentication: mutual TLS, JWT client assertion, and provider-signed attestation documents. An authorization server implementing OIDC-A can choose to accept or reject a token based on attestation freshness and the attestation provider's root of trust.
4. Capability discovery
Every agent has a capability surface — the tools, data sources, and actions it can execute. Resource servers benefit from knowing this in advance. OIDC-A defines a capability-discovery mechanism that lets a resource server introspect an agent's declared capability set and make authorization decisions accordingly.
How it fits with existing standards
OIDC-A is strictly additive. It is built on:
- RFC 6749 — OAuth 2.0 Authorization Framework.
- RFC 7519 — JSON Web Token (JWT).
- OpenID Connect Core 1.0 — identity layer on top of OAuth 2.0.
An authorization server that implements OIDC-A is still a conformant OIDC authorization server. A resource server that doesn't understand the agent claims can ignore them and fall back to standard OIDC semantics. The design is deliberately non-breaking so the transition path is gradual.
Why this matters for Agentic Labs
At Agentic Labs we ship Agentic Trust — an embedded copilot SDK that drops into any SaaS. The moment you have a copilot acting in-product on behalf of a user, you need to answer: which identity is making this API call? The user's? The agent's? The agent's provider's? All three, in sequence?
The current OAuth stack can't express that cleanly. We've felt this pain first-hand, which is why OIDC-A exists.
Status
OIDC-A is an early-stage specification proposal. The draft is public on GitHub. Feedback, implementations, and critiques are welcome — especially from identity and access management implementers, authorization server vendors, and teams deploying agents at scale.
If you're hitting the same problem and want to compare notes, we'd like to hear from you.