Security

Security in the Opta stack is built on a local-first architecture, localhost-bound services, token-based authentication, and a three-tier rule system that governs what the AI agent can and cannot do.

Security Model

The Opta security model is designed around a fundamental principle: the AI should have the minimum privileges needed to accomplish its task, with clear escalation paths for destructive or sensitive operations. Every tool call, file access, and command execution passes through a permission check before proceeding.

The security architecture has four layers:

1. Network isolation -- the daemon binds to localhost only
2. Authentication -- Bearer token required for all daemon API access
3. Permission system -- per-tool approval rules with user confirmation
4. Guardrails -- hard rules that cannot be overridden by the model

Local-First Architecture

The entire Opta stack runs on your local network. Inference happens on your Apple Silicon hardware, session data is stored on your local filesystem, and the daemon only accepts connections from localhost. No data is sent to external servers unless you explicitly configure cloud integration.

This is not "privacy by policy" (where a cloud service promises not to read your data). This is privacy by architecture -- the data physically cannot leave your network because there is no cloud component to send it to.

Localhost-Only Daemon

The Opta daemon binds exclusively to 127.0.0.1:9999. This is enforced at the network level -- the daemon will not accept connections from other machines on the network, even on the same LAN. This prevents unauthorized access from other devices.

Listen address: 127.0.0.1:9999
Accepts connections from: localhost only
Remote access: NOT supported (by design)
LMX connections: outbound only (daemon → LMX)

Bearer Token Auth

All HTTP requests to the daemon require a Bearer token in the Authorization header. The token is generated when the daemon starts and stored in ~/.config/opta/daemon/state.json. Token validation uses crypto.timingSafeEqual to prevent timing attacks.

For WebSocket connections, the token is passed as a query parameter (?token=T) since WebSocket does not support custom headers during the handshake.

The token rotates on every daemon restart. This limits the window of exposure if a token is compromised -- restarting the daemon immediately invalidates all existing tokens.

Three-Tier Rule System

The Opta guardrail system organizes rules into three tiers based on severity and enforceability:

The specific rules in each tier are detailed in the Guardrails section.

Detailed Sections

The security documentation is organized into three focused sections:

• Permissions -- how tool permissions work, default policies, and the approval workflow
• Privacy -- local-first privacy guarantees and data handling
• Guardrails -- the complete rule set with Critical, Strict, and Guideline tiers