Manage Secrets

Secrets - API keys, tokens, credentials - are stored encrypted by the platform and delivered to agents only at bootstrap and renewal. They come in two scopes: organization secrets shared by every agent, and per-agent secrets that apply to one agent (and can override an org secret).

Organization secrets

dvx secret list
dvx secret set <name> --value <value>
dvx secret set <name> --from-file ./key.txt   # or --from-file - to read stdin
dvx secret delete <name>

A common one is the LLM API key, shared by all agents:

dvx secret set llmproxy:llm.api_key --value sk-ant-...

Per-agent secrets

Set a secret on a single agent:

dvx agent secret list my-agent
dvx agent secret set my-agent <name> --value <value>
dvx agent secret delete my-agent <name>

To override a service’s credential for just this agent - for example, give one agent its own LLM key - use --override-service:

dvx agent secret set my-agent llmproxy.api_key --override-service llmproxy --value sk-ant-...

The platform checks the agent-level override first and falls back to the org-level secret.

Operator-only vs agent-delivered

By default, user-defined secrets are delivered to the agent process. To keep a value visible to operators but not handed to the agent, set it operator-only:

dvx agent secret set my-agent <name> --value <value> --no-agent-accessible

Credential injection

A secret can be injected into the agent’s outbound requests (e.g. an Authorization header to a specific host) so the agent uses the credential without ever reading it. Manage these rules with:

dvx secret add-injection <secret-name> --domain api.example.com --header Authorization
dvx secret list-injection <secret-name>
dvx secret rm-injection <secret-name> <rule-id>

For provider identities that are provisioned automatically (GitHub/GitLab), see Use integrations from the CLI.