Skip to main content
Secrets are scoped to an agent or shared vault-wide, stored AES-256-GCM encrypted, and decrypted into the container environment at deploy time. See secret management overview for the encryption model.
This is separate from your project’s local .env (used only by nasiko run .) and from the control plane’s own environment (used by the routing engine and orchestrator chat) — the same key commonly needs to be set in all three places for different parts of the platform to work. See the quickstart prerequisites for the full breakdown.

​
CLI

Without --agent, a secret lives at the vault level and any agent you deploy can reference it.

​
API

The same operations are split across two route families, not one: Both are authenticated the same way.

​
Who can manage secrets

Setting, reading, or removing secrets requires the can_manage_secrets permission. See access control.

​
How secrets reach a running agent

Secrets aren’t mounted as files or fetched at runtime. They’re decrypted server-side and injected as environment variables at deploy time, alongside the observability configuration. To the agent, a secret is just an environment variable that’s there at process start.
Changing a secret’s value doesn’t affect an already-running container. Run nasiko restart to re-read the current secret set and re-inject it.

​
Refresh on scale-up

When an agent scales up, Nasiko refreshes secrets immediately before new replicas start, so every replica runs current values. Scaling up is itself a refresh point — no manual restart needed after rotating and then scaling.