AI Agents Have a Credential Problem
Here's the uncomfortable reality of agentic AI in 2026: for an AI agent to do anything genuinely useful — schedule a meeting, file a GitHub issue, send a Slack message, query a Salesforce dashboard — it needs OAuth tokens for those third-party services. And right now, most agent frameworks handle this by passing raw credentials around like candy.
The patterns we see in production are alarming. Refresh tokens stored in plaintext environment variables. API keys hardcoded into agent tool definitions. Long-lived access tokens shared across multiple agent instances with no revocation mechanism. One compromised agent and every service it touches is exposed.
This isn't a hypothetical. OWASP's Agentic AI Top 10 lists "Identity Abuse" (ASI03) and "Tool Misuse" (ASI02) as critical risks specifically because agent credential management is so immature. When an agent can autonomously access your Gmail, your Stripe dashboard, and your AWS console, the blast radius of a prompt injection goes from "leaked conversation" to "drained bank account."
How Auth0 Token Vault Actually Works
Auth0's Token Vault solves this with a clean architectural separation: the agent never touches raw third-party credentials. Instead, Auth0 acts as a secure intermediary that acquires, stores, refreshes, and exchanges tokens on behalf of users.
Connected Accounts
Users link their third-party accounts (Google, GitHub, Slack, Salesforce, etc.) through Auth0's Connected Accounts flow. The user completes a standard OAuth consent screen, and Auth0 stores the resulting access and refresh tokens in its encrypted Token Vault. The tokens are associated with the user's Auth0 profile but never exposed to the application directly.
The Connected Accounts API lives at /me/v1/connected-accounts/ — users can initiate connections, list their linked accounts, and revoke access at any time. Scopes are explicitly declared at connection time, and revoking a connection immediately invalidates all tokens for that provider.
Token Exchange (RFC 8693)
When an AI agent needs to call a third-party API on behalf of a user, it doesn't fetch the user's raw Google token. Instead, it performs a token exchange — trading an Auth0-issued credential for a short-lived, scoped external access token.
The exchange uses OAuth 2.0 Token Exchange (RFC 8693) via Auth0's /oauth/token endpoint with a custom grant type: urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token. The agent sends its Auth0 refresh token or access token as the subject, specifies the target connection (e.g., "google-oauth2"), and receives a short-lived external access token in return.
This is fundamentally different from giving the agent a raw token. The exchanged token is scoped, short-lived, and auditable. Auth0 handles refresh rotation automatically. If the user revokes their Connected Account, the next exchange attempt fails immediately.
Three Exchange Patterns
Token Vault supports three exchange patterns for different architectures:
Refresh Token Exchange — the agent holds an Auth0 refresh token and exchanges it directly. Best for server-side agents with persistent sessions.
Access Token Exchange — the agent holds an Auth0 access token (from a frontend session) and a backend Custom API Client performs the exchange. Best for SPA-plus-API architectures.
Privileged Worker Exchange — a backend service uses a signed JWT bearer token to exchange tokens without a user session. Best for machine-to-machine workflows and background agent tasks.
1-SEC + Token Vault: Defense in Depth
Token Vault handles the authorization layer — ensuring agents get properly scoped, short-lived tokens. But authorization alone doesn't answer the security questions that matter: Is the agent using those tokens appropriately? Is it accessing services it shouldn't? Is someone exploiting the agent to abuse delegated access?
That's where 1-SEC's AI Containment module comes in. Token Vault is integrated as a sub-component of AI Containment (Module 11), adding token-aware security monitoring on top of the existing agent sandboxing, tool-use monitoring, and OWASP Agentic AI Top 10 coverage.
Scope Escalation Detection
1-SEC's ExchangeTracker maintains a per-agent baseline of what OAuth scopes each agent has historically requested for each connection. When an agent suddenly requests calendar.write after only ever needing calendar.readonly, that's a scope escalation — possibly because the agent has been prompt-injected into performing actions beyond its original mandate.
The scope escalation detector fires a HIGH severity alert with the specific new scopes, the connection, and the agent ID. This pairs with Token Vault's scoped token model: even if the escalated scope is technically available on the user's Connected Account, 1-SEC flags the behavioral anomaly.
Token Exchange Rate Monitoring
A healthy agent exchanges tokens at a predictable rate. An agent under attack — or an agent being used as a token oracle — exchanges tokens rapidly. 1-SEC monitors per-agent exchange velocity with a configurable threshold (default: 20 exchanges per 5-minute window). Exceeding this triggers a HIGH alert and can invoke enforcement actions including process termination via the SOAR engine.
Unauthorized Agent Access
Token Vault Connected Accounts belong to users. Agents must be explicitly delegated access via agent_identity_delegation events. 1-SEC's ConnectedAccountTracker maintains a mapping of which agents are authorized for which user-connection pairs.
If an agent attempts to use a Connected Account token without a prior delegation from the owning user, 1-SEC fires a CRITICAL alert. This catches scenarios where a compromised agent tries to piggyback on another user's Connected Accounts, or where an agent framework bug allows cross-user token access.
OAuth Consent Phishing Detection
1-SEC monitors OAuth grant events from Auth Fortress and flags grants with unusually broad scopes (more than 10 scopes in a single grant). This detects consent phishing attacks where a malicious application requests excessive permissions under the guise of a legitimate integration.
Telemetry Contract: 6 New Event Types
To monitor Token Vault operations, 1-SEC added 6 canonical event types to the versioned telemetry contract:
token_exchange — emitted when an agent initiates a Token Vault token exchange. Captures the connection (e.g., google-oauth2), subject token type, requested scopes, and agent ID.
token_exchange_request — the raw exchange request, including grant type and subject token type for audit purposes.
token_exchange_response — the exchange result, including success/failure, error codes, granted scopes, and token expiry.
connected_account_link — emitted when a user links a new third-party account via Connected Accounts. Captures user ID, connection name, and granted scopes.
connected_account_unlink — emitted when a user revokes a Connected Account. 1-SEC automatically revokes all agent authorizations for that connection.
connected_account_usage — emitted when an agent uses a Connected Account token to call a third-party API. This is the audit trail for every delegated API call.
These events are available via the /api/v1/event-schemas endpoint and follow the same versioned contract as all other 1-SEC telemetry. Instrument your agent framework to emit these events to the NATS event bus or HTTP API, and all Token Vault monitoring activates automatically.
API Endpoints for Token Vault Operations
1-SEC exposes two Token Vault API endpoints:
GET /api/v1/token-vault/status returns the current Token Vault status including whether Auth0 credentials are configured, exchange statistics (total exchanges, success/failure counts, per-connection breakdown), connected account count, and authorized agent count. This is a read-only endpoint safe for dashboards.
POST /api/v1/token-vault/exchange performs a Token Vault token exchange via Auth0. The request body includes subject_token (the Auth0 refresh or access token), subject_token_type (RFC 8693 URN — defaults to refresh token), connection (the target provider, e.g., "google-oauth2"), and an optional login_hint. The response returns a short-lived external access token.
The exchange endpoint is a mutating operation that requires write-scope API key authentication. All exchanges are tracked by the ExchangeTracker and feed into the scope escalation and rate monitoring detectors.
Configuration: Opt-In by Design
Token Vault is opt-in, consistent with 1-SEC's zero-config philosophy. All 16 modules work independently without it. When you're ready to add secure agent delegation, the configuration is minimal:
In your 1-SEC config (configs/default.yaml), add:
token_vault: enabled: true auth0_domain: "yourapp.us.auth0.com" auth0_client_id: "your-client-id" auth0_client_secret: "your-client-secret"
Or use environment variables: AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_CLIENT_SECRET. Setting AUTH0_DOMAIN automatically enables Token Vault.
Auth0 requirements: your application must be first-party (is_first_party: true), confidential (token_endpoint_auth_method not "none"), and OIDC-conformant (oidc_conformant: true). Token Vault must be enabled on your Auth0 tenant.
Once configured, the AI Containment module initializes the Token Vault sub-component during startup and begins monitoring token exchange events. The startup log confirms activation: "AI agent containment started (OWASP Agentic AI Top 10 + agentic web access)" with token_vault: true.
Enforcement: From Detection to Response
Token Vault alerts feed directly into 1-SEC's SOAR enforcement engine. The vps-agent enforcement preset includes policies for Token Vault detections out of the box:
Excessive token exchanges (HIGH) — webhook notification to SOC, rate-limit the agent Scope escalation (HIGH) — webhook notification, log for audit review Unauthorized agent access (CRITICAL) — kill the agent process, block the source IP, webhook notification Broad OAuth consent grant (MEDIUM) — log and notify
The approval gate integrates naturally with Token Vault's human-in-the-loop model. When enforcement wants to kill an agent process, it can require human approval first — giving the SOC team visibility without adding latency to normal operations.
All enforcement actions are recorded in the responses stream with full audit trails including the triggering alert, the action taken, and the outcome. Dry-run mode lets you test Token Vault enforcement policies before going live.
Architecture: Where Token Vault Fits
The integration architecture is straightforward:
1. User authenticates via Auth0 and links third-party accounts (Google, GitHub, Slack, etc.) through Connected Accounts.
2. AI agent needs to call a third-party API. Instead of using a raw token, it makes a Token Vault exchange request — either directly to Auth0 or via 1-SEC's /api/v1/token-vault/exchange proxy.
3. 1-SEC's Token Vault sub-component monitors the exchange: validates the agent is authorized for that user-connection pair, checks for scope escalation, tracks exchange velocity.
4. If the exchange is legitimate, the agent receives a short-lived external access token and makes the API call.
5. If the exchange is anomalous — unauthorized agent, scope escalation, excessive rate — 1-SEC fires an alert that feeds into the enforcement engine.
6. The user can revoke a Connected Account at any time. 1-SEC's ConnectedAccountTracker automatically revokes all agent authorizations for that connection.
Token Vault lives inside AI Containment because it's fundamentally an agent containment concern: controlling what resources an agent can access and detecting when those access patterns deviate from authorized behavior. It's not a separate module — it's the credential layer for the agent security stack that AI Containment already provides.
Getting Started
To start using Token Vault with 1-SEC:
1. Set up an Auth0 tenant and enable Token Vault (auth0.com/docs/secure/tokens/token-vault).
2. Create a first-party, confidential, OIDC-conformant application in Auth0.
3. Configure Connected Accounts for the third-party providers your agents need.
4. Add token_vault configuration to your 1-SEC config or set AUTH0_DOMAIN, AUTH0_CLIENT_ID, and AUTH0_CLIENT_SECRET environment variables.
5. Instrument your agent framework to emit token_exchange, connected_account_link, connected_account_usage, and agent_identity_delegation events to 1-SEC's event bus or HTTP API.
6. Start in dry-run enforcement mode, review the alerts, then switch to live enforcement.
The combination gives you the best of both worlds: Auth0 handles the complex OAuth plumbing — token acquisition, storage, rotation, and exchange. 1-SEC handles the security monitoring — scope escalation, rate anomalies, unauthorized access, and enforcement.
AI agents need authorization to be useful and containment to be safe. Token Vault and AI Containment provide both.