Security Controls

Eight subsystems, one defense-in-depth control plane.

The Project-AI security architecture is not a single firewall — it is eight interlocking subsystems coordinated by a central orchestrator. Each subsystem publishes invariants, exposes telemetry, and produces audit-grade evidence.

System interactions

         ┌─────────────────────────────────────────────────────┐
         │   8 · Contrarian Firewall Orchestrator              │
         │       Central Security Kernel                       │
         └────┬────────────┬────────────┬───────────┬──────────┘
              │            │            │           │
              ▼            ▼            ▼           ▼
         ┌────────┐  ┌──────────┐  ┌────────┐  ┌──────────┐
         │ 1 Hydra│  │ 2 Lock-  │  │ 3 Run- │  │ 5 Monitor│
         │Defense │  │ down     │  │ time   │  │  Alerts  │
         └───┬────┘  └────┬─────┘  └────┬───┘  └────┬─────┘
             │            │             │           │
             └────────────┼─────────────┼───────────┘
                          ▼             ▼
                    ┌────────────────────────┐
                    │  4 · Observability     │
                    │     Telemetry & SLOs   │
                    └────────────────────────┘
                                ▲
                                │
                  ┌─────────────┴─────────────┐
                  │                           │
              ┌───────────────┐       ┌────────────────┐
              │ 6 Agent Sec.  │       │ 7 Data Valid.  │
              │  Encapsulation│       │  XXE / CSV / JSON
              └───────────────┘       └────────────────┘

control 01·1,200+ LOC

Cerberus Hydra Defense

Exponential multi-implementation spawning

Inspired by the mythological Hydra: when a defensive agent is bypassed or disabled, the system spawns 3 replacements in a randomly-chosen language combination. 50 human × 50 programming languages → 2,500+ unique implementations.

Capabilities

▸Exponential 3× spawn factor on every confirmed bypass
▸Polyglot diversification across 50+ programming runtimes
▸Cross-language process lifecycle management
▸Generation depth bounded (0–5) with parent tracking
▸Bypass event records with risk score + attacker signature

Guarantees

✓No single-language failure can collapse the defensive layer.
✓Spawn is deterministic given a (bypass_event, lockdown_stage) tuple.
✓Every spawned agent is registered before it executes.

Invariants

Spawn factor

SPAWN_FACTOR = 3

Polyglot space

|H| × |P| ≥ 2500

Generation bound

gen(a) ≤ 5

src/app/core/cerberus_hydra.py

control 02·384 LOC

Lockdown Controller

25-stage progressive system lockdown

Granular containment without shutdown. 25 lockable sections — authentication, data access, model weights, inference, credentials — escalate deterministically from risk score and bypass depth. Idempotent; survives restart.

Capabilities

▸25 lockable sections across auth, data, AI, monitoring tiers
▸Deterministic stage formula from risk and bypass depth
▸Idempotent — re-applying a stage is a no-op
▸Persistent state across process restarts
▸Observation mode for non-destructive testing

Guarantees

✓Refusal is always cheaper than uncontained execution.
✓Operational continuity at every stage below 25.
✓Lockdown state is restartable evidence, not volatile RAM.

Invariants

Stage domain

stage ∈ [0, 25]

Monotone escalation

stage(t+1) ≥ stage(t) until reset

Determinism

stage = f(risk, depth)

src/app/core/cerberus_lockdown_controller.py

control 03·331 LOC

Runtime Manager

Multi-language runtime health verification

Health-gates the polyglot agent fleet. Every runtime (Python, Rust, Go, Java, …) is verified at startup with a bounded health check; selection is biased toward verified, healthy runtimes. Unhealthy runtimes degrade silently — never crash spawning.

Capabilities

▸Startup verification of 50+ runtimes with 5s timeout
▸Health classification: healthy · degraded · unavailable
▸Weighted selection biased to verified runtimes
▸Command-injection-safe exec_path resolution
▸Fallback Python runtime if registry is missing

Guarantees

✓No agent is ever spawned in an unverified runtime.
✓Failed health checks degrade — never panic.
✓Selection is reproducible given the verified set.

Invariants

Verify before use

spawn(a) ⇒ verified(runtime(a))

Timeout bound

health_check ≤ 5s

Fallback

|R_healthy| = 0 ⇒ python3

src/app/core/cerberus_runtime_manager.py

control 04·437 LOC

Observability & Metrics

Telemetry, SLOs, incident forensics

Per-agent timelines, incident graphs (Hydra topology), Prometheus-compatible metrics, and SLO tracking. The Cerberus subsystem is observable end-to-end so refusals can be replayed and defended in audit.

Capabilities

▸Per-agent timeline of tasks, decisions, terminations
▸Hydra incident graph: nodes = agents, edges = spawns
▸SLO sampling: detect→lockdown latency, false positives, overhead
▸Prometheus-format metric emission
▸Forensic export per incident

Guarantees

✓Every agent action appears in a replayable timeline.
✓Every spawn appears as a graph edge with metadata.
✓Refusals are first-class events, not silences.

Invariants

Detect → lockdown

p50 < 3s

False positive rate

FPR < 5%

Containment rate

CR > 95%

Resource overhead

Δ < 15%

src/app/core/cerberus_observability.py

control 05·431 LOC

Security Monitoring

CloudWatch metrics · SNS alerting · audit logs

Cloud-native event pipeline. Structured JSON audit logs, CloudWatch metric emission, SNS alerts on high/critical severity, and threat-campaign signature matching (Log4Shell, JNDI, etc.). Falls back to local-only logging when AWS is absent.

Capabilities

▸Severity-tiered events (critical · high · medium · low)
▸Auto-alert on high/critical to SNS topic
▸Structured JSON audit log with metadata
▸Named threat-campaign signature registry
▸Anomaly detection over rolling windows

Guarantees

✓No security-relevant event is dropped silently.
✓Alert routing is severity-bounded — no alert storms on low-tier.
✓Local fallback when cloud is unreachable.

Invariants

Severity scale

S ∈ {critical, high, medium, low}

Alert trigger

S ∈ {critical, high} ⇒ SNS publish

Audit hash

every event ⇒ JSON record + hash

src/app/security/monitoring.py

control 06·469 LOC

Agent Security

Encapsulation · numerical bounds · plugin isolation

Defense-in-depth for agents operating in adversarial environments. Read/write/execute permissions on agent state, numerical clipping and outlier rejection, multiprocessing-based plugin isolation, and a runtime fuzzer for resilience testing.

Capabilities

▸Agent state encapsulation with per-caller access log
▸Numerical clipping to safe bounds ([−1e6, 1e6])
▸Z-score outlier rejection on incoming tensors
▸Safe division (zero → configurable default)
▸Plugin isolation via subprocess with timeout
▸4-strategy input fuzzer for resilience tests

Guarantees

✓No untrusted code mutates agent state without authorization.
✓Numerical pathways cannot panic on NaN/Inf/div-by-zero.
✓A hostile plugin cannot exhaust the host process.

Invariants

State access

set(k, v) ⇒ caller ∈ allowed

Numeric bound

x ∈ [−1e6, 1e6]

Isolation

plugin → subprocess(timeout)

src/app/security/agent_security.py

control 07·556 LOC

Data Validation

Secure parsing · XXE · CSV · JSON

Validate everything, trust nothing, sanitize by default. XML via defusedxml (XXE-blocked), CSV with formula-injection detection, JSON with schema enforcement, and a 17+ pattern data-poisoning defense (XSS, SQLi, path traversal, Log4Shell, template injection, CRLF).

Capabilities

▸XML: XXE / DTD / external entity blocking
▸CSV: formula-injection prefix detection (=, +, -, @)
▸JSON: schema validation with required-field enforcement
▸Attack-pattern matcher (17+ classes)
▸SHA-256 content hash on every parsed payload

Guarantees

✓No untrusted XML can read the local filesystem.
✓No spreadsheet formula reaches end-user clients.
✓Every parsed payload has a content-addressed hash.

Invariants

XXE

parse_xml(p) ⇒ no_entity_resolution

CSV cell

cell[0] ∉ {=, +, -, @}

Schema

data ⊨ schema

src/app/security/data_validation.py

control 08·24.7 KB

Contrarian Firewall Orchestrator

Monolithic central security kernel

The central kernel. Coordinates Hydra, Lockdown, Runtime, Observability, Monitoring, Agent Security, and Data Validation through a single orchestration point. Adaptive chaos/stability balancing, bi-directional agent communication, deep integration with TARL governance and the Triumvirate.

Capabilities

▸Modes: passive · active · aggressive · adaptive (default)
▸Stability tiers: stable · balanced · chaotic · maximum chaos
▸Threat intel ingest from 6 sources (swarm, Cerberus, Thirsty-Lang, …)
▸Real-time auto-tuning of chaos / stability balance
▸Bi-directional channel: agents ↔ governance ↔ firewall
▸Deterministic audit trail across the whole stack

Guarantees

✓One coordination point — no silent subsystem drift.
✓Auto-tuning is bounded by configured operational mode.
✓Every cross-subsystem decision is anchored in the audit ledger.

Invariants

Mode bound

mode ∈ {passive, active, aggressive, adaptive}

Chaos bound

χ ∈ [0, 1]

Audit completeness

decision ⇒ ledger entry

src/app/security/contrarian_firewall_orchestrator.py

Service-level objectives

Metric	Target	Source
Detect → lockdown latency	p50 < 3s	Observability
False positive rate	< 5%	Observability
Containment rate	> 95%	Observability
Resource overhead	< 15%	Observability
Spawn factor on bypass	3× per event	Cerberus Hydra
Polyglot diversity	≥ 2,500 combinations	Cerberus Hydra
Runtime health-check timeout	≤ 5s	Runtime Manager
Lockdown idempotence	always	Lockdown Controller