Skip to content

CONCEPT Cited by 5 sources

Token vault

Definition

A token vault is an out-of-band credential-management component that holds long-lived provider credentials for the enterprise and mints short-lived, scoped tokens on demand for specific tool invocations. Agents never possess the long-lived credentials directly — they make a tool call through a gateway, the gateway requests a narrowly-scoped token from the vault for that exact operation, and the token dies shortly after use.

The token vault is one of the four load-bearing components of the four- component agent production stack (Gateway + Audit log + Token vault + Sandboxed compute). It is the substrate under AAC's "no long-lived credentials" property and the enabling infrastructure for On-Behalf-Of (OBO) authorization flows.

Canonical statement

From the 2026-04-14 Redpanda Openclaw is not for enterprise scale post (Source: sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale):

"A token vault handles credentials out-of-band. The agent never holds your Salesforce token directly. When it needs to take an action, the gateway requests a short-lived, scoped token from the vault for exactly that operation."

The essay's framing: "Don't give the dog your keys." The token vault is the architectural answer to the dog-and-documents problem — the agent (the dog) never holds the credentials (the keys) because they live in a separate service (the vault) that only responds to the gateway.

Why out-of-band

"When Openclaw connects to your calendar or Salesforce, it holds credentials. Probably in a config file. Probably with more permissions than it actually needs. That's the dog with your documents. The sandbox doesn't help because the credentials are already inside it." (Source: sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale)

The threat model: if credentials are inside the agent's execution environment — config file, env var, Keychain, disk — any compromise of the agent (prompt injection, sandbox escape, malicious tool output parsed unsafely, SOUL.md edit) exposes them. Moving credentials to an out-of-band vault means the sandbox-level compromise surface no longer includes the credentials at all.

The four properties of a token vault

  1. Long-lived credentials live in the vault, not the agent. The enterprise's Salesforce service-account password, GitHub PAT, Snowflake key, etc. are stored in the vault with strong access control — usually an HSM-backed secret store.
  2. Tokens are minted per invocation. On each tool call, the gateway asks the vault: "mint me a token scoped to , , , , for the next N seconds."
  3. Tokens are scoped to the minimum privilege for that operation. Not "can do anything on Salesforce" but "can read Account record 0015Xx00002YyZz for the next 30 seconds."
  4. Tokens self-expire. Minutes-scale lifetime or shorter (see concepts/short-lived-credential-auth). Compromise of a token yields a time-bounded window.

OBO via token vault

The token vault is the critical enabler for On-Behalf-Of flows against systems that don't support service accounts. Verbatim:

"Many enterprise systems — Salesforce, ServiceNow — don't support service accounts at all. They only support user-based auth. On-Behalf-Of (OBO) flows through a token vault, allowing an agent to act in the context of a real user, with that user's actual permissions, without ever directly holding their credentials. You can't build a real multi-tenant agent without this." (Source: sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale)

The flow:

  Human user
  (authenticated via corp IdP)
    |
    v
  [ Agent session ]
    |
    | tool call: "update this Salesforce opportunity"
    v
  [ Gateway ]
    | 1. Agent session attests user identity
    | 2. Gateway requests user-scoped Salesforce token
    v
  [ Token vault ]
    | 3. Vault holds the enterprise's Salesforce OBO
    |    trust relationship; mints a short-lived token
    |    bound to this user + this operation
    v
  [ Salesforce ]
    (sees the request as the real user,
     enforces that user's per-record entitlements)

The vault is the only entity that can produce user-scoped Salesforce tokens on demand; it does so because the enterprise's Salesforce OBO trust relationship is configured at the vault. The agent never sees the user's Salesforce credentials, never sees a service-account token, never sees a long-lived token.

What stays long-lived

The trust relationship between the vault and each downstream system is long-lived — Salesforce Connected App credentials, GitHub App installation ID, Snowflake OAuth client credentials, etc. These are rotated by security operators out-of-band, not by the vault's consumers.

The vault's own authentication to downstream systems is long-lived (its own service credential / client certificate / workload identity). What's short-lived are the tokens it mints from its trust relationship to downstream systems.

Mechanism gap

The 2026-04-14 source names the component without naming a protocol. Not disclosed:

  • Token-exchange protocol. OAuth2 Token Exchange (RFC 8693)? OIDC? SAML Assertion? Custom?
  • Credential-store substrate. HashiCorp Vault? AWS Secrets Manager? GCP Secret Manager? Proprietary?
  • Binding to the gateway. Sidecar? In-process library? Separate service?
  • Vault→downstream protocol. How does the vault authenticate to Salesforce to mint a user-scoped token on demand?
  • Caching / pre-fetch. Does every tool call round-trip to the vault, or are session-scoped tokens cached with invalidation?
  • Audit of the vault itself. Who can access the vault's long-lived credentials? How is the vault's own operator access audited?

All deferred to future Redpanda disclosure.

Relationship to adjacent wiki concepts

  • concepts/short-lived-credential-auth — the token vault's output is short-lived credentials. The vault is the credential-minting substrate; short-lived-credential-auth is the property the vault delivers.
  • concepts/ephemeral-credentials — broader category (covers SSH keys via OPKSSH, per-boot VM keys, etc.). Token vault is the agent-specific substrate at the tool-invocation altitude.
  • AAC — the token vault is the concrete implementation substrate under AAC's "no long-lived credentials" property.
  • OBO — the token vault is the concrete mechanism that makes OBO flows work for user-auth-only systems.
  • four-component-agent-production-stack — the token vault is component #3 of the four.
  • patterns/agent-sandbox-with-gateway-only-egress — Fly.io's sibling pattern: proxy holds credentials, client doesn't. Token vault is the agent-specific generalisation with per-call scoped-token minting (vs proxy-holds-all-creds).

Seen in

  • sources/2026-08-31-redpanda-corebreak-proves-agent-guardrails-need-to-live-outside-the-a-6ef5e77e — the CoreBreak credential-theft path is the token vault's threat model made concrete: injected instructions steered managed browser + code-interpreter tools into "reading the execution role's cloud credentials and exfiltrating them." Redpanda's lesson — "a typed, mediated tool grant keeps the credential behind the boundary. A general compute environment with ambient cloud credentials puts it one HTTP request away from any injected instruction" — is exactly the vault-vs-ambient-credential distinction.
  • sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale — canonical wiki introduction as component #3 of the four-component agent production stack. The post's "Don't give the dog your keys" framing canonicalises the out-of-band credential-holding axis. Mechanism not disclosed; the component is named and its architectural role is canonicalised, but no protocol / software / vendor is bound.
  • sources/2026-03-12-stripe-10-things-we-learned-building-for-the-first-generation-of-agentic-commerce — commerce-layer instance of the token-vault pattern via Shared Payment Tokens (SPTs). Stripe's framing: "secure, scoped tokens that let agents transact on behalf of buyers" without "exposing credentials." Three-role separation (buyer / agent / seller) where credentials stay vaulted at Stripe and the agent holds only a scoped reference is the canonical commerce-domain realisation of this concept.
  • sources/2026-08-13-zalando-agentic-engineering-at-zalando-a-snapshot — Zalando is building a token vault into its forthcoming Identity Broker, which captures delegation chains for on-behalf-of flows, brokers between different OAuth2 infrastructures, and sits (via an infra gateway) in the call path between agent↔MCP-server and agent↔agent (patterns/on-behalf-of-agent-authorization). Distinguishing angle vs the Redpanda/Stripe instances: the vault is bundled with a multi-OAuth2-infrastructure broker for a large internal engineering org, not a single-provider commerce/SaaS vault.
  • sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker — the vault made concrete + open-sourced. The follow-up open-sourcing post names the vault's data model: user sessions hold the encrypted provider tokens for one user + one third-party service and are shared by all agents the user has delegated to; grants (revocable, optionally time-limited user→agent delegations) and permission sets (named scope groups) gate what can be minted. The mechanism gap this page flagged is partly closed: the token-exchange protocol is RFC 8693, and the runtime confirms the gateway-holds-the-token property — the exchanged provider token "returns only to the gateway," never to the agent. A named limitation sharpens the model: a revoked grant cannot claw back an already-issued provider token (short lifetimes are the only mitigation).

Merged aliases

  • tokenized-secret
Last updated · 766 distilled / 2,225 read