Token Vault
Getting Started

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 .env files, 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

Loading diagram...

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:

Loading diagram...

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.

On this page