Parallax Security Model

Security Architecture

Defense in depth through multiple independent security layers. Every operation is validated, logged, and controlled.

Three-Stage Validation Flow

Agent emits <tool_call>
  → 1. checkPolicy('tool', toolName)
       — is this tool allowed?
  → 2. checkPolicy('shell', command)
       — is the shell command safe? (regex deny)
  → 3. checkPolicy('domain', hostname)
       — is the domain allowed? (web_search only)
  → DENY → error returned to agent (no execution)
  → ALLOW → tool.execute() runs
  → Lens: policy_check + tool_call events logged

Encrypted Credential Vault

All sensitive credentials are encrypted using AES-256-GCM with PBKDF2 key derivation (100,000 iterations, SHA-256). The passphrase is never stored — only held in the environment variable at runtime.

  • ◆AES-256-GCM encryption for all stored secrets
  • ◆PBKDF2 key derivation with 100,000 iterations
  • ◆12-byte random IV per encryption operation
  • ◆Passphrase held only in environment variable (CORTEX_VAULT_KEY)
  • ◆Full access audit log (vault_access_log)

Parallax 3-Stage Validation

Every tool call passes through a 3-stage validation gate before execution. Any stage can deny the operation, preventing unauthorized or dangerous actions.

  • ◆Stage 1: Tool name policy check — is this tool allowed?
  • ◆Stage 2: Shell command pattern check — regex deny rules for dangerous commands
  • ◆Stage 3: Domain allow/deny — for web search URLs
  • ◆All decisions logged as policy_check events in Lens
  • ◆Default-deny for known dangerous patterns (rm -rf /, fork bombs, disk writes)

Policy Engine

Granular allow/deny rules with priority-based evaluation. Rules are stored in SQLite and evaluated by priority (lower number = higher precedence).

  • ◆Three rule kinds: tool, shell, domain
  • ◆Regex-based pattern matching
  • ◆Priority ordering for rule precedence
  • ◆Default-allow when no rules match
  • ◆Pre-seeded deny rules for dangerous shell patterns

Sandboxed Code Execution

Code execution happens in isolated Docker containers with strict resource limits and no network access. Subprocess fallback available when Docker is not present.

  • ◆Docker containers with --network=none (no external access)
  • ◆256MB memory limit, 0.5 CPU cores
  • ◆64 PID limit and no-new-privileges security flag
  • ◆30-second execution timeout
  • ◆64KB output cap to prevent log flooding
  • ◆Ephemeral containers — no data persists

Cortex Lens Audit Trail

Every security-relevant event is logged to the Cortex Lens database, providing a complete audit trail for all system activity.

  • ◆All LLM calls logged (provider, model, tokens, cost)
  • ◆All tool calls logged (tool name, arguments, timestamp)
  • ◆All policy checks logged (allowed/denied with reason)
  • ◆All vault access logged (credential name, access time)
  • ◆Session lifecycle events (create, resume, close)

Approval Gates

Sensitive operations require explicit user approval before execution. The shell and code_exec tools have built-in approval gates.

  • ◆Shell command execution requires approval by default
  • ◆Code execution in sandbox requires approval
  • ◆Configurable approval timeout
  • ◆Policy-based automatic approval for trusted patterns
  • ◆Full audit of all approved and rejected operations

Default Deny Rules

The following dangerous patterns are blocked by default on first migration:

PatternBlocks
rm\s+-rf\s+/Recursive root filesystem delete
:(\)\{.*\}Shell fork bomb attacks
dd\s+if=.*of=/dev/Direct block device writes
chmod\s+777\s+/World-writable root permissions