What is a token vault?

Why do AI agents need a token vault?

AI agents increasingly take real actions on behalf of users: scheduling meetings in a calendar, posting to chat, updating CRM records, or reading files through tools exposed over MCP servers. Every one of those actions requires a provider token. The naive pattern is for each agent to hold its own refresh tokens in environment variables or config files, which recreates the worst habits of API key handling and feeds secret sprawl at agent speed. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024 alone, and 70% of secrets leaked in 2022 were still valid three years later.

There is also a protocol mismatch. OAuth assumes an interactive user with a browser who can complete a consent redirect. A headless agent cannot pop a login screen every time it needs access. A token vault resolves this by capturing the user's consent once, storing the resulting grant, and then issuing short-lived tokens to the agent on demand. That makes it the storage half of the agent delegation problem: the user authorizes once, and the vault brokers every subsequent access.

How does a token vault work?

The flow has three phases. First, connection: the user completes a normal OAuth consent flow with each provider (Google, Microsoft, Slack, GitHub, and so on), and the vault stores the resulting refresh token encrypted at rest, bound to that user and that connection. Second, exchange: when an AI agent needs to act, it presents its own credential to the vault and receives a fresh provider access token, downscoped where the provider supports narrower scopes. Implementations commonly build on OAuth 2.0 Token Exchange (RFC 8693), where a subject token represents the user and an optional actor token represents the agent, so the delegation chain can be preserved rather than flattened into a single anonymous credential, where the identity provider supports actor claims.

Third, maintenance: the vault handles refresh and rotation centrally, outside agent code. Agents never see refresh tokens at all; they receive only short-lived access tokens scoped to the immediate task. When a user offboards or revokes consent, the grant is severed in one place instead of being hunted down across every agent that ever cached it.

What are the core capabilities of a token vault?

A token vault is an architectural pattern rather than a standard, so vendor implementations differ, but the capability set is converging.

• Encrypted storage of OAuth access and refresh tokens, keyed per user and per provider connection
• Token exchange that issues short-lived access tokens at request time, downscoped where the provider supports it
• Automatic refresh and rotation handled centrally, outside agent logic
• Delegation records that preserve both the user (subject) and the agent (actor) behind each access
• Access control governing which agents may obtain tokens for which connections
• Audit logs of every token issuance and exchange for compliance and incident response

Why does a token vault become your highest-value NHI store?

A token vault concentrates the delegated access of many users across many SaaS providers into one system. That is the point, and it is also the risk. A stolen OAuth token already reflects a completed login and MFA challenge, so replaying it walks past those controls entirely: Microsoft reported 147,000 detected token replay attacks in a single year, a 111% increase. An attacker who compromises a vault, or an agent identity authorized to draw from it, inherits ready-made access to email, files, and business systems without ever touching a password. The failure modes look like session hijacking and account takeover, but laundered through a legitimate broker.

The subtler risk is misuse without compromise. An agent with standing rights to pull tokens for several services is a textbook confused deputy: a prompt injection buried in an email or document can steer the agent into using perfectly valid vault-issued tokens for an attacker's purpose. The vault sees a routine, authorized exchange. Nothing in the storage layer distinguishes a legitimate request from a hijacked one.

Token vault vs secrets manager: what is the difference?

A secrets manager manages credentials that belong to workloads and services themselves, and modern ones issue dynamic credentials and short-lived certificates rather than only storing static keys. A token vault manages user-delegated OAuth grants and performs protocol-level exchange: it does not just hold a token, it mints fresh, scoped ones and maintains the user-to-agent delegation chain. Put differently, a secrets manager answers how a workload proves its own identity, while a token vault answers how an agent safely borrows a user's access.

The two are complementary. Most organizations running agents at scale need both: a secrets manager for machine credentials, and a token vault for the delegated, per-user grants that agents consume. Treating either as a substitute for the other leaves half the credential estate unmanaged.

How do you secure a token vault?

Because a vault concentrates delegated access, it must be treated as tier-zero infrastructure, with controls that assume it will be targeted.

• Scope every issued token as narrowly as the task allows, applying least privilege to scopes, not just roles
• Keep refresh tokens inside the vault; agents should receive only short-lived access tokens, consistent with zero standing privileges
• Authenticate agents to the vault with strong, unique workload credentials, never a shared API key
• Inventory which agents hold vault grants and revoke them as part of the NHI lifecycle when agents are retired
• Monitor issuance patterns and downstream token use with runtime identity security and identity threat detection, since the vault's own logs end at issuance

Frequently asked questions

Related terms