What is OIDC-A?

OIDC-A (OpenID Connect for Agents) is a proposed extension to OpenID Connect that defines how to represent an AI agent's identity, validate the delegation chain linking it back to the user or system that authorized it, and verify a cryptographic attestation of its properties before granting it access to a service. It was published as a paper in September 2025 by Subramanya N, discussed publicly on GitHub and Hacker News, and remains an open technical proposal today, not a standard ratified by the OpenID Foundation. The problem it tackles is specific and technical: non-human identities for AI agents already pose a scale and governance problem today, but OIDC-A operates one layer upstream, the protocol by which a system authenticates an agent, verifies who delegated it to act, and decides which capabilities to grant, instead of simply treating it as a service account with a fixed token.

How it extends classic OIDC

OpenID Connect authenticates a human user and returns an ID Token with claims about who they are. OIDC-A adds claims designed for an agent: who created it, which model powers it, and above all a delegation chain, the sequence of steps starting from the original user and potentially passing through several intermediate agents before reaching whoever executes the final action. Each step in the chain can be verified individually, so a downstream service does not have to blindly trust the last link but can trace the chain back to the human request that started it all. Alongside this sits attestation, a cryptographic proof of the agent's integrity and origin compatible with existing frameworks such as IETF RATS and Entity Attestation Tokens, and capability-based authorization, where permissions are not assigned to the agent as one single block but to the specific capabilities it needs for that particular task.

Why it is emerging now

As long as AI agents performed single, supervised tasks, a generic OAuth token was enough. With agents acting on behalf of other agents, in delegation chains that can run three or four steps deep before touching a production system, classic authentication no longer distinguishes "who asked for what" along the chain: a system only sees the last request, with no way of knowing whether the agent that generated it had the authority to do so. OIDC-A exists to close exactly this protocol-level gap, not to replace agent-to-agent or agent-to-tool communication mechanisms such as MCP or A2A, which solve how an agent talks to a tool or another agent, not who the agent is or what it is allowed to do.

An enterprise example

A procurement agent gets instructed by a manager to renew a software contract within a spending cap, and to do so it delegates to a finance agent the task of checking available budget. With OIDC-A, the finance system receiving the request can verify the full chain, manager, procurement agent, finance agent, and grant only the capability "read the budget of category X", not blanket access to the entire accounting system. Without this layer, the finance system only sees a valid token and has no way of knowing whether the request genuinely originated from a legitimate human authorization.

Why it matters for decision makers

OIDC-A is not ready for an adoption mandate: it is a proposal, not an OASIS-grade standard with tested conformance at scale, and security roadmaps should treat it accordingly. But the problem it addresses, authenticating and authorizing agents that delegate to other agents, is not solved by any existing perimeter control, and it is the direction major identity management vendors are already moving toward. Whoever is designing an identity architecture for enterprise AI agents today should track its evolution closely, if only to avoid rebuilding permission management from scratch once standardization arrives.