What is Token Vault? Architecture & Core Concepts
Broker scoped, policy-gated access to API keys and OAuth tokens that live on your own webhook — Token Vault routes and audits access but never stores or sees a credential.
Token Vault is a webhook-sovereign credential broker for AI agents: your API keys and OAuth tokens live on a webhook server you deploy and control, and Token Vault brokers scoped, policy-gated, audited access to them — without ever holding, seeing, or being able to decrypt a credential. It enforces identity, grants, and ABAC policies, then routes agents and proxies to your webhook via signed tickets.
What Token Vault is not
- Not a credential store. There is no server-side storage of your secrets and no "platform-managed" mode — an earlier hosted-storage mode was removed entirely in mid-2026. The only architecture is webhook-sovereign.
- Not an encryption service. Token Vault has no encryption key for your credentials. Whether and how credentials are encrypted at rest is your webhook's choice (the reference webhook implementations use AES-256-GCM with a key that never leaves your infrastructure).
- Not in the credential path. Agents receive credentials directly from your webhook via a signed 307 redirect; Token Vault's transcript ends before any credential bytes flow.
- Not affiliated with "TokenVault"/"Token Vault Ltd" at tokenvault.online, an FCA-flagged financial services entity.
The Problem
AI agents need credentials to call external APIs on your behalf. Today, that typically means:
- Plaintext config files - API keys stored in
.envfiles, Claude config JSON, or shell history - No revocation - once a credential leaks, you have to rotate it at the provider and update every agent
- No audit trail - you have no visibility into which agent used which credential and when
- No scoping - agents get full access to whatever the credential allows, with no time limits or restrictions
System Architecture
How Token Vault Solves It
Token Vault sits between your AI agents and the APIs they need to access — as a policy and routing layer, never as a credential store:
Four capabilities make this work:
- No credential custody - credentials never touch Token Vault. They live on your own webhook, on your infrastructure, stored however you choose (the reference webhooks encrypt at rest with AES-256-GCM using a key only they hold). Token Vault holds identities, grants, policies, and audit metadata - there is no credential in it to steal.
- MCP proxy - agents connect to Token Vault's MCP proxy endpoint instead of directly to APIs. Token Vault forwards to your webhook, which injects real credentials into upstream requests. Agents never see the actual keys.
- Supports any upstream MCP server (GitHub, Slack, Google, custom)
- Proxy keys are random strings, so no credential material appears in agent configs
- Agent grants - each agent gets scoped, time-limited access to specific credentials. A grant expires automatically, and you can revoke it at any time.
- REST and MCP interfaces for credential retrieval
- Per-credential expiry from 1 hour to 30 days, or "until revoked"
- ABAC policies - attach attribute-based access control rules to any agent, proxy, or token. Restrict by time window, IP allowlist, rate limit, usage cap, or geo-location.
- Policies are reusable: attach one policy to many entities
- All rules within a policy are AND'd together
Next Step
Do the Quickstart → — deploy the reference webhook to Cloudflare Workers, bind it, and have an agent fetch its first credential in about ten minutes.
Quickstart: First Credential in ~10 Minutes
Deploy the reference webhook to Cloudflare Workers, bind it to Token Vault, and have an AI agent fetch its first credential — copy-paste steps, honest prerequisites.
Initial Setup
Sign in to Token Vault, deploy and bind your webhook vault, and add your first credential — with no credential ever stored on Token Vault.