Integrate & ship

Secrets

A vault for the credentials the platform uses on your behalf. Store once, reference by name, rotate in one place.

Open Configure → Secrets. Anywhere a credential is needed — a warehouse connection, a provider key, an MCP token — you can reference a secret instead of typing the value in.

Why it works this way

The problem isn't storing a key; it's the copies. Paste a warehouse password into four connectors and rotation means finding all four, one of which someone set up last year and forgot. A reference means the value exists once and every consumer follows it.

Creating and referencing

1
Create the secret
Give it a clear name — snowflake_analytics_ro beats key2. Values are encrypted at rest with authenticated encryption and are never returned to the browser after saving.
2
Reference it
In a connector or provider form, choose the secret instead of pasting a value. The reference is stored, not the credential.
3
Rotate in place
Update the value here and every consumer picks it up on its next call. No redeploy, no hunting.

Name rules

Names are validated by the database, so an invalid one fails at save rather than silently never matching:

Rule	Detail
Pattern	`^[A-Za-z][A-Za-z0-9_]*$`
Must start with	A letter
May contain	Letters, digits and underscores — no hyphens, spaces or dots
Max length	64 characters

Valid	Invalid	Why
`SNOWFLAKE_ANALYTICS_RO`	`snowflake-analytics-ro`	Hyphens are not allowed
`stripe_live_key`	`2captcha_key`	Cannot start with a digit
`jiraToken`	`jira token`	No spaces

Referencing a secret by name

Beyond connector forms, the reference syntax works wherever the server resolves it — most visibly on a swarm HTTP node:

HTTP node header

Authorization: Bearer {{secret:SUPPORT_API_TOKEN}}

Why it works this way

{{secret:NAME}} is deliberately left unresolved by the client-side template engine and substituted on the server at call time. That is what lets a swarm authenticate to a third-party API without the credential ever being sent to the browser or visible on the canvas — so someone who can edit the graph still cannot read the value.

Exactly which fields resolve

Worth being precise about, because a reference written anywhere else is passed through as the literal text {{secret:NAME}} — which usually surfaces as an authentication failure from the far end rather than as an error here.

Surface	Fields resolved
Swarm HTTP node	The URL, every header VALUE, and the request body. Header names are not templated.
Swarm A2A remote-agent node	The auth header value. The endpoint URL is not templated.
Warehouse and database connections	Every string field of the connection config.
Integration credentials	Every string field of the integration config — search providers, object stores, automation tools.
MCP Builder environment bindings	The value side of `ENV_NAME={{secret:NAME}}`, resolved when the container starts.

Whitespace inside the braces is tolerated — {{ secret:NAME }} resolves the same way. The name inside a reference must satisfy the same pattern as a stored name, so a secret that could not be saved could not have been referenced either.

When a reference cannot be resolved

On a swarm HTTP or A2A node, a connection or an integration it fails loudly: a missing secret, or one you have not been granted, stops the call with an explicit error naming the secret. It is never quietly replaced with an empty string, which would turn a credential problem into an unauthenticated request that some APIs answer with a 200 and an empty result.

MCP environment bindings are the exception

A binding whose secret is missing or revoked is skipped rather than raised, so the container starts with that variable simply absent — and code written the idiomatic way, os.environ.get("API_TOKEN", ""), then sends an empty token. The failure surfaces as the remote API rejecting the call, one layer away from the cause. If a built server starts failing to authenticate after a rotation, check that the binding still names a secret you own or have been granted.

Your own secret wins, and two shared ones collide

Names are resolved per user, in this order: a secret you own with that name is used first; otherwise a secret shared with you. If two different shared secrets both carry the name, the call fails as ambiguous rather than picking one.

This is the practical argument for qualifying names in a shared workspace — BILLING_STRIPE_KEY and SUPPORT_STRIPE_KEY rather than two STRIPE_KEY entries in different people's vaults. It also means a colleague can override a shared secret for themselves simply by owning one of the same name, which is useful deliberately and surprising accidentally.

Worked example — rotating a warehouse password

1
Rotate at the source first
Issue the new password in Snowflake, Postgres or wherever the account lives. The vault stores what you tell it; it cannot change the credential upstream.
2
Configure → Secrets → edit the value
Same secret, new value. Do not create SNOWFLAKE_ANALYTICS_RO_V2 — the entire benefit is that consumers point at a name, and a new name means finding all of them again.
3
Nothing to redeploy
Connections and integrations resolve the reference on their next call, so the change takes effect without touching them.
4
Restart any MCP server that binds it
The one exception: environment bindings are resolved at container start, so a running server keeps the old value until it restarts or scales to zero.
5
Revoke the old credential upstream
Until you do, the rotation has added a credential rather than replaced one.

Where secrets can be used

Warehouse and database connections — passwords, service accounts, key files.
Model provider credentials — API keys, AWS/GCP/Azure credentials.
MCP server tokens.
Integration credentials — search providers, automation tools, object stores.

Access

Secrets are private to their owner. An administrator can grant a user or group access from Access control, which lets a colleague use a secret in a connector without ever seeing its value.

Note

Granting access to a secret grants the ability to use it, which is effectively access to whatever it unlocks. Grant to groups rather than individuals so leavers are handled by group membership rather than an audit of every grant.

Hygiene

Least privilege at the source: Create a read-only warehouse user for analytics rather than storing an admin credential. The vault protects the value; it can't reduce what the credential can do.
One secret per system per purpose: Separate credentials for separate uses means revoking one doesn't break the others, and the audit trail tells you which integration did what.
Rotate on a schedule and on departure: Anything a leaver could have seen should be rotated, whether or not you think they copied it.
Never put credentials in prompts: A system prompt is sent to a model provider and shown in traces. Credentials belong here, referenced by the platform, not in text the model can read back to someone.

How they're protected

Values are encrypted before storage using a workspace encryption key held in the environment, not in the database — so a database dump alone doesn't yield credentials. On a self-hosted deployment that key is PROVIDER_CREDS_SECRET; back it up somewhere you can recover it from, because losing it makes every stored secret unreadable. See Install & deploy.

PreviousAPI & webhooks Next Access control