Skip to main content
A Token Vault stores credentials per user and enforces the mapping between users and the credentials they’re allowed to use. When you run AI agents in a multi-user environment, it’s the foundation that carries your existing access boundaries over to the agents unchanged.

​
The Confused Deputy Problem behind it

The Confused Deputy Problem occurs when a requester without permission gets a more privileged entity to exercise that permission on their behalf. Agent platforms shared by several users often keep access tokens for third-party services in a shared credential store. Without control over which user may use which credential, one user can start a session with another user’s credentials. The agent then reaches external services with the permissions of the credential’s owner, not the requester. In a setup built on shared credentials such as a Machine User or an API key, the risk of bypassed access boundaries grows unless the mapping is managed precisely.

​
Where OAuth fits

OAuth is an authorization protocol that lets a user delegate part of their account’s permissions to an application. The user reviews the requested scope on a browser consent screen, and the application receives an access token that represents only that scope. Because the token is guaranteed to be a subset of the user’s existing permissions, an agent that talks to the backend with this token alone preserves the original access boundary. Agents connect to several services, and tokens expire. A Token Vault manages where the tokens obtained per user are kept and how the agent uses them at runtime.

​
Architecture

A Token Vault consists of three parts.

​
The vault

Separate vaults per user, holding OAuth access and refresh tokens or fixed tokens such as API keys. Register a refresh token and a token endpoint, and the vault can renew access tokens on its own. The Credential Vault in Claude Managed Agents implements this layer. Credentials are re-resolved periodically during execution, so rotation takes effect without restarting the session.

​
The registration interface

Give end users a screen where they can register and update only their own credentials, closing every path to anyone else’s. From the user’s point of view, it’s just an OAuth button per service. Behind it, the system maps the user identified by your authentication layer to their vault and records the user identifier in the vault’s metadata.

​
Token retrieval

When the agent calls a tool, the token is resolved from the vault of the user bound to that session and used for the request to the external service. This keeps resource reads, updates, and deletions within the user’s existing permissions.

​
Operational cautions

​
Verify the requester-to-vault mapping on every request

Verify the requester’s identity on every request and resolve that person’s vault and no other.

​
Keep scopes to least privilege

OAuth controls permissions in units of scopes, so for an agent that only needs to read, configure read-only scopes and obtain tokens with those.

​
Compensate for coarse scopes

Unlike Cloud IAM, the OAuth scopes services commonly support express only broad permission categories and can’t control access per resource. Move resources that demand careful handling into a separate tenant, out of reach of the token.

​
What you gain

The access boundaries already configured in your existing third-party services keep working through the agent. Users can only drive the agent within their own permissions, and the Confused Deputy Problem becomes structurally impossible. Credential management stays separated from agent code, and revocation and rotation happen in one place. For audits, the vault-to-session mapping tells you whose permissions performed which operation.

​
Cross App Access and ID-JAG

A Token Vault still leaves some work on the table. Users walk through an OAuth flow per service, and administrators maintain the user-to-vault mapping themselves. Okta’s Cross App Access addresses this. It’s an OAuth extension built around the Identity Assertion Authorization Grant, known as ID-JAG. Once a user logs in to the IdP, access tokens for each service are obtained from the ID token via an assertion, with no browser involved. Users never see a per-service consent screen. The IdP becomes the hub for token issuance, so administrators centrally control which clients can obtain tokens for which services and gain visibility from the issuance records. With it in place, every connection passes through central identity policy and lands in the logs, letting you manage and monitor which agents access which services.

​
The practical answer until adoption

Cross App Access and ID-JAG only work once the IdP, each service’s authorization server, and the client all support them. While you wait, the practical answer is a Token Vault. Establish centralized permission management, revocation, and auditing with a Token Vault first, and when Cross App Access arrives everywhere, the only thing that changes is how tokens are obtained. The principle of whose permissions the agent acts under stays intact.

​
References