Secrets

The Secrets section of Settings holds tokens that your tools need, each stored under a name. You write the value once, and everywhere it is needed you write the name instead.

This exists because of what the alternative looks like. An HTTP tool needs an Authorization header; an MCP server needs a GITHUB_TOKEN in its environment. Without a place to put a secret, the only way to send one was to type it into the tool’s own row — where it sits in the clear for anyone in the workspace who can open that skill.

Naming one

A secret’s name is upper case, digits and underscores, starting with a letter: STRIPE_TOKEN, GITHUB_TOKEN, INTERNAL_API_KEY. That shape is not decoration — the name is written inside a template, next to {'{{body.…}}'} and {'{{campo}}'}, and a convention you cannot confuse with a data field is what makes a header readable at a glance.

1. Open Settings and go to Secrets.

2. Give it a name, paste the value, and (optionally) a line saying what it is for. A workspace with fifteen secrets and no notes is a workspace where nobody dares delete any of them.

3. Reference it wherever it is needed, as {'{{secret.STRIPE_TOKEN}}'}.

Where a secret can be named

Place	Example
An HTTP tool’s header	Authorization: Bearer {'{{secret.STRIPE_TOKEN}}'}
An HTTP tool’s URL	https://api.example.com/v1/{'{{secret.TENANT}}'}/orders
An HTTP tool’s body template	{'{"signature": "{{secret.WEBHOOK_SIGNING_KEY}}"}'}
An MCP server’s environment	GITHUB_TOKEN = {'{{secret.GITHUB_TOKEN}}'}

Caution

A name that does not exist is an error, not a blank. A tool that names a missing secret comes back to the model as a tool error saying which one is missing; an MCP server that names one simply does not start, and says so in the log. Neither sends the literal {'{{secret.X}}'} text to a third party — that would get you a 401 you would read as “my token expired”.

What you cannot do, on purpose

Read a value back. There is no screen and no API route that returns it. What the list shows is the name and the last four characters, which is enough to tell two secrets apart and not enough to use one. If you lose a value, you replace it.

Send one somewhere of your choosing, if you are not an admin. Naming a secret is how it gets used, and what uses it is a thing you write: an HTTP tool inside a skill, or an MCP server’s environment. Whoever writes one of those picks where the value goes. So in a team workspace, writing a skill or registering an MCP server takes an admin — the same bar as writing the secret itself. Reading them does not: what is stored is the name.

Scope

Secrets follow the active workspace, and resolve exactly the way provider API keys do: a team run uses the team’s secret, falling back to the personal secret of whoever started the run. Team secrets can only be written by team admins.

Providers & API keys Model credentials, which follow the same scope rules.

Tools HTTP tools, where a secret is most often named.