Credentials & secrets
A runbook run needs credentials: one for the model provider, and often a few for the tools the agent calls. Jetty keeps these in two distinct layers, and which layer a secret belongs in determines how it is scoped and when it is read.
1. AI provider keys
Settings → AI providers (/settings/ai-providers). These are the keys that let a run talk to a model provider. Jetty supports per-provider keys for:
- Anthropic
- OpenAI
- AWS Bedrock
- OpenRouter
- Google Gemini
- vLLM
The runtime needs a key for whichever provider it's configured to use. If the runtime is pointed at OpenRouter, it needs the OpenRouter key; if it's on Anthropic direct, it needs the Anthropic one. Provider keys are scoped to the collection, and runtimes read them at run time, so you set the key once and every run in the collection picks it up.
2. Environment variables
Settings → environment variables (/settings/environment-variables). Org-wide key/value secrets and config, injected into every run in the collection. This is where everything that isn't a model-provider key lives: API tokens for the tools your agent calls, service URLs, feature flags, default config.
If your runbook scrapes with a third-party service, queries a database, or posts to Slack, the credential for that goes here. It lands in the sandbox environment the same way a local .env would, so the agent reads it however that tool expects.
Across both layers, secrets are never written to logs. Provider keys and injected variables are available to the run but kept out of trajectory output and run logs.
Which layer do I use?
- Talking to a model? AI provider keys.
- Talking to any other service (DB, scraper, Slack, your own API)? Environment variables.
New here? Start with the quickstart. To see how a runtime picks up the provider key at run time, see runbook runtimes →