Skip to main content
Enterprise feature. OSS ships the OIDC config/storage plumbing referenced elsewhere on this page, but the actual SSO login redirect/callback route is nasiko-ee only — see SSO setup.
Nasiko handles two categories of sensitive material, both encrypted at rest with AES-256-GCM:

​
Per-agent secrets

Secrets are encrypted before they’re written to the database and decrypted only when injected into a container’s environment at deploy time. Plaintext exists in memory for that deploy call and then inside the running container — nowhere else.
  • Stored ciphertext-only. A database dump never exposes raw values.
  • Decryption happens once, server-side, immediately before the container starts.
  • Rotating a secret and restarting the agent re-injects the new value. Nothing is cached outside the container’s environment.
SECRETS_ENCRYPTION_KEY is a 32-byte base64 value validated at startup — the server refuses to start if it’s missing or malformed. Generate it from a cryptographically secure source, store it in your secrets manager, and rotate it deliberately: rotation invalidates every secret encrypted under the old key, so all agent secrets must be re-entered afterward.
See managing agent secrets for the CLI and API workflow.

​
Platform identity secrets

Nasiko supports SSO through any OIDC-compliant identity provider (Entra ID, Okta, Auth0, Keycloak, and others). The client secret is encrypted at rest under the same scheme, whether configured via environment variables at deploy time or the admin settings API at runtime. See SSO setup, including how group claims can place users into roles, teams, and departments automatically.

​
Where this fits