Skip to main content
Every value you inject into a sandbox is one of two things: a plain environment variable or a vault-backed secret. This page explains the decision so you can pick the right one, then points you to the guides that cover each in depth.

​
The decision

You declare both in the [env] table of .amika/config.toml. The difference is whether the value itself lives in the repo or in the Amika vault.
The rule of thumb: if you would be uncomfortable seeing the value in your Git history, make it a secret. Otherwise a plain value is simpler and versioned with your code.

​
Security model today

Secrets are resolved at sandbox creation time and copied into the sandbox VM, where they are readable as environment variables from inside the sandbox. The vault protects secrets at rest and keeps them out of your repository — it does not currently isolate them from code running in the sandbox.
A future design (tokenized secrets swapped in by a network proxy on outbound requests, so the agent never sees real values) is described under Secrets Vault in the roadmap. Until that ships, treat any secret injected into a sandbox as visible to the agent and any code it runs.

​
Where to go next

  • Manage secrets — push, list, and update vault secrets, including Claude and Codex credentials.
  • Inject credentials — wire stored secrets and agent credentials into a sandbox at create time.
  • config.toml reference — the full [env] syntax, including service references.