Security

Security Model

CortexPrism uses a Parallax security model — all tool calls pass through a multi-layer policy system before execution.

Architecture

Agent → Tool Intent → Policy Validator → Executor
                            │
                   [regex allow/deny rules]
                   [capability level (CPL)]
                   [optional human approval]

Policy Validator

Every tool call an agent makes is evaluated before execution:

1. The agent emits a tool intent (e.g. shell("rm -rf /tmp/cache"))
2. The validator evaluates the intent against all active policy rules
3. The intent is either approved, denied, or held for human approval

Default Deny Rules

Seeded on first cortex migrate:

Pattern	Blocks
rm\s+-rf\s+/	Recursive delete from root
:\(\)\{.*\}	Fork bomb patterns
dd\s+if=.*of=/dev/	Direct disk writes
chmod\s+777\s+/	World-write on filesystem root

Managing Rules

cortex policy list
cortex policy add "curl.*evil\.com" --kind shell --effect deny --reason "Blocked domain"
cortex policy check shell "rm -rf /etc"
cortex policy remove pol_abc123

Rules are evaluated by priority (ASC order). The first matching rule wins. If no rule matches, the default is to allow.

AES-256-GCM Vault

API keys and credentials are stored encrypted using:

• AES-256-GCM symmetric encryption
• PBKDF2 key derivation (100,000 iterations, SHA-256)
• Passphrase supplied via CORTEX_VAULT_KEY env var (never stored on disk)

export CORTEX_VAULT_KEY="your-passphrase"
cortex vault store "openai-key" --service openai
cortex vault get "openai-key"

Once vaulted, credentials are removed from config.json plain text.

Cortex Lens (Audit Log)

Append-only audit log in lens.db tracking:

• Every LLM call (provider, model, token counts)
• Every tool call (name, arguments, result, policy decision)
• Every policy evaluation (rule matched, effect, reason)
• Session start/end events

Visible in the Web UI under the Lens tab and queryable via GET /api/lens/recent.

CPL (Capability Level)

YAML-based policy files defining capability boundaries:

version: 1
description: "Custom security policy"
rules:
  - kind: shell
    effect: deny
    pattern: "rm\\s+-rf\\s+/"
    reason: "Prevent recursive root delete"
    priority: 1
  - kind: domain
    effect: allow
    pattern: "api\\.github\\.com"
    reason: "Allow GitHub API access"
    priority: 10

Loaded via cortex policy or auto-loaded from .cortex/policy.yml.

Code Sandbox Isolation

Code execution runs in ephemeral Docker containers with:

• No network access by default
• CPU and memory resource limits
• No host filesystem mounts
• Container destroyed immediately after execution

Subprocess fallback available for systems without Docker (less isolation, retains policy gating).

No Telemetry

CortexPrism collects no telemetry. No usage data, prompts, or credentials are ever sent to external servers.

Known Limitations

• Policy validator operates on intent strings — best-effort filter, not OS-level sandboxing
• LLM prompt injection through untrusted content is a risk — review tool approvals carefully
• Subprocess code execution has no container isolation — use Docker for untrusted code

Reporting Vulnerabilities

See the Security Policy for the responsible disclosure process.