Secrets

Secrets are encrypted user-owned credentials that Dreadnode can inject into runtimes and evaluation sandboxes as environment variables without ever returning the plaintext value in normal API reads.

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 any API.
• Injected at runtime: secrets are decrypted only 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.

Workflow

The normal secret workflow looks like this:

1. Store a secret from the App settings page or the API.
2. Verify the configured state in the App or with /secrets in the TUI.
3. Select the specific secrets you want at runtime or evaluation creation time.
4. Reprovision or rerun when a rotated value needs to take effect.

This distinction matters because Dreadnode treats the secret library as a user-owned source of truth and secret_ids as the explicit execution-time selection.

Scoping and selection

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

When you provision an interactive runtime, you pass the list of secret IDs to inject (secret_ids). That selection applies to that runtime request; the project is only the grouping bucket for the resulting resource.

When you create an evaluation, you can also pass secret_ids. The platform injects those same user-owned 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 also lets you choose secrets by env-var-style selectors 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 evaluation request.

There is not currently a standalone CLI secret CRUD command group. Secret management today is primarily an App, TUI-inspection, SDK, and API workflow.

Injection into sandboxes

Secrets are injected as environment variables at sandbox creation time. If you want different secrets on an existing runtime, provision or restart that runtime with a different secret_ids selection. If you want different secrets for an evaluation run, create a new evaluation with a different secret_ids selection. Secrets are only injected when you pass their IDs — they are not automatically injected into every sandbox.

Provider presets

Provider presets let you create secrets with canonical environment variable names. Supported presets:

Provider	Env var name
openai	OPENAI_API_KEY
anthropic	ANTHROPIC_API_KEY
github	GITHUB_TOKEN
tinker	TINKER_API_KEY

When you create a secret from a preset, the env var name is automatically set to the preset value. You still choose whether to auto-inject the secret by passing its ID in secret_ids.

Lifecycle and management

Common actions

• Create and update secrets from App settings or the API.
• Inspect configured secrets and provider presets from /secrets in the TUI.
• Delete secrets you no longer use through the App or API.
• Use evaluation --secret selectors in the CLI when you need to map known env-var names to concrete secret_ids.

App, TUI, CLI, and API roles

Surface	Best use
App	create, rotate, and delete your 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

Lifecycle expectations

Step	What happens
Create	Secret is stored encrypted and shown with a masked preview
Select	You choose which secrets to inject for a runtime request
Provision	Secrets are decrypted and injected into the sandbox
Rotate	Update the value and reprovision or restart the runtime to apply

Nuances and pitfalls

• Provider presets only report whether a canonical secret exists, not whether a specific runtime is already using it.
• Secret values are never returned by normal read APIs. You only see metadata and masked previews.
• Evaluations pass selected secret_ids into both the agent runtime sandbox and the task environment sandbox created for each sample.