OpenID Connect for Agents (OIDC-A)

• OpenID Connect for Agents (OIDC-A) is a protocol extension that defines secure identity representation, delegation, and attestation for autonomous agents within OAuth 2.0 infrastructures.
• It introduces agent-specific JWT claims for identity, delegation chains, and attestation tokens, ensuring verifiable provenance and integrity of agent operations.
• The protocol supports fine-grained, capability-based authorization and dynamic client registration, enhancing secure interactions in API-driven environments.

OpenID Connect for Agents (OIDC-A) is a formal extension to OpenID Connect Core 1.0 that establishes a standards-based, interoperable protocol for representing, authenticating, delegating, attesting, and authorizing LLM-based and other autonomous agents in OAuth 2.0 environments. OIDC-A directly addresses the surge of autonomous agent population and API-driven workloads by introducing mechanisms for first-class agent identity representation, secure delegation, endpoint and claim discovery, provenance-preserving attestation, and fine-grained, capability-based authorization, while maintaining full compatibility with extant OAuth 2.0 and OpenID Connect infrastructures (Nagabhushanaradhya, 30 Sep 2025).

1. Agent Identity Representation and JWT Claims

OIDC-A systematically augments the traditional set of OIDC claims within the ID Token, introducing categories dedicated specifically to the identity, provenance, delegation, capability, and integrity of AI-driven or LLM-based agents (Nagabhushanaradhya, 30 Sep 2025). New agent-specific JWT claims (all residing in the payload) include:

• Core Agent Identity Claims
  • agent_type (REQUIRED): Discrete class of agent (“assistant”, “coding”).
  • agent_model (REQUIRED): Underlying LLM or reasoning engine (“gpt-4”, “claude-3-opus”).
  • agent_version (RECOMMENDED): Model version string (e.g., “2025-03”).
  • agent_provider (REQUIRED): Hosting entity (FQDN, e.g., “openai.com”).
  • agent_instance_id (REQUIRED): Globally unique per-execution-instance identifier.
• Delegation and Authority Claims
  • delegator_sub (REQUIRED): Subject (“sub”) of the delegator in the most recent step.
  • delegation_chain (OPTIONAL): Array, each element recording a full chronological delegation step, each with fields
  • {iss, sub, aud, delegated_at, scope, [purpose, constraints, jti]}.
  • delegation_purpose (RECOMMENDED): Human-readable intent.
  • delegation_constraints (OPTIONAL): Key-value resource/time/global constraints.
• Capability, Trust, Attestation Claims
  • agent_capabilities (RECOMMENDED): Array listing model/agent’s granular capabilities (e.g., “email:read”, “calendar:view”).
  • agent_trust_level (OPTIONAL): Coarse trust status (“verified”, “sandbox”, “untrusted”).
  • agent_attestation (RECOMMENDED): Remote attestation token or reference (format, evidence blob, timestamp).
  • agent_context_id (RECOMMENDED): Opaque conversation/task context handle.

Mathematically, OIDC-A constrains delegation as follows:

• Maximum delegation depth: $\lvert\text{delegation\_chain}\rvert \leq L_{\max}$.
• Monotonic scope reduction: for all $i$, $\text{scope}_i \subseteq \text{scope}_{i-1}$.

The composite agent JWT thus encodes not just a static identifier, but also a full runtime, provenance, and policy envelope binding the agent’s model, instantiation, delegation ancestry, and attributed capabilities.

2. Structure and Validation of Delegation Chains

OIDC-A encodes agent delegation with a time-ordered “delegation_chain” array, each step codified as a JSON object with required (“iss”, “sub”, “aud”, “delegated_at”, “scope”) and optional fields (purpose, constraints, jti, and potentially step-local signatures).

Formal properties enforced:

• Each issuer (“iss”) must be trusted, often validated against a registry or federation authority.
• If a step is independently signed (step.jws), its JWS must validate against the issuer’s JWK set.
• delegated_at timestamps are monotonically increasing.
• For $i > 0$, delegation_chain[i].aud matches delegation_chain[i-1].sub.
• Each scope is a subset: $\text{scope}_i \subseteq \text{scope}_{i-1}$.
• Any violation, such as scope escalation or invalid signature, leads to rejection.

Validation is algorithmically defined as (see (Nagabhushanaradhya, 30 Sep 2025)):

for i in range(len(chain)): # check issuer trust and signature # check timing, audience, and scope # enforce constraints ...

This guarantees provenance auditability, monotonic attenuation of privileges, and a verifiable principal-to-agent-to-service chain of authority, supporting both agent-subclass and multi-tenancy patterns.

3. Agent Attestation and Integrity Verification

OIDC-A provides explicit machinery for runtime integrity attestation. The agent_attestation claim conveys a structured evidence blob (typically EAT, JWT, or COSE) and format label, which resource servers or relying parties can verify independently or by POSTing to a deployment-specific agent_attestation_endpoint.

Supported mechanisms:

• The agent or its execution environment generates the attestation (e.g., TPM/TDX/SNP-SEV/TEE), signs with a provider or enclave root, and populates agent_attestation.token.
• Relying parties verify using attestation verification keys, extracted from OIDC Discovery metadata (attestation_verification_keys_endpoint).
• Integrity metrics (PCRs, model hashes, measurements) must match known-good reference values. Optional “nonce” claims prevent replay, and timestamps are freshness-checked.
• Out-of-band verification by POSTing to the endpoint allows offloading detailed attestation checks to the agent provider, yielding a signed verified: true confirmation.

This explicit inclusion of remote attestation enables trust elevation and risk-adaptive policy, facilitating runtime assurance that the agent instance corresponds to the provisioned code and model, enforcing both compliance and non-repudiation.

4. Protocol Endpoints, Discovery, and Lifecycle Extension

OIDC-A prescribes several protocol-level extensions to the foundational OIDC suite (Nagabhushanaradhya, 30 Sep 2025):

• Registration and Discovery
  • Dynamic Client Registration incorporates explicit fields for agent_provider, supported model strings, capability taxonomy, attestation/delegation formats.
  • OIDC Discovery documents gain fields for endpoints and metadata relevant to agents, including:
  • agent_attestation_endpoint, agent_capabilities_endpoint
  • Claim and type enumerations, supported delegation and attestation mechanisms
  • Verification key URIs for attestation evidence
• Authorization Flow
  • The scope request parameter can be extended with “agent” to trigger agent claim population.
  • The delegation_context parameter (opaque JSON) seeds a fresh multi-step delegation context.
  • The token endpoint merges or amends the validated delegation_chain in issued tokens.
• Token Introspection
  • OIDC-compliant introspection responses may include all OIDC-A agent claims to downstream resource servers.

All endpoints and claims are designed for compatibility and forward-integration with policy engines, resource servers, and federated OAuth deployments.

5. Capability-Based Authorization and Policy Integration

OIDC-A directly exposes granular agent capabilities in the agent_capabilities claim. These are not limited to OAuth2 scopes but can enumerate arbitrary, fine-grained operations (e.g., “calendar:modify,” “transaction:sign:usd<1000”). Integration patterns include:

• Importing agent_capabilities into XACML- or OPA-style policy decision points; each capability is mapped as an attribute of the token’s subject, allowing the resource server to implement custom, business-specific access control rules.
• Mapping claims to conventional OAuth scopes, allowing drop-in support for existing policy enforcement architectures.
• Combining delegation_constraints, trust_level, and attestation verification with capabilities to support risk- or context-adaptive authorization: certain operations may require “verified” agents with attestation evidence, stricter time-window constraints, or provable low-risk execution environments.

This explicit capability modeling supports least-privilege design and cryptographically-enforceable separation of agent duties across tasks and downstream workflows.

6. Comparison with Prior Art and Interoperability

OIDC-A operationalizes agent identity and delegation following foundational proposals in OAuth-based agent infrastructure (Chan et al., 17 Jan 2025, South et al., 29 Oct 2025), decentralized identity designs (DID, VC), and capability-based access control. Unlike prior practice, it provides:

• Native protocol mechanisms for agent-specific claims and attestation, instead of encoding agent attributes into custom fields or relying on out-of-band metadata.
• Full provenance of delegation steps, with monotonic scope guarantees and verifiable, revocable audit trails.
• Integrity and runtime attestation directly in the token, not merely as static registration attributes.
• Compatibility with industry-standard OAuth 2.0, OIDC, and established central/federated authorization systems.
• Ready integration with policy engines and resource servers; tokens can be introspected for all capabilities and delegation proofs required for real-time risk assessment, compliance, and incident attribution (Nagabhushanaradhya, 30 Sep 2025, South et al., 29 Oct 2025).

These design elements have been identified as missing or insufficiently formalized in traditional or emergent agent authorization frameworks, and OIDC-A concretizes them in a standards-oriented, extensible protocol.

---

OIDC-A establishes a comprehensive, standards-aligned solution for representing, attesting, delegating, and authorizing LLM-based and autonomous agents, employing explicit protocol-level claims, cryptographically-verifiable delegation and integrity mechanisms, and fine-grained capability statements in a manner transparent to and compatible with existing OAuth/OIDC service ecosystems (Nagabhushanaradhya, 30 Sep 2025).