The Token Vault: Secure OAuth Delegation and Identity for AI Agents
Why AI agents need their own first-class cryptographic identity alongside user delegation, and how a Token Vault enables secure tool execution.
When building an enterprise AI agent, you will quickly hit a critical security dilemma:
A user asks an agent to inspect a document in their cloud storage drive and update an issue in their project management tracker. To perform these tasks, the agent must call external APIs on behalf of that specific user.
How do you give the agent the necessary authorization tokens to execute these actions?
In early prototypes, developers often inject the user’s raw Bearer token directly into the LLM system prompt or into tool arguments.
Putting raw credentials into an LLM prompt or tool argument is an unacceptable security hazard.
If an attacker executes a prompt injection attack (such as hiding instructions inside a shared document that direct the model to output its system prompt), the model can leak the user’s secret keys into the chat window. Furthermore, prompts and completions are logged across monitoring tools and vector caches, exposing sensitive credentials in plain text.
To solve this, we architected the Token Vault. But along the way, we learned a deeper architectural lesson: user delegation alone is not enough—AI agents need their own first-class identity.
Why Pure Impersonation is an Anti-Pattern: The Case for Agent Identity
Most early agent architectures treat the agent as a pure impersonator. The agent borrows the user’s OAuth token and calls downstream APIs disguised as the user.
In an enterprise, pure impersonation creates severe operational and compliance problems:
1. Loss of Auditability and Non-Repudiation
If an agent uses Alice’s raw token to delete a cloud resource or update a customer record, the downstream audit log records: “Alice deleted the resource.”
Alice did not delete the resource. Her autonomous agent chose that action as part of an automated reasoning chain. If an incident or data corruption occurs, security teams cannot distinguish between actions Alice took deliberately in a UI and actions an autonomous model decided to take on her behalf.
2. Dual-Identity: Acting “On-Behalf-Of”
True enterprise security requires dual identity:
- The Principal (The User): Who authorized the intent? (Alice)
- The Actor (The Agent): Which autonomous system executed the action? (Agent ID
financial-analyst-v2)
Downstream APIs need to know both. When an action occurs, the audit log should state: “Agent financial-analyst-v2 modified record 123 on behalf of Alice.” This enables security teams to trace autonomous behavior, audit model decisions, and revoke agent permissions without locking out the human user.
3. Asynchronous Autonomy Beyond Browser Sessions
User OAuth tokens are tied to human sessions. But real enterprise agents do not just sit inside interactive chat windows. They run asynchronous background workflows, nightly data consolidations, and multi-agent handoffs. An agent must have its own persistent, verifiable identity—a workload identity or service principal—with its own baseline permissions and lifecycle controls.
4. Agent-to-Agent (A2A) Trust
In complex systems, a supervisor agent coordinates with specialized subagents (a research agent, a code review agent, a billing agent). Passing a human user’s session token across multi-agent hops violates least-privilege security. With first-class agent identities, subagents authenticate to each other using signed, short-lived machine tokens with narrowly scoped authority.
The Idea: The Token Vault with Dual Identity
The Token Vault decouples the agent’s reasoning engine from the credential layer while binding the user’s authorization to the agent’s identity:
+-------------------------------------------------------------------------------+
| Enterprise AI Platform |
| |
| 1. User Consent & Delegation |
| [ User: Alice ] ──────▶ [ Token Vault ] ──────▶ [ External Identity / SaaS ] |
| | (Google / GitHub / CRM) |
| | Stores encrypted |
| | access & refresh tokens |
| v |
| Issues Opaque Reference: |
| "auth_ref: vt_98a72b" |
| (Bound to Alice + Agent: `doc-assistant`) |
| |
| 2. Agent Execution with Agent Identity |
| [ Agent Runtime ] |
| Identity: `doc-assistant` (Signed Workload Token) |
| Calls tool with: |
| - document_id: "doc_123" |
| - auth_ref: "vt_98a72b" |
| | |
| v |
| [ Tool Broker ] ────▶ Resolves `vt_98a72b` with Token Vault |
| | Verifies: Does Agent `doc-assistant` have |
| | delegated authority from Alice? |
| v |
| [ Backend API Call ] |
| Headers: |
| - Authorization: Bearer <real_user_token> |
| - X-Actor-Agent-ID: doc-assistant-v2 |
+-------------------------------------------------------------------------------+
The language model works strictly with opaque reference handles. It never sees an OAuth access token, a client secret, or a refresh token.
How It Worked in Production
- Zero Credential Leakage via Prompt Injections: Even if an attacker compromises an agent’s reasoning chain through indirect prompt injection, the model cannot leak secrets because it does not possess them. The model only knows an opaque reference handle that is useless outside of the authenticated broker session.
- Crystal-Clear Incident Forensics: By attaching the agent’s unique workload identity alongside the user’s delegated identity, operations teams could immediately filter logs to see which actions were human-initiated versus agent-initiated.
- Automated Token Lifecycle: Third-party access tokens typically expire in an hour. The Token Vault manages refresh token rotations in the background, allowing long-running agent workflows to proceed without interrupting users with repeated login prompts.
- Independent Agent Revocation: If a specific agent version exhibits buggy behavior or behavioral drift, security teams can revoke that agent’s workload identity instantly. The human users remain unaffected, and other verified agents continue operating normally.
What to Watch Out For
- Granular Scope Containment: When users connect external accounts, request the minimum necessary OAuth scopes. If an agent only needs to read documents, never request write permissions. If an agent needs write access, implement step-up confirmation so users explicitly approve the elevated capability.
- Confused Deputy Attacks: An agent must not be tricked into using Alice’s delegated token to access records on behalf of Bob. The Token Vault must verify that the session identity, the agent identity, and the delegated connection reference all cryptographically match before issuing or using a token.
- Rate Limits on Refresh Flows: Third-party identity providers place rate limits on token refresh endpoints. If dozens of concurrent agent workflows attempt to refresh tokens simultaneously for the same user, you can trigger provider throttling. Implement distributed caching and locking around refresh token exchanges.
- Graceful Disconnected States: When an upstream token expires and cannot be refreshed (such as when a user changes their enterprise password), the tool broker must return a clean, structured re-authentication prompt to the conversational interface rather than crashing the agent with an unhandled exception.