AI agent support

Vault Enterprise provides native support for AI agents through two related capabilities:

• Agent Registry — Enrolls, governs, and audits agentic identities.
• OAuth resource server configuration — Lets Vault validate OAuth 2.0 tokens issued by trusted authorization servers so clients can authorize access to Vault directly.

Together, these capabilities let an approved agent present an OAuth 2.0 token to Vault without a separate login step. Vault validates the token, resolves the client to a Vault Identity entity, checks the entity's Agent Registry record, and enforces authorization constraints for agentic workflows.

For API usage details, refer to:

• Agent Registry API
• OAuth Resource Server API

How Vault supports native AI agents

Native AI agent support combines identity, credential validation, and governance:

1. Vault validates an OAuth JWT using an OAuth resource server configuration profile.
2. Vault resolves the authenticated client to a Vault Identity entity.
3. Vault checks whether the relevant entity has an Agent Registry record.
4. Vault evaluates the entity's baseline policies and, for delegated on-behalf-of workflows, the agent's authorization ceiling.

Vault Identity answers the question "who is this client?" The Agent Registry answers the question "is this client an approved agent, and what governance constraints apply to it?" OAuth resource server configuration answers the question "which external OAuth JWT issuers does Vault trust, and how should Vault validate their tokens?"

Agent Registry

The Agent Registry is a Vault Enterprise component that provides enrollment, governance, and auditing for agentic identities. It operates alongside the Identity secrets engine to distinguish agents from other types of Vault clients and to enforce authorization constraints specific to agentic workflows.

Relationship to Vault Identity

Every registered agent maps to exactly one Vault Identity entity. The entity carries authentication bindings, aliases, and baseline policy attachments, just as it does for any other Vault client. The Agent Registry adds a record that captures governance metadata and authorization constraints that are specific to agents.

The two components have distinct responsibilities:

An entity can exist without an Agent Registry record. In that case, the entity represents a non-agent client and is not subject to agent-specific governance. An Agent Registry record cannot exist without a corresponding entity.

Agent Registry records

An Agent Registry record contains the following fields:

Agent Registry invariants

The Agent Registry enforces the following rules:

• One registration per entity. Each entity can have at most one registration record. If you need to re-register an entity, delete the existing registration first.

• Entity must exist. The entity_id must refer to an existing Vault Identity entity at the time the registration is created or updated.

• Display name must be unique within the namespace. No two registrations in the same namespace can share a display_name.

Authorization ceiling

The authorization ceiling is the primary governance mechanism the Agent Registry provides. It restricts what an agent can do when it acts on behalf of another identity in a delegation, or on-behalf-of, flow.

An agent's authorization ceiling cannot expand what an agent is allowed to do. In a delegated workflow, Vault evaluates two policy sets independently:

1. The subject's baseline policies must allow the request.
2. The agent's ceiling policies must also allow the request.

If either policy set denies the operation, Vault denies the request. The ceiling can only further restrict operations that the subject's baseline would otherwise permit. It can never grant additional access.

Default ceiling policies

When you create or update a registration, Vault automatically adds two built-in policies to ceiling_policies unless you set no_default_ceiling_policy to true:

• default — Vault's standard default ACL policy.
• default-ceiling — A narrow policy that permits the agent to read its own Agent Registry record and the definitions of the default and default-ceiling policies.

These defaults ensure that an agent acting on behalf of a subject cannot use the subject's permissions to modify the agent's own governance constraints.

If you set no_default_ceiling_policy to true, Vault does not add either policy automatically. You can still include them explicitly in ceiling_policies if you want one or both.

Define policies specific to the access your agent requires, then add them to the agent's ceiling_policies.

OAuth credential requirement

Vault requires an Agent Registry record for clients that authenticate using OAuth resource server credentials, also called OAuth JWTs. An entity that has no Agent Registry record cannot use OAuth credentials to make requests. If you present an OAuth credential for an unregistered entity, Vault rejects the request.

In a delegation flow, where an agent acts on behalf of a subject, the actor entity must have a registration. In a direct, non-delegation flow, the subject entity must have a registration.

OAuth resource server configuration

The OAuth resource server configuration is a Vault Enterprise feature that defines how Vault validates JWTs issued by OAuth 2.0 authorization servers. By configuring one or more validation profiles, you establish trust relationships between Vault and external identity providers, enabling Vault to accept their JWTs as authentication credentials on every request without a separate login step.

This configuration positions Vault as an OAuth 2.0 resource server. Each profile tells Vault which issuer to trust, how to verify token signatures, and which claims to enforce.

Profiles

A profile defines how Vault validates JWTs from a specific authorization server. Each profile represents a trust relationship with one issuer. You can configure multiple profiles to accept tokens from different authorization servers.

When Vault receives an OAuth JWT, it extracts the iss issuer claim and looks up the corresponding profile. If no profile matches the issuer, Vault rejects the token.

Profile fields

Key validation modes

Each profile uses exactly one of two mutually exclusive modes for validating JWT signatures:

• JWKS mode (use_jwks=true): Vault fetches the authorization server's public keys from the configured jwks_uri. Vault caches these keys and refreshes them when it encounters an unrecognized key ID, subject to rate limiting to prevent abuse.

• Static key mode (use_jwks=false): Vault uses PEM-encoded public keys provided directly in the profile configuration. Each key includes a key_id that Vault matches against the JWT kid header.

You cannot configure both jwks_uri and public_keys on the same profile.

Supported algorithms

Profiles accept asymmetrically signed JWTs only. The following signing algorithms are supported:

• RSA: RS256, RS384, RS512, PS256, PS384, PS512
• ECDSA: ES256, ES384, ES512

HMAC algorithms, including HS256, HS384, and HS512, opaque tokens, and JWE, or JSON Web Encryption, are not supported.

Issuer uniqueness

Each issuer_id must be unique across all profiles in a namespace. This constraint enables Vault to perform a direct lookup from the JWT iss claim to the correct profile without scanning all profiles.

Enabling and disabling profiles

Set enabled to false to disable a profile without deleting it. Disabled profiles are skipped during JWT validation. This allows you to temporarily suspend trust for a specific issuer without losing the profile configuration.

Namespace isolation

Profiles are scoped to the namespace in which they are created:

• Profiles in the root namespace are accessible only within the root namespace.
• Profiles in a child namespace are accessible only within that child namespace.
• There is no cross-namespace visibility or inheritance of profiles.

Each namespace maintains its own independent set of profiles with its own issuer uniqueness constraint.

How OAuth JWTs and Agent Registry work together

When a client presents an OAuth JWT in the X-Vault-Token header, Vault uses the configured profiles to validate the token. Vault extracts the iss claim, finds the matching enabled profile, verifies the token signature against the profile's keys, and checks the token's claims, including audience, expiration, and required fields, against the profile's settings.

After validation, Vault resolves the caller's identity through a Vault Identity entity alias bound to the profile's issuer and the value of the configured user_claim. The entity's policies become the caller's baseline permissions.

Vault then checks the Agent Registry requirement for the request:

• In a delegated, on-behalf-of request, the actor must have a registration.
• In a direct, non-delegated request, the subject must have a registration.

If the required entity has no Agent Registry record, Vault rejects the OAuth credential.

Managing registrations and profiles

You manage Agent Registry records through the agent-registry/ path in the Vault API. The following paths are available:

You manage OAuth resource server profiles through the sys/config/oauth-resource-server path:

For complete request and response schemas, refer to the Agent Registry API and /sys/config/oauth-resource-server API documentation.