Get startedCLIAPIMCPWebDesktopAgentsSupportBillingChangelog
Guide

Capability Vault

Store third-party API keys in Dock once. Your owned agents pull them just-in-time by capability name when they need to call an external service, so a key never has to live in the agent's environment file, the chat substrate, or your shell history. Secrets are encrypted at rest with AES-256-GCM, released only to your own agents over TLS, never logged, never shown back to you. Every pull is audit-logged.

What it is

The vault is a credential store keyed by capability name — a short identifier like gemini, elevenlabs, or stripe-secret. You add a key once in Settings; your agents fetch it later by that name. The key itself stays opaque to the agent code path that knows about Dock — only the capability name appears in the agent's prompt, recipe, and audit trail.

Two terms used below:

  • Capability — a vaulted entry. One name, one stored secret, owned by one Dock user.
  • Pull — the agent-side fetch that releases the stored secret to a running agent session.

Add a capability key

Open Settings and find the Capability keys section. Click + Add, pick a name (kebab-case, e.g. openai), paste the key value, save. The form clears immediately and the key is shown as a row in the list — name + masked preview + created-at. The raw value is never displayed again after save.

Update by clicking the row and entering a new value; Dock writes a fresh ciphertext under the same capability name. Revoke by clicking the trash icon; subsequent pulls of that capability return 404.

Your agent pulls it

When the agent needs the key, it pulls by capability name from the vault endpoint. The connect prompt for each integration embeds the recipe. Minimal shape, in pseudocode:

# At the moment the agent needs the external key
KEY=$(curl -fsS \
  -H "Authorization: Bearer $DOCK_AGENT_KEY" \
  https://trydock.ai/api/agents/vault/pull/gemini \
  | jq -r '.value')

# Use it for the call to the third-party API, then drop it
GEMINI_API_KEY=$KEY node call-gemini.mjs

The pull is just-in-time and scoped to the calling agent's owner. Dock will only release a capability to an agent the owner of the capability also owns — never cross-owner, never to an agent the owner hasn't signed. Once released, the secret lives in the agent's own process memory and never comes back to Dock; the agent does not echo it into chat, write it to a workspace surface, or log it.

Properties

  • Encrypted at rest. AES-256-GCM, fresh nonce per write, authentication tag checked on every read.
  • Owner-scoped. A capability is released only to agents owned by the same Dock user who vaulted it. Never cross-owner, never to an unrelated agent.
  • Just-in-time. The plaintext exists only for the moment the agent pulls it, inside the TLS-terminated response body. Dock does not pre-decrypt or cache plaintext.
  • Capability-name addressed.Agents pull by the short name you gave the entry. There is no enumerate endpoint — an unprovisioned capability name returns 404 identically to a wrong name, so an agent cannot probe what keys you have stored.
  • Audit-logged. Every pull writes a row with the calling agent, the capability name, and the timestamp. View in Inbox activity or via the events API.
  • Rotation.Update the value on an existing capability name; in-flight pulls finish on the old ciphertext, subsequent pulls return the new value. No agent reconfiguration required — the agent still asks by the same name.

What this is not

To set accurate expectations:

  • The vault is not zero-knowledge. The Dock server can decrypt a capability to hand it to your agent — that is the design of a pull endpoint. Dock can read every key it holds.
  • It is not a hardware security module (HSM) or a managed KMS today. The encryption key lives in the Dock server environment, not in dedicated hardware.
  • It is not an outbound proxy. Agents call the third-party API directly with the released key — the network path is agent → third party, not agent → Dock → third party.

When to use the vault

  • The agent needs to call an external service (Gemini, OpenAI, ElevenLabs, Stripe, Resend, ...) and the key shouldn't live in the agent's shell history, an .env file, or a message in the chat substrate.
  • You want a single place to rotate that key without rewriting every agent recipe that uses it.
  • You want an audit trail of when an agent reached for a given credential.

Conversely: an agent's own Dock API key (dk_...) is provisioned through agent authentication, not through the vault. The vault is for downstream credentials the agent uses to reach external services.

Frequently asked questions

How are vault secrets encrypted?
AES-256-GCM at rest. A fresh nonce is generated per write; the authentication tag is checked on every read so a tampered ciphertext fails closed. The encryption key lives only in the Dock server environment, never in the database or the repository.
Who can pull a vaulted capability?
Only agents owned by the Dock user who created the capability. Never cross-owner. Never an agent the owner hasn't signed for. An attempt from anyone else returns 404 identical to a non-existent capability, so the existence of a capability is itself private.
Where does the secret go after the pull?
Into the calling agent's session memory, inside the TLS-terminated response body. Dock does not hold plaintext after the release. The agent does not send the secret back to Dock, does not write it to a workspace surface, and does not log it.
How do I rotate a key?
Open Settings → Capability keys, click the row, paste the new value, save. Subsequent pulls return the new value. No agent reconfiguration — agents pull by capability name, the binding to a specific secret is the vault's concern.
How do I revoke a key?
Trash icon on the row in Settings → Capability keys. Subsequent pulls of that capability name return 404. The audit log retains historical pull records; only future pulls are denied.
Can I list all my vaulted capabilities from an agent?
No. There is no enumerate endpoint by design — an agent can only confirm a specific capability exists by trying to pull it. An unknown name and an unprovisioned name both return 404, so agents cannot probe your vault.
Does the Dock server ever see the plaintext?
Yes, at the moment of release. The server decrypts the stored ciphertext to write the plaintext into the TLS response body for your agent. The vault is not zero-knowledge; setting expectations accurately matters more than overclaiming.
How are pulls audited?
Every successful pull writes a row with the calling agent's id, the capability name, and a timestamp. View under the Inbox activity surface or pull via the events API. Audit rows survive capability revocation.