Skip to content

06-COMPLIANCE-STANDARDS.md

Latest commit

 

History

History
940 lines (665 loc) · 74.9 KB

06-COMPLIANCE-STANDARDS.md

File metadata and controls

940 lines (665 loc) · 74.9 KB
Raw

06 — Compliance & Regulatory Standards

v3.0.0 additions: Canonical 1.1 evidence stream schema with 6-field record_hash cryptographic binding, centralized threshold configuration under config/thresholds/<REGION>_BASELINE.json, operational external balance reconciliation worker (POAM-023 / POAM-2026-038 closed), and strictly human-gated NeMo policy refinement.

Field Value
Version 3.0
Date 2026-09-07
Classification INTERNAL
Document CAGE-TR-06

1. Regulatory Framework Overview

Jurisdictional compliance in CAGE is a configurable posture, not a fixed property of the system. A single environment variable selects which regional framework set is active:

export CAGE_DEPLOYMENT_REGION=US_FED    # or EU_ECB, APAC_MAS, LOCAL, or an adopter-defined region

The layering is strict:

Layer Scope Behaviour
Universal baseline ISO/IEC 42001:2023, FIPS 140-2/3, OSCAL, CSA AARM Active in every posture, including LOCAL. Blocks the global release gate.
Jurisdictional extension US_FED, EU_ECB, APAC_MAS, adopter-defined Additive. Loaded only when selected. Gates regional deployment posture only — a regional gate failure never blocks the global stable tag.
Domain overlay Per-plugin <REGION>_OVERLAY.json Supplied by whichever optional domain plugin is active. Domain and jurisdiction compose independently: any plugin runs under any posture.

Several frameworks in the table below are sector-specific (FINRA, SEC, GLBA, MiFID II, EBA guidelines). They are listed because the finance example domain is one of the two case studies shipped in-tree, and because financial services is the densest regulatory surface available for stress-testing the substrate. They are not core CAGE requirements. A healthcare deployment of the same substrate loads clinical frameworks instead — via the same mechanism, with no kernel change — and an adopter in manufacturing, logistics, or energy loads theirs.

Summary of Targeted Frameworks

Column note: entries marked (All Regions) are universal-baseline obligations. Entries marked with a region label are configurable extensions active only under that posture. Entries whose scope is sector-specific apply only when the corresponding domain plugin is loaded.

Standard Authority Scope in CAGE / Active Region Mappings
NIST SP 800-53 Rev 5 NIST HIGH baseline; primary US cyber framework (US_FED)
NIST SP 800-37 Rev 2 (RMF) NIST 7-step authorization process (US_FED)
FIPS 199 NIST Security categorization (US_FED)
FIPS 140-2/3 NIST Cryptographic standards (All Regions)
ISO/IEC 42001:2023 ISO AI Management System (All Regions)
OSCAL v1.0.4 / 1.1.2 NIST Machine-readable compliance artifacts (All Regions). Artifact schema: OSCAL v1.0.4. Runtime assessment state semantics: aligned to NIST SP 800-53A §3.2 four-state model (OSCAL 1.1.2 — includes ERROR state alongside satisfied, not-satisfied, not-applicable).
ISO-20022 ISO Banking/payments standard (All Regions)
FINRA Rule 4511 FINRA 7-year records retention (US_FED)
SEC Rule 17a-4 SEC Electronic records (US_FED)
SEC Reg S-P SEC Privacy of consumer financial information (US_FED)
GLBA Federal Financial privacy (US_FED)
SR 11-7 Federal Reserve Model Risk Management (non-agentic components) (US_FED)
SR 26-2 Federal Reserve Agentic AI Risk Management (US_FED; suppressed in EU_ECB)
EU AI Act (Reg. 2024/1689) European Union High-Risk AI obligations, Art. 6, 9, 10, 12, 14, 17, 29a, 61, Annex III §5(b) (EU_ECB)
DORA European Union Digital Operational Resilience Act, Art. 10, 11, 12 (EU_ECB)
GDPR Article 22 European Union Automated individual decision-making constraints (EU_ECB)
EBA Guidelines (2023/02) EBA / ECB Internal governance for financial institutions (EU_ECB)
MAS FEAT Principles Singapore MAS Fairness, Ethics, Accountability, Transparency (APAC_MAS)
CSA AARM v1.0 Cloud Security Alliance Autonomous Agent Risk Management — 11 threat vectors (All Regions)

No single compliance program covers all frameworks. CAGE's architecture is designed so that a single evidence artifact (e.g., an OpenTelemetry trace with HMAC seal and regional baseline stamps) simultaneously satisfies NIST AU controls, ISO 42001 A.5.3 documentation, and regional electronic record mandates.

1.1 Adding a Jurisdiction

Because the region layer is data rather than code, extending CAGE to a jurisdiction it does not ship — Canada's AIDA, the UK's pro-innovation framework, Japan's FSA guidance, an internal corporate standard — is a configuration exercise:

Step Artifact Purpose
1 config/thresholds/<REGION>_BASELINE.json Numeric governance thresholds for the posture, following the schema of the shipped baselines
2 config/compliance/<REGION>_BASELINE.json Control profile — which controls are in scope and how they map to the universal baseline
3 config/opa/ region Rego Any region-specific authorization rules
4 compliance/lula/lula-validation-<region>-*.yaml Machine-checkable assertions for the new posture's gates
5 <REGION>_OVERLAY.json in each active domain plugin Domain-specific control deltas for that jurisdiction
6 CAGE_DEPLOYMENT_REGION=<REGION> Activation

No Python changes are required at any step. The new posture inherits the universal ISO 42001 baseline automatically and, per the additive rule above, its gates constrain regional deployment posture only.

Verify a posture with the region-marked test subset:

CAGE_DEPLOYMENT_REGION=<REGION> uv run pytest tests/ -m <region_marker> -v

See docs/compliance/REGION_GUARD_AUDIT.md for region-guard enforcement semantics.

2. FIPS 199 Security Categorization

Source: compliance/categorization/FIPS199_CATEGORIZATION.md

CAGE is categorized under FIPS 199 using the high-water mark rule across three security objectives per information type:

Security Objective Categorization
Confidentiality Moderate
Integrity High
Availability Moderate
Overall System Impact HIGH

The Integrity objective dominates and elevates the overall system impact to HIGH, which triggers the full NIST SP 800-53 Rev 5 HIGH baseline (approximately 350+ controls) as the applicable control set.

The Privacy Impact Assessment (compliance/pia/PRIVACY_IMPACT_ASSESSMENT.md) applies a stricter categorization of C=High / I=High / A=High, reflecting the sensitivity of PII processed in LLM prompts and the reputational impact of data exposure in a financial AI context.

Finding FIND-007: The FIPS 199 categorization document is currently unsigned by the Authorizing Official. Status: In-Progress. Tracked in POAM-009. This is a Critical finding blocking ATO.

3. NIST SP 800-53 Rev 5 Control Coverage

⚠️ US_FED ONLY — Regional Scoping Notice: NIST SP 800-53 Rev 5 is a US_FED deployment requirement only. It does not apply to EU_ECB or APAC_MAS deployments. EU_ECB stable releases are gated on EU AI Act (Reg. 2024/1689) compliance. APAC_MAS stable releases are gated on MAS FEAT compliance. See §14 (Compliance Posture Summary) and §15.2 (Supported Jurisdictions) for the full regional breakdown.

NIST SP 800-53 gates apply to US_FED deployments only. EU_ECB stable releases are gated on EU AI Act compliance. APAC_MAS stable releases are gated on MAS FEAT compliance.

Sources: docs/NIST_RMF_CHUNK1_CURRENT_STATE.md through docs/NIST_RMF_CHUNK5_MONITOR_ROADMAP.md

3.1 Overall Readiness

24% overall readiness — 113 controls sampled across all applicable families; 24 fully implemented, 23 partially implemented, 66 gaps identified.

3.2 Control Family Coverage

Control Family Coverage Key Implementations
AC (Access Control) 19% OPA Rego RBAC (src/cage_finance/opa/trade_governance.rego, config/opa/trade_policy.rego); no MFA deployed
AU (Audit & Accountability) 54% OTel traces; Langfuse; 7-year retention pipeline
CA (Security Assessment) 19% Lula 6h CronJob; SAR target 2026Q1
CM (Configuration Management) 32% config/governance_thresholds.json; Terraform IaC
IA (Identification & Authentication) 15% HMAC routing seals; no MFA; no account management procedures
IR (Incident Response) 28% GovernanceEventBus; IR-6 reporting implemented (see docs/POAM.md); full IRP authorship is an adopter responsibility for real deployments
RA (Risk Assessment) 15% compliance/rar/RISK_ASSESSMENT_REPORT.md; Lula automated checks
SC (System & Communications) 33% NetworkPolicy enforcement; Linkerd mTLS (FIND-011 resolved)
SI (System & Information Integrity) 42% Presidio PII detection; NeMo guardrails; Aho-Corasick scanning

The AU (Audit & Accountability) family is the strongest at 54%, driven by the mature OpenTelemetry and Langfuse observability stack. The IA (Identification & Authentication) family at 15% represents the most critical gap — absence of MFA and formal account management procedures directly imposes a HIGH risk finding.

4. NIST RMF 7-Step Readiness

Sources: docs/NIST_RMF_CHUNK2_PREPARE_CATEGORIZE.md through docs/NIST_RMF_CHUNK4_ASSESS_AUTHORIZE.md

4.1 Step-by-Step Scores

RMF Step Score Status Key Gaps
1–2 Prepare / Categorize 28/100 In Progress No SSP; FIPS 199 unsigned; system roles TBD
3–4 Select / Implement 29/100 In Progress No MFA; mock trace source
5–6 Assess / Authorize 22/100 Not Started Authorization package 24% complete; no ATO letter
7 Monitor 18/100 In Progress ISCM strategy document pending; no SIEM integration

No ATO (Authorization to Operate) has been granted. The security assessor determined overall risk as HIGH and does not recommend full ATO at this time. An Interim ATO (IATO) may be possible if the remaining Critical finding (FIND-007) is remediated first.

4.2 ATO Progression Roadmap

Source: docs/NIST_RMF_CHUNK5_MONITOR_ROADMAP.md

The phased roadmap targets continuous ATO posture over a 52-week horizon:

Phase 0  Weeks  1– 2  →  +38%  Authorization foundation
                           SSP draft, FIPS 199 sign-off, system role assignment

Phase 1  Weeks  2– 6  →  +45%  Quick wins
                           MFA deployment, intra-cluster mTLS, SBOM automation

Phase 2  Weeks  6–16  →  +59%  Core hardening
                           Audit pipeline production, vuln scanning, IRP activation

Phase 3  Weeks 16–52  →  +77%  Architectural uplift
                           Federated identity, SIEM integration, continuous ATO

5. ISO/IEC 42001:2023 AI Management System Compliance

Sources: docs/ISO_42001_COMPLIANCE.md, docs/SYSTEM_DESCRIPTION_ISO_42001.md

5.1 Clause Mapping

Clause Title CAGE Implementation
6 — Planning Risk-based AI planning execution_analyst risk-based plan generation
8 — Operation Runtime AI controls symbolic_governor plugin-registered pipeline (Phase 1 domain tiers + Phase 2 post-eval, with Kernel Gates 0.5 FTRA, 1 CBF, 2 OPA, 3b Consensus, 7 Causal Gatekeeper, and FRIA)
9 — Performance Evaluation Monitoring & measurement EvaluatorAuditor (src/governed_financial_advisor/agents/evaluator/) + Lula 6h CronJob
10 — Improvement Continual improvement HITL interrupt + POAM tracking

5.2 Annex A Control Mapping

Annex A Control Title CAGE Implementation
A.5.2 Social Impact Assessment NeMo nemo_output_rail guardrail
A.5.3 Documentation & Monitoring OTel trace stamping; SHA-256 hash-chained Context Accumulator (src/compliance_bridge/context_accumulator.py) — AARM-V1 Memory Poisoning neutralization
A.8.4 AI System Operation Controls HITL + Saga WAL; DEFER State Machine (src/gateway/governance/defer_queue.py) — Confidence-Starvation Boundary 0.70, AARM-V7 Context Window Overflow neutralization
A.9.2 Data Privacy & PII Presidio + NeMo (nemo_input_scan)
SC-4 Fiscal Controls / RBAC OPA Rego (opa_policy_check)

5.3 Continuous Audit Evidence Loop

The system implements an automated evidence pipeline satisfying ISO 42001 Clause 9 continuous evaluation requirements:

Lula CronJob (6h)
  → OSCAL Assessment Results (YAML)
    → POST /v1/audit/ingest (Compliance Bridge)
      → run_audit_workflow (`src/compliance_bridge/audit_workflow.py`)
        ├── Step 1:  Artifact persistence (idempotent GCS/S3 write)
        ├── Step 2:  OSCAL parse (OscalFinding extraction)
        │            OscalResult: PASS | FAIL | NOT_APPLICABLE | ERROR
        │            (see §5.5 for ERROR state semantics)
        ├── Step 2b: ContextAccumulator SHA-256 hash chain (AARM-V1)
        ├── Step 3:  Langfuse trace flush + compliance scores
        │            ERROR findings score 0.0 (same as FAIL — never masked as PASS)
        ├── Step 3b: SSE event publish — AUDIT_FINDING per finding (non-fatal)
        ├── Step 3c: Langfuse eval-dataset auto-population for FAIL findings
        │            (background task, Tier 3.2 / ISO 42001 A.7.5 — see §5.3.1)
        ├── Step 4:  Critical-control alert detection
        │            Triggered by result ∈ {FAIL, ERROR} on {A.9.2, SC-4, A.8.4}
        ├── Step 4b: SSE event publish — GOVERNANCE_VIOLATION for critical FAIL/ERROR
        │            (response returned to caller immediately after Step 4b)
        ├── Step 5:  Remediation advisor via vLLM (background task, fire-and-forget)
        └── Step 6:  AARM Conformance Report (11-vector NEUTRALIZED/PARTIAL/EXPOSED)
               GCS/S3: context_chain.ndjson + aarm_conformance.json

Steps 3c, 5, and 6 execute as background asyncio tasks scheduled after the Step 4b response is returned — they do not add to the caller-facing audit-ingest latency. All Step 5/6 errors are non-fatal (wrapped in try/except) and logged rather than raised.

This loop produces time-stamped OSCAL Assessment Result artifacts that serve as machine-readable evidence for both ISO 42001 and NIST SP 800-53 assessment records.

5.3.1 Continuous Monitoring — Evidence Age SLA (NIST SP 800-53 CA-7)

Independent of the Lula-triggered audit-ingest pipeline above, the Compliance Bridge runs a background evidence-freshness monitor implementing NIST SP 800-53 CA-7 (Continuous Monitoring):

Component Behaviour
run_sla_monitor() Started as an asyncio background task in the Compliance Bridge FastAPI lifespan context (main.py). Polls every EVIDENCE_SLA_POLL_INTERVAL_SECONDS (default 300s / 5 min).
Per-control SLA Each control has an independent maximum evidence age. A breach is detected when get_compliance_metrics() reports evidence_age_seconds > sla_seconds for that control.
Startup grace period No alerts fire while metrics.startup_grace_active is true — prevents false-positive breaches immediately after a fresh deployment before the first Lula cycle has run.
Breach alerting On breach, a synthetic OscalFinding (result="FAIL", remarks="Evidence SLA breach") is built per breached control and routed through the same notifier.send_critical_alert() path used by Step 4/4b — Slack/PagerDuty receive an identical alert shape whether the failure came from a live Lula scan or a stale-evidence detection.
Fail-soft design Exceptions in a single poll cycle are logged and the loop continues; the monitor never crashes the Compliance Bridge process. Disable via EVIDENCE_SLA_DISABLED=1.
Region awareness sla_monitor.py resolves get_sla_seconds(CAGE_DEPLOYMENT_REGION) fresh on every poll cycle via the _active_sla_seconds() helper, so jurisdictional SLA targets (SC-7/SC-8 for US_FED, Article 12 for EU_ECB, MAS-FEAT-1 for APAC_MAS) are monitored only in their applicable region, alongside the universal ISO 42001 targets (A.9.2, SC-4, A.8.4, A.5.3) which apply everywhere. Unset/unrecognised regions default to universal-only, mirroring the active_region resolution pattern used by GET /v1/controls. Resolved FINDING-05 in JURISDICTIONAL_SEPARATION_ANALYSIS.md; covered by 6 dedicated tests in tests/test_compliance_bridge_tier2.py::TestSlaMonitor.

This closes a gap that a purely CronJob-triggered audit pipeline cannot cover: if the Lula CronJob itself stops running (misconfigured schedule, RBAC failure, cluster outage), Steps 1–6 above never execute and no new evidence is produced — but no alert would fire from the audit-ingest pipeline alone, since there is nothing to ingest. sla_monitor.py independently detects the resulting evidence staleness and raises the same critical-alert path, satisfying the "detect silence, not just failure" requirement of continuous monitoring.

5.3.2 Evaluation Dataset Auto-Population (ISO 42001 A.7.5)

populate_eval_dataset() (invoked from Step 3c above) creates a Langfuse Dataset Item for every FAIL finding in a per-control dataset named cage-compliance-<control_id> (e.g. cage-compliance-A.9.2). Each item records the full OscalFinding as input, an expected_output of result: PASS (i.e. the item is a regression baseline — "this should not fail again"), and metadata linking back to the audit_id, ISO clause, and framework cross-references from CONTROL_META. Only FAIL findings are recorded; PASS findings provide no negative-example value for regression-detection eval suites. This satisfies ISO 42001 A.7.5 (Documented Information) by retaining control-failure evidence in a structured, queryable form that QA engineers and future LLM-based remediation advisories can evaluate against, rather than relying solely on point-in-time Langfuse traces.

5.5 OSCAL Assessment State Semantics (NIST SP 800-53A §3.2)

Change introduced in CAGE v2.2.0 (2026-06-01). Prior versions incorrectly mapped scanner failures to NOT_APPLICABLE. This section documents the corrected four-state model and its regulatory basis.

The OscalResult type in the Compliance Bridge defines four mutually exclusive assessment states, aligned with NIST SP 800-53A §3.2 assessment attribute vocabulary:

State OSCAL status.state Langfuse Score Triggers Alert Regulatory Meaning
PASS satisfied 1.0 No Assessment objective met — evidence satisfies the control requirement
FAIL not-satisfied 0.0 Yes (if critical) Assessment objective not met — evidence explicitly fails the control
NOT_APPLICABLE not-applicable (no score) No Control does not apply to this system component type (e.g. a wireless control on a wired-only system)
ERROR error 0.0 Yes (if critical) Control applies but the scanner/collector failed to gather evidence ("fetch failed", timeout, unrecognised OSCAL state)

Why ERROR ≠ NOT_APPLICABLE

The distinction is critical for audit integrity:

  • NOT_APPLICABLE is a deliberate, documented scoping decision. It means the control was reviewed and determined to be out of scope for this specific system component. It must be justified in the SSP and approved by the Authorizing Official.
  • ERROR is an operational failure. The control is in scope, but the evidence collection mechanism broke. The control may be violated — we simply cannot confirm it.

Masking an ERROR as NOT_APPLICABLE would:

  1. Hide a potential security blind spot from auditors and the Authorizing Official
  2. Prevent the critical-alert pipeline from firing on controls like SC-4 (Fiscal Limits) or A.9.2 (PII masking)
  3. Violate NIST SP 800-53A §3.2, which requires evaluation errors to be flagged as Incomplete/Unknown — never as Not Applicable

Implementation Points

Component Behaviour
_map_state() Unrecognised OSCAL status.state values → ERROR (with warning log). Explicit "not-applicable" / "na" → NOT_APPLICABLE.
_finding_to_state() ERROR findings emit OSCAL state "error", not "not-applicable".
findings_from_metrics_dict() Langfuse fetch failures ({"error": "..."}) emit an ERROR OscalFinding with a descriptive remarks field. They are not silently dropped.
_step4_alert_on_critical_fail() Critical-control filter matches result ∈ {FAIL, ERROR}. A scanner failure on SC-4, A.9.2, or A.8.4 triggers the same Slack/PagerDuty alert as an explicit FAIL.
_ingest_sync() ERROR findings score 0.0 in Langfuse — identical to FAIL. They are never scored as 1.0 (PASS).

5.4 Compliance Bridge API Endpoints (v2.0.0-rc.1)

CAGE v2.0.0 adds four new REST endpoints to the Compliance Bridge (src/compliance_bridge/main.py):

Endpoint Method Description
/v1/aarm/conformance-report GET Returns the AARM 11-vector conformance report card (JSON/YAML). Supports optional vLLM narrative enrichment (11 concurrent calls, asyncio.Semaphore(3) rate cap).
/v1/defer/pending GET Lists all currently parked DEFER queue tokens with their DeferReason, confidence_score, and TTL remaining.
/v1/defer/{id}/inject POST Resolves a deferred token via automated data injection — body carries supplementary context data. Token status transitions to INJECTED.
/v1/defer/{id}/escalate POST Manually escalates a deferred token to MANUAL_REVIEW. Token status transitions to ESCALATED.

These complement the existing POST /v1/audit/ingest and GET /v1/events/stream (SSE) endpoints.

6. OSCAL Artifact Inventory

Source: compliance/oscal/

CAGE maintains its compliance artifacts in OSCAL v1.0.4 format to enable machine-readable, interoperable security documentation. The current artifact inventory is:

File Type Status
compliance/oscal/component-definition.yaml Component Definition (OSCAL v1.0.4) 3 components, 4 controls defined
compliance/oscal/system-security-plan.yaml System Security Plan Stub — Critical gap (POAM-015)
compliance/oscal/sp800-53-component-definition.yaml SP 800-53 Component Definition Present
compliance/oscal/sp800053-profile.yaml SP 800-53 Profile Present
compliance/oscal/common-controls-catalog.yaml Common Controls Catalog Present
compliance/oscal/information-type-registry.yaml Information Type Registry Present

SSP Gap (FIND-013 / POAM-015): No complete System Security Plan exists. The compliance/oscal/system-security-plan.yaml file is a stub with placeholder content. Severity: HIGH. Status: Open. A complete SSP is a prerequisite for ATO submission.

OSCAL Artifact Persistence and KMS Batch Signing

OSCAL Assessment Result artifacts are persisted to GCS using the native google-cloud-storage>=2.0.0 SDK (primary) with boto3>=1.35.0 S3-compatible fallback. Each artifact batch is signed using Cloud KMS HSM-backed asymmetric signing before persistence, providing tamper-evident audit evidence:

  • Signing: RSA-PKCS1-4096-SHA256 via KMSSigner — private key never leaves the HSM
  • Verification: Sub-millisecond local RSA verification using embedded public key PEM
  • Audit trail: Google Cloud Audit Logs provide an immutable record of every signing operation
  • Compliance: Satisfies FINRA Rule 4511 tamper-evident records requirement and ISO 42001 §A.7.5 records integrity

Automated Multi-Jurisdiction SSP Exporter

To accelerate compliance authoring across different jurisdictions, CAGE includes an automated compliance narrative compiler: src/gateway/governance/oscal_ssp_exporter.py.

This tool dynamically compiles STPA hazards (UCAs) and control implementations into OSCAL System Security Plans. It provides a --framework CLI parameter to dynamically generate the control cross-walk narrative targeted at different international authorities:

  • EU AI Act: python -m src.gateway.governance.oscal_ssp_exporter export --framework EU_AI_ACT
  • Singapore MAS FEAT: python -m src.gateway.governance.oscal_ssp_exporter export --framework MAS_FEAT
  • ISO/IEC 42001: python -m src.gateway.governance.oscal_ssp_exporter export --framework ISO42001
  • NIST SP 800-53 (Default): python -m src.gateway.governance.oscal_ssp_exporter export --framework NIST

7. Lula Validation Manifests

Three-Region Compliance Matrix

CAGE ships validation manifests for all three regulatory jurisdictions located flat within compliance/lula/. The manifests are parametrized in CI via a pytest matrix that runs all three regions in parallel:

Jurisdiction Manifest Selector / Pattern Threshold Config OSCAL Framework
US_FED compliance/lula/lula-validation-{sc4,sc7,ac2,ac3,ra5,cm6,ir6,ia3,ia5,sc8,si2,cilium-dpv2}.yaml config/thresholds/US_FED_BASELINE.json NIST SP 800-53 Rev 5
EU_ECB compliance/lula/lula-validation-{eu-ai-act-art9,eu-fria,gdpr-art22,dora-art10}.yaml config/thresholds/EU_ECB_BASELINE.json EU AI Act + DORA
APAC_MAS compliance/lula/lula-validation-{mas-feat,mas-notice655,mas-trm-s6}.yaml config/thresholds/APAC_MAS_BASELINE.json MAS FEAT + TRM

Each manifest set covers the same control families but with jurisdiction-specific thresholds, telemetry suppression rules (EU_ECB/APAC_MAS suppress SR 26-2 telemetry per the "no legal force" sentinel), and OSCAL framework routing.

Source: compliance/lula/

Lula automates OSCAL Assessment Result generation on a 6-hour CronJob schedule (deployment/k8s/lula-cron.yaml). RBAC permissions are defined in deployment/k8s/lula-rbac.yaml.

Active manifests listed below (representative excerpt) — for the complete 31-manifest active inventory (plus draft validations), see compliance/lula/README.md.

Manifest Control Kubernetes Check
compliance/lula/lula-validation-a52.yaml ISO 42001 A.5.2 Social impact assessment ConfigMap
compliance/lula/lula-validation-a53.yaml ISO 42001 A.5.3 Documentation/logging config
compliance/lula/lula-validation-a92.yaml ISO 42001 A.9.2 PII detection Deployment
compliance/lula/lula-validation-sc4.yaml SP 800-53 SC-4 Information in shared resources
compliance/lula/lula-validation-au12.yaml SP 800-53 AU-12 Langfuse OTLP ingestion availability (direct; OTel Collector deprecated 2026-05-31)
compliance/lula/lula-validation-ac2.yaml SP 800-53 AC-2 Account management / service account lifecycle
compliance/lula/lula-validation-ac3.yaml SP 800-53 AC-3 Access enforcement / OPA RBAC
compliance/lula/lula-validation-ra5.yaml SP 800-53 RA-5 Vulnerability scanning (pip-audit / Trivy CI)
compliance/lula/lula-validation-cm6.yaml SP 800-53 CM-6 Configuration settings enforcement
compliance/lula/lula-validation-ir6.yaml SP 800-53 IR-6 Incident reporting
compliance/lula/lula-validation-ia3.yaml SP 800-53 IA-3 Device identification / Linkerd mTLS SPIFFE identity (POAM-007,POAM-011)
compliance/lula/lula-validation-ia5.yaml SP 800-53 IA-5 / SC-12 Authenticator management / KMS HSM key lifecycle (docs/operations/KEY_ROTATION.md)
compliance/lula/lula-validation-sc8.yaml SP 800-53 SC-8 Transmission confidentiality / TLS enforcement (tests/test_tls_enforcement.py)
compliance/lula/lula-validation-si2.yaml SP 800-53 SI-2 Flaw remediation / CVE patching (pinned images, base image upgrades)
compliance/lula/lula-validation-aarm-vectors.yaml CSA AARM v1.0 11-vector AI agent threat model coverage
compliance/lula/lula-validation-ftra.yaml OWASP AISVS C9 FTRA action reachability registry integrity & fail-closed gate
compliance/lula/lula-validation-tqp007.yaml POAM-007 / IA-3 Linkerd mTLS strict mode assertion across pods
compliance/lula/lula-validation-iso001-token-quota.yaml ISO 42001 A.8.4 Gateway token quota limit & rate limiting enforcement
compliance/lula/lula-validation-flowsignal.yaml SP 800-53 SI-4 Signal flow integrity & CBF backpressure queue validation
compliance/lula/lula-validation-cilium-dpv2.yaml SP 800-53 SC-7 GKE Dataplane V2 / Cilium anetd DaemonSet readiness — boundary protection via eBPF L7 network policy (deployment/k8s/cilium/)

7.1 Lula Stub Manifest Gate & Baseline

To prevent mock or placeholder manifests from quietly passing validation without asserting live Kubernetes resources, CAGE enforces an automated stub manifest gate via scripts/check_lula_stub_count.py:

  • Stub Classification: A manifest is classified as a stub if its Rego contains default allow = true without substantive conditions, its domain.resources list is empty, its description contains TODO/STUB/placeholder, or the Rego rule body has fewer than 3 meaningful logic lines.
  • POAM Linkage: Every stub manifest must be tracked by an active finding in docs/POAM.md.
  • Baseline Ratchet: The total stub manifest count cannot exceed the baseline recorded in compliance/lula/.stub-baseline (currently 1). If a PR introduces an untracked stub or causes the stub count to exceed the baseline, the CI gate fails.

8. Information System Continuous Monitoring (ISCM) Strategy

Source: compliance/continuous-monitoring/ISCM_STRATEGY.md

8.1 Two-Tier Monitoring Architecture

CAGE implements a two-tier ISCM strategy balancing compliance cycle frequency with real-time operational visibility:

Tier 1 — Compliance Cycle (6-hour frequency):

  • Lula CronJob generates OSCAL Assessment Results
  • Compliance Bridge ingests results via POST /v1/audit/ingest
  • run_audit_workflow scores compliance posture
  • Langfuse records compliance scores as evaluation traces
  • SSE alerts surface open findings to operators

Tier 2 — Operational Real-Time (60-second frequency):

  • SC-4 OPA policy watch with continuous enforcement
  • Continuous OTel span streaming from all agent nodes
  • AgentSight eBPF DaemonSet capturing kernel-level agent activity

8.2 Evidence Age Tracking

The ComplianceMetrics model in src/compliance_bridge/types.py includes an evidence_age_seconds field that tracks the staleness of each compliance assertion. A 6-hour startup grace period is enforced before the system raises evidence-age alerts, allowing the first Lula cycle to complete after deployment.

9. Privacy Impact Assessment

Source: compliance/pia/PRIVACY_IMPACT_ASSESSMENT.md

The PIA identified eight privacy risks (PR-1 through PR-8) associated with LLM-based financial AI processing:

Risk ID Risk Residual Risk Control
PR-1 PII in LLM prompts MODERATE NeMo input scan; Presidio masking
PR-2 Audit log over-retention LOW 90-day raw AI logs; 7-year redacted
PR-3 Unauthorized data access LOW OPA RBAC; NetworkPolicy
PR-4 Market data linkage LOW Pseudonymization
PR-5 Third-party data exposure LOW yfinance read-only; ISA agreement
PR-6 Intra-cluster plaintext LOW FIND-011 resolved; Linkerd mTLS deployed
PR-7 Session token exposure LOW ≤8-hour token lifetime
PR-8 Residual data in models LOW vLLM stateless inference

PR-1 remains at MODERATE residual risk pending MFA deployment. PR-6 has been reduced to LOW following Linkerd mTLS deployment (POAM-007 closed 2026-05-17).

9.1 Data Retention Schedule

Data Category Retention Period Regulatory Driver
Audit logs 7 years FINRA Rule 4511; SEC Rule 17a-4
AI interaction logs (raw) 90 days Operational; privacy minimization
AI interaction logs (redacted) 7 years FINRA Rule 4511
Session tokens ≤ 8 hours SEC Reg S-P; GLBA
PII in prompts 24-hour session limit GLBA; SEC Reg S-P

10. Security Assessment Report (SAR-CAGE-2026Q1)

Source: compliance/sar/SAR_2026Q1.md

Overall Risk Determination: HIGH

The security assessor does NOT recommend ATO at this time. An Interim ATO (IATO) is possible only if the remaining Critical finding (FIND-007) is resolved prior to submission. The finding register is:

Finding ID Description Severity Status POAM
FIND-010 HMAC routing seal bypass Critical RESOLVED POAM-012 Closed
FIND-011 No intra-cluster mTLS Critical RESOLVED POAM-007 Closed
FIND-007 FIPS 199 categorization unsigned Critical In-Progress POAM-009
FIND-001 No account management procedures High Open —
FIND-003 Mock audit traces in production path High Open POAM-003
FIND-006 No Incident Response Plan (IRP) High Open —
FIND-008 No vulnerability scanning High RESOLVED POAM-010 Closed
FIND-013 No complete System Security Plan High Open POAM-015
FIND-014 No ATO authorization letter High Open POAM-005

FIND-010 and FIND-011 are resolved Critical findings: HMAC seal integrity was hardened (FIND-010), and intra-cluster mTLS was deployed via Linkerd with Cilium L7 egress lockdown (FIND-011). FIND-008 (vulnerability scanning) is resolved via the security-scan.yml CI pipeline implementing pip-audit, Trivy, Grype, and CycloneDX SBOM generation.

CVE-2025-69872 Remediation (outlines Package Removal)

The outlines Python package was removed from all CAGE images following the discovery of CVE-2025-69872 (critical severity). Structured output enforcement is now handled natively by vLLM's FSM (Finite State Machine) guided decoding, which provides equivalent ExecutionPlan schema compliance without the vulnerable dependency.

Attribute Value
CVE CVE-2025-69872
Severity Critical
Affected Package outlines
Remediation Package removed; vLLM FSM guided decoding used instead
NIST Control SI-2 (Flaw Remediation)
Lula Validation compliance/lula/lula-validation-si2.yaml — flaw remediation CronJob
Status RESOLVED

11. Risk Assessment

Source: compliance/rar/RISK_ASSESSMENT_REPORT.md

CAGE's current overall risk posture is assessed as HIGH based on four compounding risk drivers:

  1. Missing Authentication Controls: No multi-factor authentication is deployed. Operator accounts rely on single-factor credentials. No formal account management procedures exist (FIND-001). This directly fails SP 800-53 IA-2, IA-4, and IA-12.

  2. No Intra-Cluster Transport Encryption: RESOLVED. Linkerd mTLS proxy injection is active in the governance-stack namespace, encrypting all service-to-service traffic. POAM-007 closed 2026-05-17.

  3. Incomplete Authorization Package: The authorization package stands at 24% completion. Without a complete SSP, POA&M, and signed FIPS 199, the Authorizing Official cannot make an informed risk-based authorization decision.

  4. eBPF Monitoring Console-Only: RESOLVED. The AgentSight eBPF DaemonSet exporter has been updated to "remote" mode, exporting to http://agentsight-dashboard:8080 for centralized collection.

12. Governance Threshold Traceability

Source: compliance/risk_acceptance/THRESHOLD_TRACEABILITY_MATRIX.md

All 22 governance thresholds defined in config/governance_thresholds.json are formally traced to specific regulatory controls in the Threshold Traceability Matrix. Four thresholds carry formal documented risk acceptances:

ID Accepted Risk Rationale Regulatory Linkage
RA-001 1% OTel sampling rate Compensated by 100% governance event logging AU-12
RA-002 $10k single-agent consensus threshold Amounts below threshold acceptable without multi-agent consensus SR 26-2 §IV.B Agentic MRM
RA-003 Daily SBOM generation vs. per-build deployment/k8s/sbom-cronjob.yaml daily automation accepted as compensating control CM-3, SA-12
RA-004 Single OPA node + circuit breaker 5-failure circuit breaker enforces DENY-on-open posture SC-4, AC-3

Each risk acceptance was reviewed and signed by the system owner and is referenced directly in the OSCAL Component Definition.

13. Software Bill of Materials (SBOM)

Sources: compliance/sbom/README.md; scripts/generate_sbom.py

CAGE produces a Software Bill of Materials to satisfy supply chain risk management requirements under SP 800-53 SA-12 and SR 26-2 model inventory obligations.

Attribute Value
Generation script scripts/generate_sbom.py
Automation deployment/k8s/sbom-cronjob.yaml — daily scheduled generation
Format SPDX / CycloneDX (see compliance/sbom/README.md)
Risk acceptance RA-003 — daily generation accepted vs. per-build (documented)

The daily generation cadence was accepted under RA-003 as a compensating control. Per-build SBOM generation remains the target state and is tracked in the POAM roadmap as a Phase 1 quick-win item.

14. Compliance Posture Summary

The table below consolidates the current compliance posture across all targeted frameworks:

Framework Posture Active Region(s) Blocking Gap
NIST SP 800-53 Rev 5 (HIGH) 24% implemented US_FED No MFA, no SSP
NIST RMF (Steps 1–7) 28–22/100 per step US_FED No ATO; authorization package incomplete
FIPS 199 Categorized; unsigned US_FED FIND-007 / POAM-009
FIPS 140-2/3 HMAC-SHA256 implemented All Regions FIPS-validated module validation pending
ISO/IEC 42001:2023 Clauses 6, 8, 9, 10 mapped All Regions Evidence artifacts incomplete for Clause 9
OSCAL v1.0.4 Artifacts present; SSP stub All Regions FIND-013 / POAM-015
FINRA Rule 4511 7-year retention pipeline implemented US_FED Audit log production pipeline not validated
SEC Rule 17a-4 Electronic records design complete US_FED WORM storage not yet enforced
SEC Reg S-P PII controls implemented US_FED PR-1, PR-6 at MODERATE residual
GLBA Privacy controls partial US_FED mTLS gap (PR-6) Resolved
SR 26-2 Agentic model risk — 4 gaps closed US_FED All four gaps closed
EU AI Act (Reg. 2024/1689) High-Risk AI controls mapped (6 CTRLs) EU_ECB FRIA attestation logging only; no EU AI Office registration
DORA (Reg. 2022/2554) ICT resilience controls mapped EU_ECB Full DORA compliance testing pending
GDPR Article 22 Automated decision-making constraints EU_ECB DPIA integration pending
EBA Guidelines (2023/02) Internal model governance mapped EU_ECB ECB SSM TRIM validation pending
MAS FEAT Principles FEAT controls mapped (5 CTRLs) APAC_MAS Fairness Impact Assessment quantitative metrics pending
MAS TRM Guidelines TRM §6.3/6.4 AI controls mapped APAC_MAS MAS Notice 655 audit certification pending
ISO-20022 Transaction message format; 200 ms latency is an operational infrastructure requirement of real-time interbank rails (FedNow / SEPA Instant), not an ISO-20022 mandate All Regions SLA validation testing not complete
CSA AARM v1.0 11 threat vectors assessed All Regions 4 vectors at PARTIAL status

14b. AARM Profile Mapper and Evidence Chain (v2.1.0)

AARM Profile Mapper (src/compliance_bridge/aarm_mapper.py)

The AARM Profile Mapper translates CAGE governance decisions into the 11-vector AARM (AI Assurance and Risk Management) threat ledger format. Each vector maps to a specific CAGE control:

AARM Vector CAGE Control Implementation
V1 — Context Accumulation AARM-V1 context accumulator src/governed_financial_advisor/graph/nodes/
V2 — Confabulation Risk Confabulation scorer src/gateway/governance/confabulation_scorer.py
V3 — Prompt Injection Prompt injection detector src/gateway/governance/prompt_injection_detector.py
V4 — PII Leakage PII sanitizer src/gateway/governance/pii_sanitizer.py
V5 — CBRN Exposure NeMo CBRN rail src/gateway/governance/nemo/colang/cbrn_rails.co
V6 — Fiscal Limit Breach FiscalLimitGuard + CBF src/gateway/governance/safety/resource_guard.py & src/gateway/governance/safety/cbf_engine.py
V7 — Confidence Starvation DEFER state machine src/gateway/governance/defer_queue.py
V8 — Causal Boundary Violation DoWhy causal gatekeeper src/gateway/governance/causal/gatekeeper.py
V9 — Consensus Failure ConsensusModelRegistry src/gateway/governance/consensus/engine.py
V10 — HITL SLA Breach HITL escalator + DeferQueue TTL src/gateway/governance/hitl_escalator.py
V11 — Provenance Chain Break Provenance chain src/gateway/governance/provenance_chain.py

The AARM report generator (src/compliance_bridge/aarm_report_generator.py) produces AARM-format compliance reports from the 11-vector ledger for submission to regulatory reviewers.

Evidence Chain Metadata Binding & Durability Preconditions (src/gateway/governance/evidence/stream.py)

The evidence stream module binds governance decision metadata to OSCAL evidence artifacts at the point of creation, enforcing strict durability guarantees. Each evidence record includes:

  • thread_id — LangGraph thread identifier (links evidence to the originating inference trace)
  • control_id — NIST SP 800-53 / ISO 42001 control identifier
  • decision — PASS | FAIL | NOT_APPLICABLE | ERROR
  • governance_signature — KMS-signed (production) or HMAC-SHA256 (dev/CI)
  • deployment_region — US_FED | EU_ECB | APAC_MAS
  • langfuse_trace_id — OTLP trace ID for cross-referencing in Langfuse
  • record_hash — SHA-256 digest of the canonical evidence payload, folded into HMAC Routing Seal v2 <expire_hex>.<action_slug>.<record_hash_hex>.<hmac_hex>

Durability Preconditions (validate_evidence_stream_preconditions()): In production (CAGE_ENV=production or CAGE_REQUIRE_BLOCKING_EVIDENCE=true), the system halts at startup if the evidence stream is disabled or configured in non-blocking mode, ensuring no governance approval can proceed without guaranteed persistence to the WORM audit store.

Evidence records are streamed to the OSCAL exporter (src/compliance_bridge/oscal_exporter.py) and archived to the GCS WORM bucket for 7-year retention.

15. Multi-Jurisdiction Compliance Engine

CAGE v2.0.0 introduced a multi-jurisdiction compliance engine that allows the system to seamlessly shift its entire regulatory compliance posture between United States, European Union, and Singapore regulatory environments without any code changes. This section documents the architecture, configuration, and operational behavior of the multi-jurisdiction system.

15.1 Activation Mechanism

The active jurisdiction is determined by a single environment variable:

CAGE_DEPLOYMENT_REGION=US_FED | EU_ECB | APAC_MAS

Setting this variable at boot time triggers cascading configuration changes across three independent subsystems:

Subsystem Configuration Source Effect
Compliance Control Profiles config/compliance/{REGION}_BASELINE.json Activates region-specific regulatory control mappings (primary framework, co-frameworks, legacy citations) for all 5–6 CAGE governance controls
Governance Thresholds config/thresholds/{REGION}_BASELINE.json Loads region-calibrated numeric thresholds (confidence, drawdown, consensus, latency, portfolio limits, FRIA parameters)
OSCAL Framework Routing config/oscal/framework_mappings/*.json Routes UCA-to-control cross-walk narratives to the correct international standard for SSP generation

15.2 Supported Jurisdictions

United States (US_FED)

Attribute Value
Primary Prudential Authority Federal Reserve / OCC / FDIC (Joint Agency)
Primary AI Framework SR 26-2 (Model Risk Management for Agentic AI)
Legacy MRM Framework SR 11-7 (superseded by SR 26-2 for agentic components)
Cyber Baseline NIST SP 800-53 Rev 5 HIGH
Financial Privacy SEC Reg S-P, GLBA, FINRA Rule 4511
Compliance Profile config/compliance/US_FED_BASELINE.json (5 controls)
Threshold Profile config/thresholds/US_FED_BASELINE.json
Key Differentiator SR 26-2 Footnote 3 novelty exclusion — agentic AI is explicitly excluded from traditional MRM scope; governed under ISO 42001

European Union (EU_ECB)

Attribute Value
Primary Prudential Authority European Central Bank (SSM) / EBA / EU AI Office
Primary AI Framework EU AI Act (Regulation (EU) 2024/1689) — High-Risk AI System per Art. 6 + Annex III §5(b)
Additional Frameworks DORA (Arts. 5, 10, 11, 12), GDPR (Arts. 5, 22, 35), EBA/GL/2023/02, BCBS 239
Compliance Profile config/compliance/EU_ECB_BASELINE.json (6 controls — includes CTRL_FRIA_006)
Threshold Profile config/thresholds/EU_ECB_BASELINE.json
Key Differentiators (1) Mandatory Step 8 Fundamental Rights Impact Assessment (Art. 29a); (2) SR 26-2 telemetry suppression; (3) Stricter thresholds across all governance tiers; (4) Additional Tier 1 keywords (GDPR OVERRIDE, IGNORE FAIRNESS CHECKS, BYPASS FRIA)

Singapore / APAC (APAC_MAS)

Attribute Value
Primary Prudential Authority Monetary Authority of Singapore (MAS)
Primary AI Framework MAS FEAT Principles (Fairness, Ethics, Accountability, Transparency)
Additional Frameworks MAS Notice 655, MAS TRM Guidelines (§6.3, §6.4), MAS ENRM Guidelines
Compliance Profile config/compliance/APAC_MAS_BASELINE.json (5 controls)
Threshold Profile config/thresholds/APAC_MAS_BASELINE.json
Key Differentiator MAS FEAT Fairness Principle F2 requires quantitative fairness metrics (demographic parity, equalized odds) — mapped to DoWhy causal gatekeeper validation

15.3 Region-Specific Threshold Calibration

Governance thresholds are calibrated independently per jurisdiction to reflect local regulatory expectations. Key threshold differences:

Threshold US_FED EU_ECB APAC_MAS Regulatory Rationale
Min. Agentic Confidence 0.95 0.97 0.95 EU AI Act Art. 9 mandates stricter risk management for High-Risk AI
Drawdown Limit 5% 4% 5% EBA stress-test adverse scenario (EBA/GL/2018/02)
UCA-5 Drawdown Threshold 4.5% 3.5% 4.5% 1% more conservative cushion for EBA Pillar 2 Requirement triggers
Max Order Volume Fraction 1% 0.5% 1% MiFID II market integrity / MAR Art. 12 slippage controls
Max Portfolio Sell Fraction 10% 8% 10% ESMA MiFID II best execution requirements
Max Latency (ms) 200 150 200 DORA Art. 10 operational resilience — ECB SSM lower tolerance
Consensus Threshold (USD) $10,000 $7,500 $5,000 GDPR Art. 22 automated decision-making; MAS FEAT A1 human oversight
CBF Gamma (decay) 0.5 0.6 0.5 CRD VI / EBA SREP capital buffer maintenance
FRIA Enabled No Yes No EU AI Act Art. 29a — no US/SG equivalent

15.4 ControlRegistry Architecture

The ControlRegistry class (src/gateway/governance/constants.py) is the runtime component that loads and serves regional compliance profiles:

  • Dynamic Loading: At startup, reads CAGE_DEPLOYMENT_REGION and loads the corresponding config/compliance/{REGION}_BASELINE.json
  • Thread-Safe Access: Provides get_mapping(control_id) and get_mapping_safe(control_id) methods for safe access to region-specific control metadata
  • Graceful Degradation: get_mapping_safe() returns None for controls that don't exist in the active region (e.g., CTRL_FRIA_006 is only present in EU_ECB), preventing KeyError exceptions in non-EU deployments
  • Active Region Attribute: Exposes active_region for span tagging and audit attribution

15.5 SR 26-2 Telemetry Suppression

When CAGE operates under the EU_ECB profile, US-specific regulatory citations must not appear in audit telemetry. This is implemented via a data-driven sentinel mechanism in the Causal Gatekeeper (src/gateway/governance/causal/gatekeeper.py):

  1. Each regional profile's CTRL_MRM_004 entry includes a legacy_citation field
  2. The EU profile encodes: "SR 26-2 §IV (US Federal Reserve — no legal force in EU jurisdiction)"
  3. At runtime, the gatekeeper checks for the "no legal force" sentinel marker
  4. When detected, it emits primary_framework (the jurisdiction-correct citation, e.g., EBA/GL/2023/02) on OTel spans instead of the US-specific SR 26-2 string
  5. The APAC profile similarly flags its SR 26-2 legacy citation as having no legal force in Singapore

This mechanism is fully data-driven — adding a new region that suppresses SR 26-2 requires only a JSON profile update with the sentinel marker. No Python changes are needed.

15.6 EU-Specific: Fundamental Rights Impact Assessment (Step 8)

The EU_ECB profile activates an additional governance step — Step 8: FRIA Attestation — that executes after the 7 fail-closed governance tiers (0–6). This step:

  • Is triggered only when CAGE_DEPLOYMENT_REGION=EU_ECB
  • Reads CTRL_FRIA_006 from the EU compliance profile (Art. 29a attestation)
  • Stamps FRIA compliance attestation as OpenTelemetry span attributes
  • Records protected characteristics assessment (gender, race, ethnicity, age, disability, nationality, religion)
  • Enforces demographic parity and equalized odds thresholds (5% tolerance per EBA/GL/2020/06)
  • Is non-blocking (attestation stamp, not a fail-closed gate) — this is why it is designated "Step 8" rather than "Tier 7"
  • Requires periodic reassessment (365-day interval per Art. 29a)

15.7 OSCAL Framework Router

Implementation Status: The Multi-jurisdiction SSP Router described in this section has been fully implemented in src/gateway/governance/oscal_ssp_exporter.py (previously described as "designed but not implemented"). The FrameworkRouter class and its CLI export interface are production-ready as of CAGE v2.2.0.

The FrameworkRouter class (src/gateway/governance/oscal_ssp_exporter.py) enables automated SSP generation targeted at different international authorities. It loads external JSON routing tables from config/oscal/framework_mappings/ and maps STPA Unsafe Control Actions (UCAs) to jurisdiction-specific control identifiers:

Framework ID JSON Routing Table Target Authority
NIST NIST_SP800_53.json NIST / FedRAMP (US)
ISO42001 ISO_42001.json ISO (Global)
EU_AI_ACT EU_AI_ACT.json EU AI Office / EBA
MAS_FEAT MAS_FEAT.json MAS (Singapore)

Usage:

# Generate EU AI Act SSP narrative
python -m src.gateway.governance.oscal_ssp_exporter export --framework EU_AI_ACT

# Generate MAS FEAT SSP narrative
python -m src.gateway.governance.oscal_ssp_exporter export --framework MAS_FEAT

Adding a new jurisdiction requires only a new JSON file in the mappings directory and a one-line entry in _FRAMEWORK_FILE_MAP — zero changes to the SSP generation logic.

15.8 Extensibility: Adding a New Jurisdiction

To add a new regulatory jurisdiction (e.g., UK_FCA for the UK Financial Conduct Authority), the following config-only steps are required:

Step File to Create/Modify Purpose
1 config/compliance/{REGION}_BASELINE.json Define 5–6 control mappings with primary_framework, co_frameworks, legacy_citation, scope
2 config/thresholds/{REGION}_BASELINE.json Calibrate numeric governance thresholds to local regulatory expectations
3 config/oscal/framework_mappings/{FRAMEWORK}.json Create UCA-to-control routing table for OSCAL SSP generation
4 _FRAMEWORK_FILE_MAP in oscal_ssp_exporter.py Register the new framework ID (one line)

No Python code changes are required for steps 1–3. The ControlRegistry, SymbolicGovernor, CausalGatekeeper, and FrameworkRouter all dynamically load regional configuration from these JSON files at runtime.

16. Mathematical Safety Controls

This section formalises the mathematical safety invariants that underpin CAGE's compliance posture. All constants are sourced from config/governance_thresholds.json and the named constants in the respective source modules.

16.1 Control Barrier Function (CBF) — ISO 42001 A.8.4

Source: src/gateway/governance/safety/cbf_engine.py

The Control Barrier Function enforces the core financial safety invariant using control theory formalism. The safe set S and barrier function h are defined as:

Safe set:        S = {x ∈ ℝⁿ : h(x) ≥ 0}
Barrier function: h(x) = cash_balance − min_cash_balance

The discrete-time CBF condition that must hold at every governance step is:

h(S(t+1)) ≥ (1−γ) · h(S(t))     where γ ∈ (0,1)
Parameter Value Source
min_cash_balance 1000.0 cbf.min_cash_balance in governance_thresholds.json
γ (decay rate) 0.5 (US_FED/APAC_MAS), 0.6 (EU_ECB) cbf.gamma — region-calibrated

The CBF is enforced atomically via a single-round-trip Redis Lua script (atomic_verify_and_commit(), with fallback to Redis WATCH/MULTI/EXEC on contention). A violation of h(x) ≥ 0 raises GovernanceError immediately (fail-closed). The CBF is re-evaluated at execution time by post_hitl_revalidate_node using the fresh live price to prevent TOCTOU exploits.

ISO 42001 mapping: A.8.4 (AI System Operation Controls — runtime safety invariant enforcement).

16.2 FRIA Zone Thresholds

The Adaptive FRIA Gate (Tier 6b) maps model confidence to three decision zones. These constants are defined in src/gateway/governance/symbolic_governor.py:

Constant Value Zone Compliance Mapping
FRIA_ZONE_ALLOW 0.95 confidence ≥ 0.95 → autonomous clearance ISO 42001 A.8.4; EU AI Act Art. 29a (EU_ECB)
FRIA_ZONE_DEFER 0.70 0.70 ≤ confidence < 0.95 → synchronous FRIA gate CSA AARM V7; ISO 42001 A.8.4
(implicit deny) < 0.70 confidence < 0.70 → Confidence-Starvation Boundary ISO 42001 A.8.4; CSA AARM V7

16.3 Fiscal Limit Guard — ISO 42001 A.8.4 / SC-4

Source: src/gateway/governance/safety/resource_guard.py

The FiscalLimitGuard (and ResourceGuard.reserve()) enforces a hard daily spending cap to prevent race conditions where parallel agent threads collectively exceed the authorized limit:

Parameter Value Notes
Daily cap $500,000 USD Configurable via FISCAL_DAILY_CAP_USD env var
Cap storage Integer cents Prevents floating-point precision errors
Window 86,400 seconds Rolling 24-hour window
Retry strategy Exponential backoff: _RETRY_BASE_MS × 2^attempt Redis WATCH/MULTI/EXEC contention handling
Reservation TTL 300 seconds Reclaims limits from crashed nodes automatically

Headroom is pre-reserved in Redis after concurrent CBF+OPA validation (closing the TOCTOU race). Unused limits are returned via release(token) on Saga rollback. If Redis is unavailable, the trade is blocked (fail-closed).

ISO 42001 mapping: A.8.4 (AI System Operation Controls); [US_FED only] NIST SP 800-53 SC-4 (Information in Shared Resources).

16.4 Cryptographic Routing Seal (v3 JWT with KMS HSM Signing)

Source: src/gateway/governance/routing_seal.py

Every approved governance decision is sealed with a cryptographic routing seal before execution is permitted. In production (v3), the routing seal is an asymmetric JWT signed by Cloud KMS HSM (iss="cage-governance-kernel", aud="cage-execution-engine", exp, act, ehash) that cryptographically binds the decision to the compliance evidence stream record_hash. In local/test environments without KMS, it falls back to a 4-tuple HMAC token:

<expire_ts_hex>.<action_slug>.<record_hash_hex>.<hmac_hex>
Field Description
expire_ts_hex Hex-encoded Unix timestamp of seal expiry
action_slug URL-safe slug identifying the governed action
record_hash_hex Hex-encoded SHA-256 binding to the compliance evidence record
hmac_hex HMAC-SHA256 hex digest over payload (dev/test fallback)
Parameter Value Notes
TTL 30 seconds Seals expire 30s after issuance; prevents replay attacks
Algorithm RS256/ES256 (KMS HSM) / HMAC-SHA256 (dev fallback) FIPS-approved; constant-time comparison for HMAC verification
Secret / Key Cloud KMS HSM key URI / CAGE_ROUTING_SEAL_SECRET KMS key in prod; ≥ 64 characters required for HMAC fallback

The seal is verified by src/gateway/server/governance_middleware.py before any trade execution. A missing, expired, or invalid seal returns HTTP 401 (fail-closed). This satisfies the NoDirectBind invariant: there is no code path from CHECKING to EXECUTED that bypasses SEAL_ISSUED.

ISO 42001 mapping: A.7.5 (Records Integrity — cryptographic seal on every governance approval).

16.5 8-Tier Symbolic Governor Pipeline Reference

The full mathematical pipeline is documented in Document 05 — AI Governance & Policy Engine §16. The pipeline enforces the following invariant chain in strict sequential order:

STPA UCAs (Tier 0)
  → Confidence ≥ threshold (Tier 1)
    → h(S(t+1)) ≥ (1−γ)·h(S(t)) [CBF] (Tier 2)
      → OPA Rego ALLOW (Tier 4)  ← concurrent with Tier 2 via asyncio.gather
        → Consensus (amount ≤ threshold OR unanimous APPROVE) (Tier 5)
          → (0.5 + estimate.value × amount) ≤ 0.95 [Causal] (Tier 6)
            → FRIA zone check (Tier 6b)
              → SEAL_ISSUED → EXECUTED

All tiers are fail-closed. A violation at any tier raises GovernanceError and prevents execution. The routing seal (§16.4) is issued only after all tiers pass, satisfying the NoDirectBind formal invariant verified in proof/model.py.

17. Evidence Cold Storage and Regional Residency

Source: src/gateway/governance/evidence/cold_store.py, src/gateway/governance/evidence/residency.py

New in v3.0.0 — The evidence cold store subsystem provides vendor-agnostic durable evidence archival to cloud object storage (GCS, S3, or adopter-supplied backends) with strict regional data residency enforcement.

17.1 Layer 1 Protocol Design

EvidenceColdStore is a runtime-checkable Protocol defining the vendor-neutral seam for async cold storage. The kernel defines only the abstract contract; concrete implementations live strictly in Layer 3 integrations (src/integrations/storage_gcs/, src/integrations/storage_s3/).

Layer Invariant: cold_store.py contains zero vendor imports (no google-cloud-storage, boto3, or azure-storage-blob). This enforces the kernel/plugin boundary and ensures vendor SDKs cannot leak into the governance kernel.

17.2 Protocol Contract

Method Purpose Fail-Closed Behavior
put_batch(key, content, metadata) Persist content bytes to cold storage Raises ColdStoreError on network/auth/I/O failure
exists(key) Check object existence Raises ColdStoreError on connectivity/permission errors
put_if_absent(key, content, metadata) Atomic conditional write (only if key does not exist) GCS: uses if_generation_match=0; S3: uses conditional headers
health() Synchronous backend health check Returns ColdStoreHealth with available flag and diagnostic detail

17.3 ColdStoreReceipt — Immutable Persistence Proof

ColdStoreReceipt is an immutable dataclass returned on successful write, providing cryptographic proof of persistence:

@dataclasses.dataclass(frozen=True)
class ColdStoreReceipt:
    uri: str  # gs://bucket/key or s3://bucket/key
    key: str  # Object path within bucket
    content_sha256: str  # Hex SHA-256 digest over persisted bytes
    backend_id: str  # 'gcs', 's3', 'null'
    written_at: datetime  # UTC timestamp of confirmed write

The content_sha256 field enables verification that the stored artifact matches the in-memory evidence batch byte-for-byte, closing the gap between evidence accumulation and durable archival.

17.4 Regional Data Residency Enforcement

src/gateway/governance/evidence/residency.py + config/compliance/residency.json implement jurisdictional data residency controls mandated by GDPR Article 44, MAS TRM §4.2, and NIST SP 800-53.

Residency Mapping (per CAGE_DEPLOYMENT_REGION):

Region Allowed Storage Locations Compliance Framework
US_FED us-central1, us-east1, us-west1 (GCS); us-east-1, us-west-2 (S3) NIST SP 800-53
EU_ECB europe-west1, europe-west4, europe-north1 (GCS); eu-west-1, eu-central-1 (S3) GDPR Art. 44, DORA
APAC_MAS asia-southeast1, asia-southeast2 (GCS); ap-southeast-1 (S3) MAS TRM §4.2

The residency module validates that the configured STORAGE_BUCKET location matches the allowed regions for the active deployment posture. Violations raise ResidencyViolationError at startup (fail-closed).

17.5 Layer 3 Adapter Implementations

Adapter Backend Path Key Features
GCS Cold Store Google Cloud Storage src/integrations/storage_gcs/cold_store.py Atomic if_generation_match=0, KMS CMEK encryption, storage.objects.create audit logs
S3 Cold Store AWS S3 / MinIO src/integrations/storage_s3/cold_store.py Conditional PUT headers, SSE-KMS encryption, CloudTrail event logging
Null Cold Store In-memory (dev/test) src/gateway/governance/evidence/null_cold_store.py Accepts flushes, returns well-formed receipts without durable persistence. Raises RuntimeError in production (CAGE_ENV=prod).

17.6 Evidence Stream Integration

The evidence cold store is the durable sink for the compliance evidence stream. EvidenceStream accumulates governance decision records in-memory (NDJSON format), then periodically flushes batches to cold storage via ColdStoreFactory.get_store():

Batch Flush Sequence:

  1. Accumulate evidence records in _buffer (list of EvidenceRecord dicts)
  2. On flush threshold (time-based or count-based), serialize buffer to NDJSON bytes
  3. Call cold_store.put_batch(key=f"evidence/{timestamp}.ndjson", content=ndjson_bytes)
  4. Receive ColdStoreReceipt with SHA-256 digest and storage URI
  5. Emit receipt to audit log and telemetry span (cage.evidence.cold_store_receipt)

ISO 42001 mapping: A.7.5 (Records Integrity), A.5.3 (Documentation and Record Keeping) — durable, immutable evidence archival with cryptographic integrity verification.

NIST SP 800-53 mapping: AU-9 (Audit Record Protection), AU-11 (Audit Record Retention) — evidence records stored in WORM-equivalent object storage with 7-year retention (FINRA 4511 / SEC 17a-4 compliance for financial domains).

17.7 Fail-Closed Posture

All cold store operations fail-closed:

  • Network/auth failures raise ColdStoreError (never silently drop evidence)
  • Residency violations block startup (never start with non-compliant storage configuration)
  • NullColdStore raises RuntimeError in production (never run prod with mock storage)

This ensures that evidence loss or residency violations are impossible by construction, not detected after the fact through log analysis.

Document ends. Next: 07-SECURITY-INFRASTRUCTURE.md