printenv in a log can all expose a raw key. With secrets, there’s nothing in the sandbox to leak — the real credential never crosses the boundary.
How it works
Store the credential
Secret.create() encrypts the value and stores it with Superserve. You give it a name and the hosts it may authenticate (a provider shortcut sets the hosts for you).Bind it to a sandbox
On
Sandbox.create(), add it to the secrets map — { ANTHROPIC_API_KEY: "anthropic-prod" }. The sandbox gets an ANTHROPIC_API_KEY it can read like any other variable, but its value is a stand-in token, not your key.The sandbox makes a request
The code calls, say,
api.anthropic.com with that token, exactly as it would with a real key.Secrets are host-scoped. A secret for
api.anthropic.com is only ever attached to requests to that host. Sent anywhere else, the stand-in token is useless.When to use secrets
Use secrets for anything that authenticates — API keys, tokens, passwords. For non-sensitive configuration like log levels, feature flags, or public URLs, plainenvVars is simpler and works fine.
Provider shortcuts
For common services, a provider shortcut preconfigures the auth scheme and allowed hosts so you only supply a name and value:Provider.list() for the current list, or define your own auth with custom secrets.
Next steps
Create a secret
Provider shortcuts, custom auth, and rotation.
Bind to a sandbox
Attach secrets to environment variables at create time.
Audit usage
See every request made with a secret.
Network log
See everything a sandbox reached on the network.