HashiCorp Vault issues short-lived, dynamic secrets on demand instead of storing static ones, and it authenticates the identity requesting a secret before deciding what to hand over. That combination — dynamic issuance plus policy-gated access — is close to the right shape for AI agent credentials. Which specific tool call an agent is making a request for is a separate question, expressed at a finer resolution than Vault's path-based policy language, that agent governance has to add in front of it.
What Vault's dynamic secrets pattern actually does
Vault's defining capability, relative to a static secret store, is that it can generate credentials on request rather than only storing ones created elsewhere. A database secrets engine, for example, can create a database user with a defined permission set at the moment a workload requests access, hand back credentials with a lease attached, and revoke that database user automatically when the lease expires. The same pattern extends to cloud provider credentials, certificates, and other secret types through Vault's various secrets engines. The security property this produces is real: a credential that did not exist an hour ago and will not exist an hour from now has a fundamentally smaller attack surface than a password that has been sitting in a config file since a project's first sprint.
Access to any of this is gated by an auth method — Vault verifies the requester's identity (through a platform-specific mechanism like a Kubernetes service account token, a cloud instance identity, or an AppRole credential) and then evaluates policy attached to that identity to decide which secret paths it may read and what it may do with them. This is a workload-identity-adjacent model: authenticate what's asking, then gate by policy, described in more general terms in machine identity vs. workload identity vs. agent identity.
For agent deployments, dynamic secrets solve a problem that static-secret patterns handle badly: an agent fleet that is spinning up and tearing down instances continuously, or scaling elastically with demand, needs a credential-issuance model that doesn't assume a fixed, long-lived set of holders. Vault's lease-based model was built for exactly that kind of dynamism, even though it predates agent workloads specifically.
Where the policy model runs out of resolution
Vault's policy language is fundamentally path-based: an identity may read, write, or manage secrets at a given path or path pattern. That is the right resolution for "may this service read database credentials for the orders database" — a question with a stable, predictable shape. It runs out of resolution for the questions agent governance actually needs answered:
Which tool call justifies this request. Vault sees a request for a secret from an authenticated identity, evaluated against path-based policy. Expressing "only issue this secret if the agent is currently executing the specific tool call that legitimately needs it" is a finer-grained condition than that policy language is built for — an agent identity with policy access to a path can request a secret from that path for any reason, at any time, as long as the identity checks out, unless a layer in front of Vault adds that condition.
On whose behalf. An agent acting for different users or tenants over the course of its operation presents the same Vault identity each time, unless something upstream binds the request to the current principal. Vault's auth methods authenticate the workload; carrying "and this specific call is for user X's task" is a separate binding a layer above Vault has to add, which is the same on-behalf-of gap covered generally in the confused deputy problem.
Delegation depth. If an orchestrator agent retrieves a secret and needs a sub-agent to act on it, that hand-off is outside Vault's own visibility — from Vault's perspective, one authenticated identity requested one secret. Narrowing what the sub-agent actually receives, versus what the orchestrator was entitled to, is a decision made in the layer outside Vault, in line with the scoping pattern in sub-agent delegation with scoped tokens.
Lease duration vs. task duration. A lease is a fixed, pre-configured duration decided when the secrets engine and role are set up, rather than one that dynamically shrinks to the length of the specific task using it. A task that completes in seconds against a lease configured for tens of minutes leaves the credential valid for the entire remainder of the lease, unless something actively revokes it on completion.
Patterns that work well for agent fleets
A few Vault-native patterns hold up well specifically for agent workloads:
- Short TTLs by default, renewed rather than long-lived. Configure leases as short as your infrastructure's issuance latency tolerates, and let workloads renew rather than issuing long leases for convenience. A leaked credential's usefulness is bounded by how quickly it expires.
- Dynamic database and cloud credentials over static ones wherever a secrets engine supports the target. Every credential type Vault can generate dynamically is one fewer static secret sitting in a config or environment variable.
- Response wrapping for credential delivery. Wrapping a secret in a single-use, time-limited token for delivery to the requesting workload limits exposure if the delivery channel itself is logged or intercepted somewhere along the way.
- Revoke on completion, not just on expiry. Explicitly revoking a lease when a task completes, rather than letting it run to its configured TTL, shrinks the window further and is worth the extra call for anything touching sensitive systems.
Where to put the missing layer
The gap Vault leaves — task-level and tool-level authorization — is best closed by a broker sitting in front of Vault rather than by trying to force that resolution into Vault's own policy language. The broker receives the agent's request for a specific tool call, evaluates it against current policy (which agent, which principal, which tool, is this within the task's scope), and only then requests the underlying secret from Vault — immediately wrapping it in a scope and lifetime matched to the call rather than passing through whatever lease Vault issued by default. This mirrors the general token-exchange pattern in OAuth 2.0 token exchange for agent-to-tool authorization: Vault remains the system that safely mints and revokes the underlying credential, and the broker is where the per-call decision lives.
What good looks like
- No static, long-lived secrets for anything a Vault secrets engine can generate dynamically — databases, cloud credentials, certificates.
- Lease durations are as short as operationally tolerable, with renewal rather than long default TTLs, and explicit revocation on task completion for sensitive workloads.
- A broker layer sits between agents and Vault, evaluating each request against the current task and principal before requesting the underlying secret.
- Sub-agent delegation narrows the credential's effective scope at each hop rather than forwarding the parent's full Vault-issued secret unchanged.
- Audit records tie each Vault-issued lease to the specific agent, principal, and task that triggered it — not just the authenticated identity that made the API call.
A note on secrets vs. tokens
It's worth being precise about a distinction that gets blurred in practice: a Vault-issued dynamic secret is a credential for a downstream system (a database user, a cloud key), while a token in the agent-identity sense is a claim about who is acting and on whose behalf. Vault is excellent at the first; the second is a separate concept to layer on top rather than express through Vault's own policy language. Teams that try to route both through Vault's path-based policy end up either over-provisioning Vault roles to approximate per-task scoping — a fit that gets unmanageable fast as the number of distinct tasks grows — or under-scoping and accepting that any authenticated agent identity can pull any secret its role permits, whenever it wants. Keeping the two concerns in separate systems, with the broker translating between them, avoids both failure modes and keeps Vault's own policy set small enough to actually audit.
Common questions
Is Vault's audit log sufficient for agent governance audit requirements? Vault's audit log records every request and response against its own API accurately, which is valuable evidence of what secrets were issued to which identity when. Recording which tool call or task the request served is a separate layer of context, so pairing Vault's log with an application-level audit trail that carries that context is necessary for governance and compliance evidence, not just secret-issuance evidence.
Does using Vault remove the need for workload identity infrastructure? No — they solve adjacent but distinct problems. Vault's auth methods need something to authenticate against (a Kubernetes service account, a cloud instance identity, a certificate), and workload identity infrastructure, covered in mTLS, SPIFFE, and workload identity for agents, is commonly what supplies that underlying identity in the first place.
Should every agent get its own Vault AppRole or identity? Where feasible, yes. Sharing one Vault identity across many agents collapses Vault's audit trail into one undifferentiated principal, the same attribution loss described for shared workload identities in why agents need their own credentials. Per-agent identities cost more to provision initially and pay for themselves the first time an incident requires attributing a specific secret retrieval to a specific agent.