Contents
Developers
Managing secrets
Agents often need passwords, API keys, and tokens to do their work. Secrets hold these values so they reach the agent that needs them — and nothing else: never the chat history, never the logs, never another person.
Three kinds
| Local: workflow | Local: yours | Global | |
|---|---|---|---|
| Added by | You, on one workflow | You, for yourself | An admin, for everyone |
| Lives | Sealed in that workflow's store | Sealed in your store (+ your browser) | Server memory, from its environment |
| Used by | That workflow, when you select it | Runs where you select it | Every run, automatically |
| Good for | A database password one flow needs | Your personal API keys | Company-wide keys and configs |
"Local" means yours: sealed with your identity, so nobody else's run can open them. "Global" means the deployment's: set by an admin, available platform-wide.
How a secret travels
The server reads the deployment's master secret once at startup, then drops it from its own environment — so even a process listing the server's environment won't find it. Names travel freely (you pick "DB_PASSWORD" from a list); values only ever move sealed or straight into the run that needs them.
What each person sees
Server
Seals and opens secrets.Knows every name, guards every value.
Global values live in its memory only.
Alice
✓ Her secrets' names and values✓ Her workflows' secrets
✓ Global names (values masked)
✗ Bob's secrets entirely
Bob
✓ His secrets' names and values✓ His workflows' secrets
✓ Global names (values masked)
✗ Alice's secrets entirely
Alice and Bob both see the name DB_PASSWORD if it's global — but only
the runs it is injected into ever hold the value, and nobody's screen or log
file shows it.
Rotation
Change the value where it lives — edit your secret, or ask an admin to update a global one — and new runs pick it up. Runs already in flight keep only the old value until they end.
Related: Secrets (technical reference), Provider credentials, Security overview.