Security Controls

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

The Project-AI security documentation describes eight interlocking subsystems. The invariants below are requirements and targets; they are not promoted as universal guarantees without pinned runtime evidence.

Control evidence matrix

Control	Source status	Implementation evidence at pinned source	Runtime verification
Cerberus Hydra Defense	Documented	src/app/core/cerberus_hydra.py	Unverified by this portal
Lockdown Controller	Documented	src/app/core/cerberus_lockdown_controller.py	Unverified by this portal
Runtime Manager	Documented	src/app/core/cerberus_runtime_manager.py	Unverified by this portal
Observability & Metrics	Documented	src/app/core/cerberus_observability.py	Unverified by this portal
Security Monitoring	Documented	src/app/security/monitoring.py	Unverified by this portal
Agent Security	Documented	src/app/security/agent_security.py	Unverified by this portal
Data Validation	Documented	src/app/security/data_validation.py	Unverified by this portal
Contrarian Firewall Orchestrator	Documented	src/app/security/contrarian_firewall_orchestrator.py	Unverified by this portal

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. CERBERUS_HYDRA_README distinguishes security-message translations in 50 human languages from runtime metadata for 50 programming languages. The resulting 2,500 pairings are a documented diversity target, not independently verified 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

Documented invariants · verification pending

✓Target: a single-language failure should not collapse the defensive layer.
✓Requirement: spawn should be deterministic for a (bypass_event, lockdown_stage) tuple.
✓Requirement: a spawned agent must be registered before execution.

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

Documented invariants · verification pending

✓Target: refusal cost remains below the cost of uncontained execution.
✓Target: preserve defined operational continuity below stage 25.
✓Requirement: lockdown state persists as restartable evidence.

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. Documented implementation claim: each runtime (Python, Rust, Go, Java, …) is checked 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

Documented invariants · verification pending

✓Requirement: do not spawn an agent in a runtime that failed verification.
✓Requirement: failed health checks produce a degraded health state rather than a panic.
✓Target: selection is reproducible for the same 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

Documented invariants · verification pending

✓Requirement: governed agent actions produce timeline evidence.
✓Requirement: governed spawns produce graph metadata.
✓Requirement: refusals are explicit events rather than silence.

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

Documented invariants · verification pending

✓Requirement: security-relevant events must not be dropped silently.
✓Target: severity-bounded alert routing avoids low-tier alert storms.
✓Requirement: local logging remains available when cloud services are unreachable.

Invariants

Severity scale

S ∈ {critical, high, medium, low}

Alert trigger

S ∈ {critical, high} ⇒ SNS publish

Audit hash

Contract invariant: 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

Documented invariants · verification pending

✓Requirement: untrusted code must not mutate agent state without authorization.
✓Target: numerical pathways handle NaN, infinity, and division by zero without panic.
✓Target: plugin isolation bounds host-process resource impact.

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

Documented invariants · verification pending

✓Requirement: untrusted XML must not read the local filesystem.
✓Requirement: spreadsheet formulas must not reach end-user clients unsanitized.
✓Requirement: parsed payloads carry 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

Documented invariants · verification pending

✓Target: a visible coordination point detects subsystem drift.
✓Requirement: auto-tuning remains bounded by the configured operational mode.
✓Requirement: governed cross-subsystem decisions produce ledger evidence.

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