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
1
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).2
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.3
The sandbox makes a request
The code calls, say,
api.anthropic.com with that token, exactly as it would with a real key.4
Superserve attaches the real key
On the way out, Superserve recognizes the token, swaps in your real credential for that host, and forwards the request. The service sees your real key; the sandbox never did.
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.