# AEGIS — Continuous Adversarial Validation

- **Document ID:** ARCH-50
- **Phase:** E.3 — Adversarial/Defensive Teams
- **Status:** Draft for review (post four-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect

---

## 1. Purpose

Codify the always-on validation loop that combines threat simulation (ARCH-39), narrow chaos (ARCH-48), narrow red probes (ARCH-45), and canary claim reproduction (ARCH-43). The goal is a live, running heartbeat that says "the platform's defenses are still true today, not just at last release."

## 2. Model

- **CAV Runner** — orchestrator that schedules and runs bounded validations across the substrate 24/7.
- Runs bounded probes:
  - Threat scenario canaries.
  - Injection canaries (redaction, prompt injection).
  - Watchdog-silence spot checks.
  - Kill-switch time measurements.
  - Ledger consistency checks.
- Every run produces signed evidence attached to the relevant claim.
- Failures alarm through the standard alarm channel; distributional drift alarms independently.

## 3. Relationship with Other Frameworks

- **Threat Simulation (ARCH-39):** provides scenarios.
- **Chaos (ARCH-48):** provides failure-injection scenarios.
- **Red Team (ARCH-45):** provides periodic human insight; findings translate into new CAV probes.
- **Blue Team (ARCH-46):** consumes CAV alerts; tunes detection.
- **Evidence Traceability (ARCH-43):** CAV emits evidence artifacts.

## 4. Cadence and Safety

- Runs are bounded in scope + resource.
- Kill-switch immediate.
- Blast radius default: canary tenants only.
- Weekly summary reported.

## 5. Security-Mechanism 4-Question Spec (mandate #3, applied to CAV itself)

- **What if CAV fails?** Its outages surfaced as alarms; other validation instruments cover.
- **Can another mechanism compensate?** Yes — scheduled game days, red engagements, external audit.
- **Can operators detect the failure?** Yes — CAV heartbeat metric; missing runs alarm.
- **Can attackers hide the failure?** Alarm channels diverse (per ARCH-24); external mirror opt-in.

## 6. Assumption (hypothesis)

- **H-1.** *Continuous narrow probes catch drift within days rather than the months of release cycles.*
   - Evidence: initial pilot vs. baseline.
   - Validation: measure drift-detection latency.
   - Confidence: Medium.
   - Expiration: 12 months.
   - Review Date: 6 months.

## 7. Trust Score Contribution

CAV outcomes feed `Verification`, `Health`, `Threat Activity` dimensions.

## 8. Independent Architecture Review

- **F-1.** *CAV cost.* Bounded scope; canary-only.
- **F-2.** *CAV becomes noisy.* Distributional-anomaly detection + tuning.

## 9. Adversarial Architect Review

- **A-1.** *Insider disables CAV runs.* Signed plan + heartbeat monitor + external mirror.
- **A-2.** *Attacker exploits CAV during runs to hide activity.* Runs signed + audit-tagged; production remains distinguishable.

## 10. Operational Reliability Review

- **O-1.** Owned by SR + Ops.
- **O-2.** Metric-tracked; heartbeat visible.

## 11. Self-Critique

- **S-1.** *"Continuous" implies always-on; cost is real.* Documented; balanced against value.
- **S-2.** *Narrow scope may miss cross-cutting drift.* Complementary to broader engagements.

## 12. First-Target Analysis and Redesign

**Target:** CAV heartbeat itself. If CAV silently stops, we won't know anything ran. Response: heartbeat metric (ARCH-24 addendum); missing runs alarm; external mirror opt-in.

## 13. Future Risks / Known Limitations / Out-of-Scope / Retirement

- **Future Risks.** As probes proliferate, coverage vs. cost tension.
- **Known Limitations.** Narrow scope only; broader engagements needed.
- **Out-of-Scope.** Autonomous remediation (Human Authority).
- **Retirement Conditions.** Never.

## 14. Decisions

### D-50-1. CAV runner as bounded, signed, heartbeat-monitored always-on validator

- **Reason.** Living verification; drift detection.

## 15. Change Log

- **0.1 (2026-07-10)** — Initial draft.