# AEGIS — Release Security Gate

- **Document ID:** ARCH-28
- **Phase:** D — Deployment & Long View
- **Status:** Draft for review (post four-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect

---

## 1. Purpose

Codify the mandatory gates every AEGIS production release passes. Implements mandate #39 (Release Assurance Gates), #40 (Security Regression Prevention), and complements ARCH-14 (Supply Chain) and ARCH-27 (Verification Strategy).

## 2. Release Types

- **Standard release.** Planned; all gates full.
- **Emergency release** (patch under active exploitation). Expedited gates + post-hoc completion within 5 business days.
- **Air-gap variant.** Full gates + air-gap-integration test.

## 3. Gate Sequence

Every release passes gates in order. A failed gate blocks release until resolved. Skipped gates require explicit Owner + Auditor exception and Debt Register entry (ARCH-29).

### G-1 Architecture Review
- Delta from prior release reviewed against ARCH-* docs.
- Changes to security-critical paths (Kernel, Cryptographic Identity, Capability, Audit, Watchdogs, Recovery, AI Safety Layer) require ARCH-doc update in the same PR.
- Documentation-drift check (mandate #43 executable docs).

### G-2 Threat Review
- Threat Model (ARCH-03) updated where scope changed.
- New attack surface: adversary profile updated; residual risks recorded.
- Cross-check against Adversarial Architect Review notes from Phase B/C/D docs.

### G-3 Dependency Review
- SBOM diff; new dependencies triaged (ARCH-14).
- SCA vulnerability status per severity; SLOs met per ARCH-19 §7.2.
- License compatibility.
- Supply-chain attestation checks.

### G-4 Security Testing
- Full unit + property + integration + fuzz suites pass.
- SAST (semgrep + CodeQL) — no new criticals.
- Redaction canary passes (ARCH-20).
- AI canary evals pass (ARCH-14 §8).
- Regression tests for previously-guaranteed properties pass (mandate #40).

### G-5 Recovery Validation
- Restore drill on a canary tenant passes with Recovery Integrity Attestation (ARCH-18 §8).
- Backup integrity current; air-gap copy verified.
- Rollback plan documented and validated in staging.

### G-6 Operational Readiness
- Runbook drift check (ARCH-21) — any new failure modes have runbooks.
- On-call staffed and briefed on changes.
- Monitoring / dashboards updated for new metrics.
- Air-gap-variant integration test passes (ARCH-25 §3.6).

### G-7 Approval
- Owner + Auditor sign-off recorded.
- For releases touching signing hierarchies: ceremony completed per ARCH-14/22.
- Change ticket references all gates.

### G-8 Release
- Signed artifacts pushed to release channel(s).
- Deployment canary tenant subset first; graduated rollout.
- Post-release monitoring window with automatic rollback on regression signals.
- Transparency log update (release hash published).

## 4. Regression Prevention (Mandate #40)

Every previously-guaranteed security property is a **golden invariant**:

- Golden invariants have a dedicated test in `tests/golden/` — cannot be edited without ARCH-19-EXCEPTION + Owner + Auditor sign-off.
- Golden invariants run on every PR + every release; failure blocks.
- Adding a golden invariant is easy; removing is hard.
- Examples: capability attenuation, classification propagation, hash-chain monotonicity, revocation propagation, redaction correctness, watchdog quorum decision behavior, Recovery Integrity Attestation format.

## 5. Emergency Release Path

- **Trigger:** active exploitation or SEV-1 vulnerability confirmed.
- **Expedited gates:** G-3 (dep review, limited to affected dep), G-4 (security testing on affected path + regression suite), G-5 (restore drill deferred if not affected), G-7 (Owner-only fast approval, Auditor notified).
- **Post-hoc completion.** Full-gate closure within 5 business days.
- **Debt Register entry** recording skipped gates + timeline.

## 6. Independent Architecture Review

- **F-1.** *Gate exceptions may become routine.* Exception count is a security metric (ARCH-24); trend alarms.
- **F-2.** *Test suites take a long time.* Bounded; parallelised; incremental where safe; time budget documented per gate.

## 7. Adversarial Architect Review

- **A-1.** *Insider skips a gate via exception.* Exception requires Owner + Auditor; audited; expiration; drift.
- **A-2.** *Golden test edited during a large PR.* Golden tests in `tests/golden/` require special CI approver + Auditor visibility.
- **A-3.** *Emergency release used as skip-gate loophole.* Emergency releases audited; post-hoc completion tracked; abuse alarms.

## 8. Operational Reliability Review

- **O-1.** Gates parallelised where possible.
- **O-2.** Release-CI cost within sustainability envelope.
- **O-3.** Runbook + drill for the release process itself; drilled quarterly.

## 9. Self-Critique

- **S-1.** *Gate G-1 architecture review is subjective.* Templates + reviewer checklist reduce subjectivity; still requires human judgment.
- **S-2.** *G-6 operational readiness is broad.* Sub-checklist per operational risk; documented.
- **S-3.** *"5 business day post-hoc" for emergencies can slip.* SLO-tracked; overdue alarms.

## 10. First-Target Analysis and Redesign

**Target:** the Emergency Release path. It's the natural attacker target because it exists precisely to weaken normal controls under time pressure. Response:
1. **Emergency-release scope constrained** — only affected components can be modified; unrelated changes forbidden.
2. **Fingerprint the emergency change** — a specific bug + specific fix documented at release time.
3. **Auditor notified in real-time**, not post-hoc.
4. **Full-gate closure SLO** tracked as a security metric; overdue > policy triggers SEV-3.

**Second target:** golden invariant edits during large PRs. Response: PR splitter tool separates golden edits; special approver required; Auditor visibility.

## 11. Decisions

### D-28-1. Golden invariants CI-enforced

- **Reason.** Mandate #40 regression prevention.

### D-28-2. Emergency release scope-restricted

- **Reason.** Emergency is not "everything goes."

## 12. Open Questions

- Q-28-1. Automatic-rollback trigger metrics per component. Resolved in ARCH-24 addendum.

## 13. Change Log

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