Secrets
A secret is a named bundle of key/value entries — the same shape HashiCorp Vault's KV engine uses, where one path holds a map of keys to values. Credentials that belong together, such as an AWS access key id and its secret access key, live in one secret as two entries rather than in two separate secrets.
Open Secrets in the admin sidebar to manage them. Each record has a Name, an optional Description, its tags, and a type.
Where a secret is used
- MCP servers — any header value or environment variable value may embed
${secret:name/key}, expanded when connecting. - Agent Skills — a skill's Auth Password is a reference to one entry, chosen from dropdowns rather than typed.
A single entry is always addressed as name/key. The key is required even when the secret holds only one entry — a bare name identifies a map, not a value — so a key-less ${secret:name} fails to resolve rather than being passed through as a literal string.
The two types
| Local (encrypted) | HashiCorp Vault | |
|---|---|---|
| What is stored | The entries themselves, each value encrypted | Only a KV v2 reference — Vault Mount and Vault Path |
| Where values come from | The encrypted store | Read live from Vault each time they are resolved |
| What the detail page shows | Every stored key, with a blank value | The mount and path |
| Editing an entry | Leave the value blank to keep it, retype it to replace it, remove the row to delete the entry | In Vault |
Values are never returned for either type — not in plaintext, not as ciphertext — which is why the local type's detail page shows keys with blank values. Keys alone are readable, so a picker can list them: for a local secret they come from the stored map, and for a Vault secret they are read from Vault at that moment.
A Vault secret is read from its own tenant's Vault, which the tenant's admin connects under Tenant Settings. A tenant without one reads from the global Vault with a credential of its own, whose Vault policies decide what it may read. With neither, vault-type secrets cannot be resolved. The key local secrets are encrypted with is set up once in the configuration reference.
Renaming and deleting
Secrets are referenced by name and resolved lazily. Renaming or deleting one that something still references does not fail at edit time — the next use fails instead, naming the secret it could not find. An agent skill whose reference has gone stale records the reason on its own record the next time it is pulled.
Saving a reference is checked, though. When you save an MCP server whose headers or environment name a secret, run Test Run on a script, or save a skill's Auth Password, the secret must exist and must be one you can open. A secret hidden from you by an access-control tag is rejected exactly like a missing one. The same applies when you edit a record that already references such a secret, even if you change only another field.