Security fixes are applied to the latest stable release. We strongly recommend always running the most recent version.

Please do not open a public GitHub issue for security vulnerabilities.

To report a security issue, email us at:

security@cortexprism.io

Include as much of the following as you can:

• A description of the vulnerability and the potential impact
• Steps to reproduce (proof-of-concept code or detailed reproduction steps)
• Affected versions
• Any suggested mitigations or patches

We follow responsible disclosure — we ask that you give us reasonable time to patch before any public disclosure.

CortexPrism is designed with a defense-in-depth approach. Multiple independent layers protect against both local misuse and compromised LLM outputs.

Every tool call an agent makes passes through the policy validator 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 (regex allow/deny)
3. The intent is either approved (forwarded to the executor), denied (error returned to agent), or held for human approval

Default deny rules (seeded on first cortex db migrate):

• 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

Custom rules can be added with cortex policy add.

API keys and other credentials are stored in an encrypted SQLite database (vault.db) using:

• AES-256-GCM symmetric encryption
• PBKDF2 key derivation (100,000 iterations, SHA-256)
• The passphrase is never persisted — it must be supplied via CORTEX_VAULT_KEY at runtime

No credentials are written to config.json in plain text once they have been vaulted.

All activity is written to an append-only audit log in lens.db:

• 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

The Lens timeline is visible in the Web UI and queryable via the REST API.

Tool permissions are evaluated per-task rather than statically at install time:

• Risk profiles for 13 tool categories with default guardrails (readOnly, restrictedPaths, allowedDomains, maxDurationMs, requireConfirmation)
• Four decision levels: granted, granted_with_guardrails, denied, requires_approval
• Structured approval pipeline with auto-approve thresholds, webhook notifications, promise-based resolution, and automatic expiry (5-minute default timeout)
• Temporary grants are cached per-session for previously approved tools

All agent outputs and tool results are scanned by a 22-scanner DLP pipeline:

• Credential detection: AWS keys, GitHub tokens, OpenAI/Anthropic/Google API keys, JWTs, private keys (RSA/EC/DSA), PEM certificates, database connection strings
• PII detection: credit cards, SSNs, emails, IP addresses
• Three action levels: monitor (log only), redact (replace with placeholders), block (reject the output)
• Registered as a pre-output and post-tool pipeline hook, run on every agent turn

Pluggable content safety middleware with 5 built-in classifiers:

• Prompt injection — 10 detection patterns (ignore-previous-instructions, jailbreak DAN/STAN, system override)
• PII leakage — output-side PII detection
• Harmful code — destructive commands (rm -rf /, DROP DATABASE, eval)
• Excessive length — alerts on inputs >100K characters
• Shell injection — command injection patterns (curl|bash, backtick substitution)
• Custom classifiers can be added via registerClassifier() API

Multi-tenant data isolation between Cortex sessions:

• Three modes: strict (no cross-project access), permissive (path-only isolation), shared (no restrictions)
• Path-based isolation with workspace root enforcement and allowlist overrides
• Environment variable filtering with safe-var allowlist
• Cross-session memory access control with shared-session whitelist
• Violation recording with audit trail

Before any plugin or dependency is loaded:

• SHA-256 hash verification against known-good hashes per package@version
• Blocked hash list for known-malicious content
• Digital signature verification
• Author reputation scoring (0-100)
• Blocked/allowed author lists
• Malware pattern scanning (eval, child_process, rm -rf /, curl|sh)
• Configurable blockSuspicious mode

Continuous monitoring across 6 ecosystems (npm, PyPI, Maven, Go, Cargo, NuGet):

• CVE database with severity-scored vulnerability records
• Version range matching for affected-versions parsing
• Blocked license enforcement (GPL-3.0, AGPL-3.0, BUSL-1.1, SSPL-1.0)
• Automatic remediation suggestions with safe version bump recommendations
• Periodic health checks every 6 hours

Code execution (cortex sandbox run, code_exec tool) runs inside ephemeral Docker containers with:

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

A subprocess fallback is available for systems without Docker — this provides less isolation but retains policy gating.

CortexPrism collects no telemetry. No usage data, prompts, or credentials are ever sent to external servers. The update check (cortex self update --check) is the only outbound request made by the application itself, and it can be skipped by running with --check in offline environments.

• The policy validator operates on intent strings — it is a best-effort filter, not a sandboxing solution. For high-risk deployments, combine with OS-level sandboxing.
• LLM outputs are processed as text; prompt injection through untrusted content in files or web pages is a risk. The DLP Guard and AI Guardrails (prompt injection, harmful code, PII leakage classifiers) provide defense-in-depth, but all guardrails are heuristic-based and may not catch every instance.
• The supply chain integrity verifier uses SHA-256 hash comparison and pattern matching — it does not perform static analysis or sandboxed execution of plugin code.
• The subprocess fallback for code execution has no container isolation — use Docker when running untrusted code.
• Session isolation is enforced at the application layer — it is not a kernel-level security boundary. For multi-tenant deployments, combine with OS-level user separation.

Dependencies are managed via deno.json and deno.lock. To audit for known vulnerabilities:

deno run --allow-net https://deno.land/x/deno_audit/main.ts

We encourage contributors to report outdated or vulnerable dependencies via the private email channel above, or as a regular GitHub issue if the dependency vulnerability is already public.