We developers create agents that interact with services such as Google, Salesforce, or GitHub to manage our calendars, review source code, respond to customers, and perform other tasks. This new paradigm unlocks incredible potential, but it also exposes a brand-new attack surface that requires serious security considerations.
To manage your calendar, an agent needs to be granted access to your Google Calendar. To access your code repositories, it also requires access to GitHub, and so on. In practice, this means your application is suddenly responsible for obtaining, storing, and managing credentials for every user and every service they connect to.
The core security question becomes: When an agent tries to fetch a credential, how do you ensure it’s for the correct user and only tha…
We developers create agents that interact with services such as Google, Salesforce, or GitHub to manage our calendars, review source code, respond to customers, and perform other tasks. This new paradigm unlocks incredible potential, but it also exposes a brand-new attack surface that requires serious security considerations.
To manage your calendar, an agent needs to be granted access to your Google Calendar. To access your code repositories, it also requires access to GitHub, and so on. In practice, this means your application is suddenly responsible for obtaining, storing, and managing credentials for every user and every service they connect to.
The core security question becomes: When an agent tries to fetch a credential, how do you ensure it’s for the correct user and only that user?
Accessing services and MCP servers from your agents
When a user authenticates with your agent, they have access only to that agent. To perform tasks on behalf of your users, the agent requires access to third-party services. Whether built-in integrations or MCP Servers, this interaction usually has two parts:
An interactive user interface: In the form of integrations, connectors, or an apps section in the interactive user interface of your agent, where the user can see a list of all the third-party services that they can connect to. Once they click on “connect”, an OAuth 2 flow is performed to obtain user-bound, least-privileged tokens. 1.
A secure token storage: Once the user completes the authorization, the obtained tokens must be stored securely. Later, when an agent requires access to data from that third-party service. It retrieves the stored access_token from the secure storage. The agent then includes this access_token in the request to the third-party service.
The token storage system must accommodate a wide variety of requirements and provide easy integration while ensuring high security.
The simple, naive approach
Agents can be built and delivered in many ways, ranging from a Chatbot, a Website, a Native Application, all the way to autonomous background agents that run in the cloud, as durable workflows.
In all scenarios, the agent may require access to data from a third party. To do so, they need credentials from our storage system. The naive approach is to expose the storage service as a low-level API, like below:
const token = getAccessTokenForUser({
userId: user.id,
provider: 'github'
});
The interface is very clear. The agent needs a GitHub Access Token for the user identified by user.id. This code can now be leveraged across the agent universally.
The problem lies in that userId: user.id parameter. The API requests that the developer simply provide an identifier for the user whose credentials it requires. This design risks compromising credentials by making access control the developer’s responsibility.
This isn’t a bug; it’s a lower-level API by design that forces the developer to assemble, integrate, and secure multiple different tools.
Pitfall: Too many privileges by default
The naive approach violates the principles of Zero Trust. In this approach, the agent always has access to every user’s credentials and, therefore, access to every user’s data at all times. A small bug in the agent code, across any integration point, can potentially lead to severe vulnerabilities:
- Broken access control: A small mistake in the code could accidentally pass the wrong
user.id. - Confused deputy risk: A malicious actor could trick the agent into requesting credentials for a different user, giving it access to sensitive data it shouldn’t have.
- Blast radius: If this service is compromised, and/or a security key for this service is leaked, attackers have access to all data for all your customers.
- Privilege escalation: Attackers can use this direct access to bypass policies and obtain access to data
In effect, this approach is equivalent to providing the AI Agent with a single API Key that can access all data for all of your users. This defeats the purpose of issuing least privilege and user-bound access tokens.
Token Vault’s secure-by-design model
We built Auth0 for AI Agent on the philosophy: secure by design. We believe security should be built-in, not bolted on.
Agents built with Auth0 for AI Agents can leverage Token Vault to access external APIs, such as Google or GitHub. This includes a secure flow to connect third-party accounts and a secure credential exchange that ensures least privilege access cryptographically.
In Token Vault, credentials are always isolated by user identity. The Auth0 Platform and our SDKs work together to ensure this user isolation is always present. The AI Agent only has access to the credentials for the current user. With a much simpler API:
const accessToken = await auth0.getTokenFromVault({
connection: "google-oauth2"
});
The most important thing to notice is what’s missing: there is no userId parameter.
The developer does not pass a simple string identifying the user. Instead, Auth0’s SDKs perform the heavy lifting behind the scenes. When accessing a token vault, our SDKs determine the best credential to access the vault on the current user’s behalf based on the current session, security domain, and agent architecture, such as a Refresh Token, Access Token, or Private Key JWT. This credential is then automatically leveraged to request access from the vault.
By requiring a credential, this flow ensures we have very strong assurances about who the user is, that the user is the rightful owner of this token, and that the agent, application, MCP Server, or API’s identity is independently verified. The agent never has the power to simply ask for arbitrary user credentials.
At a glance: Two models for delegated token access
This table outlines the key differences between the two approaches.
| Feature | Auth0 Token Vault | Lower-level API model |
|---|---|---|
| Access method | Uses an existing credential that can be verified (Refresh Token, Access Token) from the user’s session, and verifies the identity of the agent | Requires an explicit user identifier to be passed by the developer. Relies only on the identity of the agent. |
| Security responsibility | The Auth0 platform is responsible for verifying user ownership via cryptographic proof. | The developer/application is responsible for ensuring the agent requests the correct userId. |
| Key risk | Unauthorized access is proactively blocked at the platform (Auth0) level. | Confused deputy attacks, credential leaks, and broken access control if the userId is wrong. |
| Design principle | It provides a secure-by-default integrated suite in which the platform handles security. | Offers flexible, low-level building blocks that must be secured correctly by the developer. |
Built for the real-world agent
The AI agent stack is still maturing. Your architecture may involve a mix of technologies:
- An agent built as a SPA or Native App
- An agent built with a web app framework like Next.js
- An agent that calls an MCP Server
- An agent that calls another agent
Token Vault is purpose-built to handle all these scenarios securely from day one. Whether you’re using Token Exchange from a Next.js backend or Access Token Exchange from an API, we make sure a user is always involved.
We designed Token Vault from the outset to support powerful, future-facing features, such as Cross-App Access. Cross-App Access allows enterprises to grant agents access to services on behalf of their employees without requiring manual consent and a connection flow. Because Auth0 owns the user’s identity end-to-end, you can automatically leverage it with no code changes required.
Build secure agents from day one
Agents present a powerful new way to interact with software, often performing a great deal of tasks on behalf of a user. The weakest link in the chain is no longer the user; it’s the agent with access to the user’s data. As an industry, we have a responsibility to deliver solutions that protect our customers from this new attack vector.
“The weakest link in the chain is no longer the user; it’s the agent with access to the user’s data.”
When evaluating a solution for your AI agents, don’t just look at the “happy path” code sample. Ask what secure-by-default and secure-by-design practices are in place.
When dealing with identity and security, it always pays to remove the burden from the developer and the application and handle this on the platform layer. This eliminates the chances of a seemingly small mistake having a major impact when something goes wrong.
With Auth0’s Token Vault, you get a solution built on a deep understanding of identity, designed to protect you and your users from the ground up.
Try Auth0 for AI Agents yourself, by creating a free account on auth0.com/ai.