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 (200,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 200,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
  • ◆Seeded deny rules for dangerous patterns (rm -rf /, fork bombs, disk writes)
  • ◆Default-allow when no rules match — add explicit deny rules for sensitive operations

Policy Engine

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

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

CPL (Capability Level)

YAML-based policy files defining capability boundaries for the agent. Rules can be managed via the CLI or auto-loaded from a policy file. Each rule specifies kind, effect, pattern, and priority.

  • ◆YAML policy files with versioned schema
  • ◆Rules evaluated by priority order (ASC) — first match wins
  • ◆Supports shell, tool, and domain rule kinds
  • ◆Allow or deny effects with descriptive reasons
  • ◆Auto-loaded from ~/.cortex/policy.yml if present

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 can require explicit user approval before execution. The shell and code_exec tools have configurable approval gates that can be toggled per session or policy.

  • ◆Shell command execution can require approval (configurable)
  • ◆Code execution in sandbox can require approval (configurable)
  • ◆Configurable approval timeout
  • ◆Policy-based automatic approval for trusted patterns
  • ◆Full audit of all approved and rejected operations

LLM Security Supervisor

Sensitive data access (memory, databases, screenshots) requires approval from a fast LLM supervisor model with decision caching and human escalation for uncertain cases.

  • ◆Fast supervisor models: Gemini 2.0 Flash, GPT-4o Mini
  • ◆Decision caching with 1-hour session TTL to reduce latency
  • ◆Human escalation for uncertain classification cases
  • ◆Structured approval pipeline with auto-approve thresholds
  • ◆Webhook notifications for pending approvals with 5-minute timeouts
  • ◆Temporary grants: approved access cached per session to prevent approval fatigue

DLP Guard & Data Classification

Automatic sensitivity detection and data loss prevention. Classifies data as SECRET/SENSITIVE/NORMAL/PUBLIC with 22 DLP scanners monitoring all agent outputs.

  • ◆Automatic classification: SECRET/SENSITIVE/NORMAL/PUBLIC based on pattern matching
  • ◆Detects passwords, API keys, PII, PHI, PCI, and confidential markers
  • ◆22-scanner DLP system monitoring all agent outputs
  • ◆Three action levels: monitor (log only), redact (mask in output), block (deny entirely)
  • ◆All existing data backfilled with classifications on first run
  • ◆AI Guardrails: 5 pluggable classifiers for prompt injection, PII leakage, harmful code, excessive length, shell injection

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