Security#

Nixi takes a security-first approach to system management. When you trust an AI agent with your servers, strong defaults and guardrails are essential.

Confirmation Requirements#

Destructive actions are gated by a confirmation mechanism enforced at the tool level. The LLM cannot bypass this – it must present changes and get explicit approval before proceeding.

Confirmations are handled by the agent, not the LLM. The tool returns a bulleted summary which the agent presents directly. The confirmed parameter is hidden from the LLM’s tool schema so it cannot bypass confirmation. If you say “yes” along with additional instructions, Nixi combines them into one workflow without double-confirming.

File System Boundaries#

• Container data is restricted to /srv/<container-name>/
• Volume mounts outside of /srv/ are rejected at the tool level
• Container removal keeps data by default (purge must be explicitly requested)
• Nixi cannot read or write arbitrary files on the system

Sensitive Data Handling#

• Secure secret prompts – when a tool needs a secret (SMB password, database credential, API key), the user is prompted via a masked password input. The secret is passed directly to the tool and never enters the LLM conversation history or chat display. This works in both TUI and Web UI.
• Passwords, tokens, secrets, and API keys are redacted in all tool output
• Both the LLM context and the TUI display see redacted values
• NixOS configuration reads automatically filter sensitive lines
• Nixi will never display or log credentials
• SMB credentials are stored in root-owned files under /srv/.credentials/ with mode 600, never in NixOS configuration or command output
• The LLM is instructed to never pass secrets as tool arguments – it leaves secret fields empty and the secure prompt mechanism handles the rest

Permissions Model#

Nixi uses a layered permissions approach:

/srv/ ownership#

The /srv/ directory is owned by the nixi user. All container data and file operations under /srv/ work without sudo. This is the primary data storage location for all containers and services.

Scoped sudo#

Only system-level commands that require root are allowed via sudo. Destructive file commands (rm, cp, mv) are NOT given sudo access to prevent accidental or malicious damage outside of /srv/.

No blanket root access is granted. The install script configures these rules through the NixOS security.sudo.extraRules option.

Web UI Authentication#

The web UI is password-protected by default. On first nixi serve, a random password is auto-generated and printed to the terminal.

• Password storage – bcrypt hash in ~/.config/nixi/config.toml, never stored in plaintext
• Sessions – HMAC-signed httpOnly cookies with 30-day expiry, regenerated on each server start
• Login page – failed attempts return a generic error (no user enumeration)
• WebSocket protection – unauthenticated WebSocket upgrades are rejected with 401
• Password management – nixi auth --set prompts for a new password with hidden input; leave empty for random (requires shell access)

If you’re exposing the web UI beyond your LAN, use a reverse proxy with TLS (see Web UI).

Network Security#

• Containers use a shared nixi network for internal DNS resolution (works with both Podman and Docker)
• Cross-node communication uses node IP addresses (container DNS is local only)
• The web UI requires password authentication (auto-generated on first run)
• Nixi enforces strong defaults and will warn about insecure configurations
• If you request something insecure (disabling firewall, weak passwords, exposing services without auth), Nixi will suggest a secure alternative and require explicit confirmation if you insist

SSH Security (Multi-Node)#

When managing remote nodes via SSH:

• Key-based auth only – BatchMode=yes ensures SSH never prompts for passwords during operation. Keys are installed once during /adopt
• Host key verification – new host keys are accepted on first connection (StrictHostKeyChecking=accept-new), but changed keys are rejected to prevent MITM attacks
• Connection timeout – 10-second timeout prevents hanging on unreachable nodes
• Password handling – during /adopt, passwords are handled entirely in the TUI and never sent to the LLM
• Monitored mode – nodes in monitored mode have a MonitoredExecutor that blocks all mutating commands at the executor level, regardless of what the LLM requests
• Known host cleanup – removing a node clears its SSH known host entry, so re-adoption with a new key works cleanly

Secure Defaults#

Nixi always prefers security over convenience:

• Strong passwords and proper permissions by default
• TLS where available
• Firewall ports are not opened unless explicitly requested
• Default container images are pulled from trusted registries
• Warnings are shown when default passwords are in use