Secrets

OPENROUTER_API_KEY is more than a label. When you select that secret for a remote run, Dreadnode creates an environment variable named OPENROUTER_API_KEY inside the sandbox. The software running there uses that exact name to find the credential.

Secrets are encrypted, user-owned credentials. Dreadnode stores the value without returning it in normal API reads, then injects it only into the remote runtimes and evaluations you select.

What secrets are

• Private to you: secrets are owned by your user and never shared by default.
• Encrypted at rest: plaintext values are never returned by read APIs.
• Injected at runtime: selected values are decrypted and injected when a sandbox is provisioned.

The key idea is that “stored” and “in use” are different states. Saving a secret makes it available for later selection. It does not automatically push that value into every runtime you launch.

One common misread: saving a provider key here does not power your BYOK chat models. Local TUI chat reads provider keys from your shell environment — secrets only reach the remote agent runs you select them for. See Chat models.

Name secrets for the software that reads them

A custom secret name must match the environment variable expected by your model provider, tool, or application. Dreadnode does not translate a custom name such as MY_OPENROUTER_KEY into OPENROUTER_API_KEY.

Secret names:

• may contain letters, numbers, and underscores
• must start with a letter or underscore
• are normalized to uppercase when saved

LiteLLM provider keys

LiteLLM resolves the provider from the model ID prefix, then looks for that provider’s environment variable. These common model prefixes use the following names:

Model prefix	Secret name
openai/	OPENAI_API_KEY
anthropic/	ANTHROPIC_API_KEY
openrouter/	OPENROUTER_API_KEY
gemini/, google/	GEMINI_API_KEY or GOOGLE_API_KEY
mistral/	MISTRAL_API_KEY
groq/	GROQ_API_KEY
together_ai/	TOGETHERAI_API_KEY

For example, an openrouter/anthropic/claude-sonnet-4 model still needs OPENROUTER_API_KEY, not ANTHROPIC_API_KEY, because LiteLLM sends the request through OpenRouter. Choose Custom when the provider is not available as a preset, enter the expected name, and paste the provider key as the value. The Chat models screen also shows which key each BYOK model expects.

Create and select a secret

The normal secret workflow looks like this:

1. Open Account Settings in the App, then select Secrets.
2. Choose a provider preset or Custom, enter the expected environment variable name, and save the credential.
3. Verify the configured state in the App or with /secrets in the TUI.
4. Select the specific secrets you want when you create a runtime or evaluation.
5. Reprovision or rerun when a rotated value needs to take effect.

Saving a secret makes it available for selection. It does not inject the value into every remote run.

Provider presets

Provider presets fill in the canonical environment variable name for you:

Provider	Secret name
OpenAI	OPENAI_API_KEY
Anthropic	ANTHROPIC_API_KEY
GitHub	GITHUB_TOKEN
Tinker	TINKER_API_KEY

A preset changes only how you create the secret. You still select its ID when you provision a runtime or create an evaluation. For providers without a preset, choose Custom and use the name the provider’s client expects.

Scoping and injection

Secrets are user-owned. You maintain a personal library of secrets and choose which ones to inject when you provision a sandbox for a project.

When you provision an interactive runtime, pass the secret IDs in secret_ids. That selection applies to that runtime request; the project only groups the resulting resource.

When you create an evaluation, you can also pass secret_ids. The platform injects those secrets into both compute units created for each evaluation sample:

• the runtime sandbox that hosts the agent loop
• the task environment sandbox derived from the task build

From the CLI, dn evaluation create lets you choose secrets by environment variable name with repeatable --secret flags. Exact names such as OPENROUTER_API_KEY are strict. Glob selectors such as OPENROUTER_* are best-effort. The CLI resolves those selectors to concrete secret_ids before submitting the request. See Running evaluations for examples.

Secrets are injected when the sandbox is created. To change the selection or apply a rotated value, restart or reprovision the runtime. For an evaluation, create a new run with the updated selection.

There is not currently a standalone CLI secret CRUD command group. Manage secret values in the App or through the API and SDK; use the TUI to inspect configured secrets.

Lifecycle and management

Surface	Best use
App	create, rotate, and delete saved secrets
TUI	inspect configured secrets and provider presets with /secrets
CLI	pass evaluation --secret selectors that resolve to secret_ids
API / SDK	full secret CRUD and preset discovery

Step	What happens
Create	The value is encrypted and shown with a masked preview
Select	You choose which secrets to inject for a runtime request
Provision	Dreadnode decrypts the selected values and injects them
Rotate	You update the value and reprovision or restart to apply it

Common pitfalls

• A correctly stored key with the wrong name is still the wrong environment variable. Use the name required by the software that reads it.
• Provider presets report whether the canonical secret exists, not whether a running sandbox uses it.
• Secret values are never returned by normal read APIs. You see metadata and a masked preview.
• Evaluations inject selected secrets into both the agent runtime and the task environment.