Every AI agent in your pipeline is an enthusiastic new hire with the credentials of a tenured one. (Welcome to 2026.) It gets a token at the start of the job, does whatever the prompt suggested next, and hands the audit trail back to you. So when a secrets store of Vault's reach says it has had enough of that arrangement, it is worth a careful read.
HashiCorp put native AI agent support in Vault Enterprise into public preview this week. The pitch is short: agents stop authenticating like long-lived workloads and start authorizing like OAuth clients, per request, with the action they want to perform attached. The Vault team built it on RFC 9396, the IETF spec for OAuth 2.0 Rich Authorization Requests, with the authorization_details claim required by default.
What actually shipped
Two pieces, doing related work:
- A new agent registration flow in Vault Enterprise, surfaced in the Terraform Vault Provider as
vault_agent_registration. It binds an agent to a Vault identity entity, lets you set a ceiling policy that caps what the agent can ever be granted, and pins the JWT issuer, audience, signing algorithm and clock-skew behaviour the agent's tokens must satisfy. - An OAuth resource server configuration, exposed in the same provider as
vault_oauth_resource_server_config_profile. This is what teaches Vault how to validate the agent's bearer JWTs against an external identity provider, via JWKS endpoints or static public keys, with namespace-consistent settings so the same profile lines up across Vault instances.
On the identity side, HashiCorp lists IBM Verify, Auth0 and Microsoft Entra as the providers Vault is wired to accept tokens from in this preview.
The behavioural shift sits in the authorization_details claim. Where Vault policies historically described what a token could do for as long as it lived, the Rich Authorization Requests model expects the agent to declare what it intends to do on each call: which scope, which action, on which resource. Vault evaluates the request against the ceiling policy and either honours the narrowed scope or refuses. HashiCorp calls it a "secure-by-default approach" and pitches it as "least privilege for AI agents at scale".
Why this matters once an agent lives inside CI
If your pipeline still treats credentials as one-per-job, this looks like a heavy upgrade for a problem you do not have. The trouble is that pipelines no longer just run scripts a human wrote. They run coding agents, review agents, deployment agents, any of which can stretch "what this job is allowed to do" in directions the original policy author never imagined.
A static token in the job environment is a blank cheque to whatever the prompt asks for next. Per-request authorization changes the question from "should this job have access to anything in this namespace" to "should this specific call, with these specific parameters, be allowed right now". That second question is the one your auditor wants answered, and usually the one you cannot answer from job logs.
There is also the agent identity problem proper. Workload identity for pods and runners has settled into well-understood patterns (SPIFFE, OIDC federation, cloud metadata). Agent identity has not. Vault's preview plants a flag: an agent is a first-class principal, registered, scoped by a ceiling, obliged to ask before it acts.
Wiring it in, schematically
The shape of a real configuration, with the values left as placeholders and the schema sketched, not reproduced. Check the docs for the actual attribute names before you apply.
resource "vault_oauth_resource_server_config_profile" "agents" {
name = "<profile-name>"
# JWT issuer, JWKS endpoint (or static public keys),
# audience, signing algorithm, clock-skew and JWT-type
# validation per the provider schema.
...
}
resource "vault_agent_registration" "review_bot" {
name = "<agent-name>"
# association with a Vault identity entity,
# reference to the OAuth resource-server profile above,
# and the ceiling policy that caps the agent's reach.
...
}
The agent then presents a JWT from your chosen identity provider, with an authorization_details claim describing the action it actually wants to take. Vault checks the claim against the ceiling policy. If the request asks for more than the ceiling permits, it does not get downgraded. It gets refused.
HashiCorp has also opened a Vault Agentic Security Beta Program, so if your team is going to find the rough edges first, you might as well feed them back through the front door.
Caveats worth pinning to the door
This is Vault Enterprise, in public preview. Read both words. Semantics that look stable in the docs can still move before GA, and teams paying for Vault Community are reading about a feature they do not get.
The ceiling policy is defence in depth, not a substitute for thought. A policy that ceilings an agent at "anything in this namespace" is still a policy that ceilings an agent at anything in this namespace. The per-request claim only helps if the ceiling is tight.
And the Rich Authorization Requests claim is only as honest as the client sending it. If the agent is compromised by prompt injection, a malicious tool call, a poisoned context, it can declare whatever authorization_details the attacker wants, up to the ceiling. The preview shrinks the blast radius of an over-privileged token. It does not turn an agent into a trustworthy narrator of its own intentions. That gap stays open, in your tool-call review.
How others have approached the same gap
Cloud identity providers have spent the last few years pushing OIDC federation so jobs trade short-lived tokens at runtime instead of stashing static ones. SPIFFE/SPIRE pushes attestation down to the workload itself. Some platform teams already use broker layers that mint per-call credentials in front of their secrets stores. Vault's preview lands on the policy-engine side of that stack, with the actions an agent can take spelled out per request, not baked into the token.
The common thread: "long-lived secret in the job env" is no longer a defensible position once the job is partly written by an LLM. Different vendors pull on different ends of that rope. Pick the one whose failure mode you can live with.
Verdict
Good direction, with the right caveats. Rich Authorization Requests are not a HashiCorp invention; Vault adopted them and made them the default for a class of clients that badly needed an opinionated answer. The Terraform surface keeps the operational ergonomics where they already live. If your roadmap already includes "stop trusting the bearer token in our agent's env", the preview gives you somewhere concrete to point.
Will it survive contact with the agents you actually run? Ask your prompt-injection log. The bar Vault just raised is the bar for credentials. The bar for what the agent decides to do with them is still yours to set.
