CONCEPT Cited by 1 source

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¶

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.
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."
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."
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.
patterns/four-component-agent-production-stack — the token vault is component #3 of the four.
patterns/credentialed-proxy-sandbox — 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-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.