# AEGIS — Future Roadmap

- **Document ID:** ARCH-32
- **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

Sequence AEGIS's evolution beyond v0-GA. Rooted in the mission from ARCH-01: build a trustworthy defensive Security OS whose value compounds over 10-15 years. Sequencing is **trust-milestone-gated**, not tech-ambition-gated.

## 2. Governing Principles

1. **Trust before scope.** Each phase adds capability only after prior phase is trustworthy.
2. **Evolution over replacement** (mandate #44).
3. **Assurance-level progression** per subsystem (ARCH-27).
4. **Simpler where possible** (mandate #24) — every new capability preserves security through clarity.
5. **Debt paydown** interleaved with new capability.
6. **Human authority preserved** at every phase.

## 3. v0-GA (Baseline — 2026)

Delivered (per Phase A–D):
- 6 core capabilities (Log Collection, Normalization, Correlation, AI Recommendations, Timeline, Audit).
- Security Kernel + 15 engines (11 mandated + Normalization, Case, Risk, Evidence).
- OIDC identity, capability model, cryptographic identity, Zero-SPOT Kernel.
- L1 + L2 + L3 AI routing with Safety Layer.
- Immutable Event Sourcing + Evidence Chain + Multi-Stage Decision Pipeline.
- Recovery Domain + immutable + air-gap backups.
- Web UI (Next.js).
- Reference deployments R-1, R-3, R-4, R-5, R-6.

## 4. v0.1–v0.2 (Trust Consolidation — 2026-2027)

**Goal:** stabilize v0 in production; retire priority debt; expand assurance.

- **Debt paydown.** D-A-01 (AI canary corpus), D-P-01 (Plugin runtime v0.2), D-D-01 (R-2 Docker coverage).
- **Plugin runtime.** Wasm sandbox + governance per ARCH-17.
- **Tauri desktop** (v0.2) — thin viewer over Next.js.
- **Expanded canary evals** for AI providers.
- **Chaos maturity** (ARCH-30 M-D-3).

## 5. v1 (Capability Growth — 2027)

**Goal:** expand from 6 → 10 v0-scope capabilities.

- **Central Dashboard** (across cases + findings + audit).
- **Configuration Review** (cloud-provider-specific; single cloud first).
- **Asset Inventory** (manual + cloud-connector-derived).
- **Risk Scoring** across assets (feeds Runtime Risk Engine E-14).
- **Threat-Intel Correlation** (first commercial + open feeds).
- **SAML + SCIM** (ARCH-02 D-02-4 debt retired).
- **BYOK** (customer-managed KEK for hosted mode; also self-hosted variant).
- **Hosted mode (limited GA).** R-7 pilot; per-region; single-tenant-per-region initially.

**Assurance targets** advance per ARCH-27 §3.

## 6. v1.5 (Response Foundation — 2028)

**Goal:** narrow, careful introduction of automated response.

- **Response Engine (Phase 3) — partial GA.** Automated response for a small, carefully-chosen set of low-risk, reversible actions (e.g., proposed rule updates, proposed policy suggestions to tenant admin, cross-case alert suppression). *Actions in customer environments remain human-approved.*
- **Endpoint Agent (limited GA).** Windows + macOS + Linux endpoint telemetry via a signed, sandboxed, self-protection-hardened agent. Kernel-level integration is out of scope for v1.5.
- **Formal verification** of Kernel capability directory (TLA+) — target completion (D-S-01 debt retired).
- **PQC hybrid signatures** for long-lived audit archival (D-C-01 partial retire).

## 7. v2 (MSSP + Federation — 2029)

- **MSSP hosted multi-tenant** with cross-tenant separation controls, batch capabilities, per-region trust.
- **Federated deployments** across regions with cross-region audit continuity.
- **Threat-intel sharing** across consented tenants with differential privacy.
- **Endpoint agent expansion** — kernel driver + self-protection matured.
- **Confidential Computing pilot** for Kernel + Audit + AI (per Future Readiness).

## 8. v2.5 – v3 (High Assurance — 2029-2030+)

- **FedRAMP Moderate** readiness → certification.
- **Post-quantum primary** across all signature sites (D-C-01 retired).
- **Confidential AI** — L2/L3 in TEEs where available.
- **Threshold signing** for Root of Trust.
- **Formal verification** expanded to Safety Layer + Recovery Engine.

## 9. Beyond (10+ years)

- **Confidential computing standard.** All security-critical engines run in TEEs where hardware is available.
- **Attested distributed trust** — hardware-anchored watchdog quorum.
- **Zero-knowledge audit selective disclosure.**
- **Continuous compliance automation.**
- **Peer benchmarking** across the AEGIS user community with privacy-preserving analytics.
- **Ecosystem** — publisher ecosystem for plugins + detection content.

## 10. Sequencing Principles

- **No feature ships without ARCH-doc + Threat Model diff + Debt Register update.**
- **Each phase gate requires:** prior phase in steady-state, prior debt retired or renewed with justification, assurance targets achieved.
- **User-facing capability** paced with **operational maturity** (ARCH-30) — don't ship a Response Engine if IR maturity is M-IR-2.
- **Cost/benefit** — every phase justifies its addition to the platform's *defensive posture*, not just to a market signal.

## 11. Independent Architecture Review

- **F-1.** *Roadmap is a prediction; predictions fail.* Framework is designed to accept re-sequencing; each phase gates re-evaluate priorities.
- **F-2.** *"Trust before scope"* is easy to say and hard to maintain under commercial pressure. Governance in ARCH-23/29; Auditor visibility.

## 12. Adversarial Architect Review

- **A-1.** *Attacker times campaign for phase transition.* Phase gates verified; transitions drilled; watchdogs active during.
- **A-2.** *Insider argues for skipping phases.* Governance requires ARCH-doc + Threat Model update + gate closure.
- **A-3.** *Attacker exploits new capability's initial immaturity.* Canary rollout; per-tenant opt-in; adaptive trust; reduced ceilings until maturity.

## 13. Operational Reliability Review

- **O-1.** Roadmap paced with team size + operational maturity.
- **O-2.** Communication cadence to tenants + auditors.
- **O-3.** Revisions on quarterly cadence.

## 14. Self-Critique

- **S-1.** *Dates are aspirational.* Roadmap will slip; the framework is designed to make slippage safe.
- **S-2.** *"Trust milestone"* language could hide feature-focused pressure.* Explicit gate criteria (assurance level, debt paydown, ARCH-doc) resist.
- **S-3.** *Response Engine is a large, high-risk capability.* v1.5 gating is conservative; may push further.
- **S-4.** *Endpoint agent* is another huge undertaking; scope may need trimming or a separate roadmap.

## 15. First-Target Analysis and Redesign

**Target:** Response Engine (v1.5). It's the closest AEGIS ever comes to acting-in-tenant-environments; it's a natural high-value target and a natural feature-pressure target. Response:
1. **Response Engine only for defensive, reversible, low-risk actions in v1.5.** Rule updates, tenant-side suggestions — nothing that mutates customer environments.
2. **Every response action passes Multi-Stage Decision Pipeline** with all engines concurring.
3. **Human authority preserved** — every response action has an approval mechanism unless tenant-opt-in for narrow categories.
4. **Assurance L4 required** on Response Engine before wider actions.
5. **Debt Register** if L4 not achieved before rollout.

**Second target:** MSSP hosted (v2). Hosted multi-tenant is the biggest attacker-value target. Response: pilot with limited tenants; per-region single-tenant first; per-tenant partition; extensive drills; Auditor engagement.

## 16. Decisions

### D-32-1. Trust-milestone-gated sequencing

- **Reason.** Mandate #24 + #34.

### D-32-2. Response Engine constrained scope at v1.5

- **Reason.** §15 first-target response.

## 17. Open Questions

- Q-32-1. Response Engine detailed threat model. Phase 3 planning.
- Q-32-2. Endpoint agent architecture. Separate ARCH doc when scoped.
- Q-32-3. FedRAMP timing tied to customer segment. Commercial decision.

## 18. Change Log

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