The Token Vaulting Pattern for AI Agents

Current agentic access control solutions, either defined in the Model Context Protocol (MCP) or implemented in agents, do not give users fine-grained control over the agent's capabilities. The user is supposed to delegate access to the agent and, in many cases, is held responsible for the agent's actions. Yet the user has no or only crude means to control those actions. When connecting an agent to an MCP server, the user usually needs to grant the agent elevated permissions. The initial OAuth flow used to connect to the server results in providing the agent with an access token that allows it to call all the tools the server provides.

Some MCP servers use step-up authorization (e.g., by using URL elicitation) and limit access to some tools. However, such an approach still has some drawbacks:

• It means that the agent will eventually get hold of a high-privilege access token. The agent will be able to make subsequent calls to sensitive tools without the user's interaction (and potentially knowledge).
• The control remains at the MCP server provider's discretion. The consumer of the MCP server (a user or an organization) is not able to apply its own policies to control tool access.

Any tool-calling control implemented on the MCP client's side (e.g., the agent asking whether it's fine to call a given tool in response to a prompt) has pretty much the same limitations: the user (or organization) is not able to apply their own fine-grained policies. It is also easy to fall into consent-fatigue, and, as a result, provide the agent with too much privilege or long-standing privilege. Both situations might lead to unintended abuse from the agent.

Implementing your own MCP clients or servers could allow you to overcome these limitations. However, such solution is impractical. Instead, at Curity, we think you can solve this by using an architecture we called the token vault pattern.

Token Vaulting Flow

In overview, the token vault is a component responsible for:

• securely storing high-privilege MCP servers' access and refresh tokens,
• applying policies that govern when to release the sensitive tokens,
• releasing the tokens during calls to MCP servers.

Applying the pattern allows issuing the agent only short-lived, low-privilege, opaque access tokens, which greatly limits any potential for abuse.

With this approach, users and organizations gain a central place where they can define fine-grained policies for tool access. For example, it becomes possible to allow the agent to call a mail-sending tool if it wants to send emails to some predefined recipients, like the user's team, but reject sending emails to any other recipients.

The token vault pattern relies heavily on the standard Token Exchange OAuth flow. Whenever the agent makes a call to an MCP server, it sends the opaque, low-privilege token. A gateway performs a token exchange flow against the token vault. The vault validates the incoming token, verifies its policies, and releases the high-privilege provider's token. The gateway then injects the provider's token into the request, so that the MCP server can use it to make its own authorization decisions. This way, the agent never receives the high-privilege token and is not able to misuse it.

Policies allow for fine-grained access control without the user's explicit approval of a tool call. The user can safely allow the agent to call any tool, knowing that the vault's policy will stop the agent from invoking sensitive ones. The vault can use policies to reject agents' access to specific tools at an MCP server and to elicit step-up authorization. The vault's policy can result in asking for additional user approval when an agent tries to perform a sensitive action. Agents that operate without a user interface can obtain such an approval via back-channel communication. For example, by using a Client-Initiated Back-Channel Authentication (CIBA) flow, the vault can push a notification to the user asking for consent.

With the introduction of a token vault, users ensure that agents operate with the least privilege and with no standing privilege. This helps keep systems secure from incidental agentic abuse.

Token Vaulting Components

The token vault is a concept that organizations can implement in different ways. You can think of it as 2 components:

• The main component is your authorization server, which should manage token storage, token vaulting configuration, and token exchange policy so that you do not need to deploy home-grown token management solutions. If you use an existing secure vault for other secrets, the authorization server should be able to integrate with the external vault.

• The second component is an extension to your API gateway. The gateway receives the low-privilege access token from the AI agent and makes token exchange requests to the authorization server. The authorization server applies its policy and can return a vaulted token to the gateway to forward to the upstream MCP server. The gateway can optionally cache token exchange results for a short time to improve performance under load.

Example Implementation

Curity's example implements the vault using bucket storage and an application plugin. A Curity Identity Server administrator configures the application plugin with:

• the MCP server providers,
• the policy for releasing tokens from the vault.

The example also provides an Azure API Management gateway policy that initiates token exchange. When an agent connects to an MCP server using the token vault pattern, it establishes an authorized connection using a low-privilege opaque access token. The agent then uses these tokens to send tool call requests. The gateway exchanges the Curity Identity Server tokens for the vaulted ones. The Curity Identity Server checks token exchange policies using code similar to the following:

val requiredScope: String = determineScopeRequiredForToolCall(toolName)

val presentedTokenScope = decodedToken["scope"] as String

// Check if the presented token satisfies tool call policy.
if (!presentedTokenSatisfiesPolicy(presentedTokenScope, requiredScope)) {

    // Check if the user consented to release of high-privilege token for the requested tool call.
    val userConsentedToElevatedPermissions = verifyUserConsents(requiredScope, toolName)

    if (!userConsentedToElevatedPermissions)
    {
        // Return a 400 response that will trigger URL elicitation.
        return insufficientScopeResponse("insufficient_scope: Required scope missing: $requiredScope")
    }
}

// Return a token response that contains the provider's token.
return buildTokenResponse(getProvidersToken(subject, resourceId))

Every provider is an MCP server that the user connects to and uses from an agent, like a GitHub MCP server or an Atlassian MCP server. The policy maps the Curity Identity Server scopes to tools exposed by the provider. It requires tokens to have a specific scope in order to call concrete tools of a provider's MCP server.

If the token satisfies the policy (the agent calls a non-sensitive action), then the gateway receives the provider's token and inserts it into the request forwarded to the provider's MCP server. The agent never receives the provider's token.

If the agent tries to run a sensitive action, then the token exchange fails with information about the required high-privilege scope. The gateway sends back to the client an elicitation request with a URL that starts a new OAuth flow against the Curity Identity Server. In that flow, the user has an option to consent to the high-privilege scope, after which the agent is able to successfully finish the sensitive task.

Video Overview

The following video shows the proof of concept in action.

Watch

Conclusion

The authorization solutions offered by MCP and agents give limited control over the agents' behavior. With the introduction of a token vault, users regain control of what their agents are allowed to do. The component leans on proven standards already used in MCP to minimize friction. It allows applying fine-grained policies to agents, regardless of whether the agent has a direct interface with the user or works on a backend. The solution adds a much-needed control so that users and organizations can utilize agents in a safe and responsible way.

Published: 2026-07-17

Michał Trojanowski

Product Marketing Engineer at Curity