# AEGIS — Vision Document

- **Document ID:** ARCH-01
- **Phase:** A — Problem Definition
- **Status:** Draft for review
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect
- **Depends on:** CLAUDE.md (Engineering Constitution v1.0)

---

## 1. Purpose

This document defines what AEGIS is, what it is not, why it exists, and the shape it must retain over a 10-year horizon. It is the strategic anchor every downstream architecture document must respect. When later documents present tradeoffs, they must be judged against the mission stated here.

## 2. Mission

AEGIS is an **AI-native, defensive-only Security Operating System**. Its purpose is to help individuals, organizations, MSSPs, and government-adjacent operators continuously **prevent, detect, analyze, contain, recover from, and learn from** security events across endpoints, servers, cloud infrastructure, AI systems, identities, networks, and data.

AEGIS aims to become one of the most trustworthy defensive security platforms in existence. It measures success by *reduction of adversary success* and *increase of defender confidence*, not by feature count.

## 3. Non-Goals

Explicitly listed to prevent scope drift into adjacent, misaligned, or unsafe categories:

- **AEGIS is not an antivirus.** It does not compete on signature databases, on-access scan speed, or consumer-grade malware quarantine flows.
- **AEGIS is not an offensive platform.** It contains no exploit generation, credential-theft tooling, C2 framework, malware authoring, phishing kit, persistence tooling, or unauthorized offensive automation. Any capability whose primary purpose is enabling misuse is disqualified — see CLAUDE.md § Defensive-Only Policy.
- **AEGIS is not a general-purpose data lake.** It stores security-relevant telemetry and derived intelligence. It is not a substitute for a customer's observability or BI stack.
- **AEGIS is not an audit-compliance-checkbox tool.** It supports compliance evidence as a byproduct of good security, not as its purpose.
- **AEGIS is not a closed platform.** It is extensible, but through a governed plugin system, not by dropping arbitrary code into the runtime.
- **AEGIS is not vendor-locked to any cloud, any AI provider, or any log source.** Every provider is replaceable (CLAUDE.md § Additional Principle 2, 3).

## 4. Positioning

AEGIS overlaps with — but is not identical to — several existing categories:

| Category | Relationship |
|---|---|
| **SIEM** (Splunk, Sentinel, Chronicle) | Overlap on ingestion and correlation. AEGIS differs by treating AI reasoning as first-class, not bolted on, and by being self-hostable and provider-independent by default. |
| **XDR** (CrowdStrike Falcon, SentinelOne, Defender XDR) | Overlap on detection/response. AEGIS defers endpoint agent to a later phase and starts as the Security Brain that any endpoint can later feed. |
| **SOAR** (Tines, Torq, Palo Alto XSOAR) | Overlap on playbook orchestration. AEGIS treats orchestration as a *policy-gated* consequence of AI recommendation, not as manual script authoring. |
| **CSPM / CNAPP** (Wiz, Prisma Cloud) | Deferred (Config Review is Phase 2/3). |
| **CMDB / ITAM** (ServiceNow) | Deferred (Asset Inventory is Phase 2/3). |
| **Vulnerability Management** | Deferred to a later phase; AEGIS consumes VM findings, does not produce them. |
| **DFIR platforms** (Cellebrite, Magnet AXIOM) | Adjacent. AEGIS assists incident timeline and evidence chain; it is not a forensic imaging tool. |

Positioning summary: **AEGIS starts as an AI-native security brain** (ingest → correlate → reason → narrate → prove) and grows outward toward sensors, response, and posture, in that order.

## 5. Ten-Year Outlook

Design decisions today must remain defensible in 2036. The following long-horizon assumptions are made explicit so they can be revisited:

1. **Frontier AI capability will keep improving**, but on-device inference at 30–70B parameters will be affordable on enterprise hardware within 5 years. Architecture must serve both the frontier hosted case and the strong local case.
2. **Post-quantum cryptography will be mandatory** for regulated customers well within 10 years. Crypto choices must be agile (CLAUDE.md § adopted principle 2; ARCH-11 will formalize).
3. **Regulation of AI-in-security will intensify**. Explainability, evidence citation, and human-in-the-loop for high-impact actions are not optional add-ons — they must be architectural.
4. **Air-gapped, sovereign, and jurisdictionally isolated deployments will remain valuable**, not niche.
5. **Supply-chain attacks against security tools will worsen**. Every dependency, model, and plugin must be treated as potentially hostile.
6. **The prompt-injection threat surface will be enduring.** Any system that ingests untrusted text and asks an LLM to reason about it must assume adversarial content. AEGIS ingests logs — which are attacker-controllable text.

## 6. Guiding Principles

Inherited from CLAUDE.md; restated here as the strategic filter for every future decision:

1. **Trust > velocity.** A trustworthy narrow platform beats an untrustworthy broad one.
2. **Defensive-only, forever.** No exception, no dual-use exception, no research exception. Categorical refusal is a feature.
3. **Provider-independent.** Every AI, every cloud, every log-source, every plugin is replaceable.
4. **Local-first where practical.** Cloud is an option, not a dependency.
5. **Policy as gate, not stage.** Enforced at every trust boundary.
6. **Evidence-preserving by default.** Nothing is silently mutated. Nothing is silently deleted.
7. **Fail-secure, fail-closed.** An AEGIS outage must not open a door.
8. **Every AI action carries policy, classification, evidence, redaction, and audit metadata.**
9. **Every sensitive operation is Authorized, Logged, Auditable, Traceable, Recoverable.**
10. **Architecture First. Implementation Second. Optimization Last.**

## 7. Scope of v0

v0 delivers **six** capabilities and no more:

| # | Capability | v0 Definition |
|---|---|---|
| 1 | **Log Collection** | Pluggable ingestion for a small, defensible set of sources (syslog, common cloud audit logs, Windows Event Log via forwarder, generic HTTP/JSON push). No endpoint agent yet. |
| 2 | **Event Normalization** | Deterministic mapping to a canonical event schema (open standard, likely OCSF-aligned) with source-of-truth preservation. |
| 3 | **Security Event Correlation** | Rule-based first (Sigma), with a clear extension point for statistical and ML detectors. Deterministic and explainable. |
| 4 | **AI Security Recommendations** | Human-readable, evidence-cited recommendations produced by the three-tier AI router. Human-in-the-loop by default. |
| 5 | **Incident Timeline** | Chronologically ordered, evidence-linked timeline of related events for a case. |
| 6 | **Immutable Audit Trail** | Hash-chained, real-time integrity chain + asynchronous signed archival. Non-negotiable. |

Everything else — Dashboard, Asset Inventory, Configuration Review, Risk Scoring, Threat-Intel Correlation, endpoint agent, response actions, MSSP multi-tenant control plane — is deferred to Phase 2+, sequenced in ARCH-18.

### 7.1 v0 Success Criteria

v0 is successful when:

- A self-hosted deployment can ingest 10M events/day per customer at ≤ 5s p95 correlation latency on a single-node Kubernetes cluster with commodity hardware.
- An air-gapped deployment can produce useful AI recommendations using only local L1+L2 tiers.
- Every recommendation cites specific evidence events by ID and hash.
- The audit trail can be independently verified for integrity by a third party using only public tooling and the published hash-chain schema.
- Every dependency has a documented replacement plan (AI provider, database, event store, message bus, identity provider).
- No feature bypasses the Security Pipeline (CLAUDE.md § Security Pipeline).

## 8. Guardrails Against Scope Drift

Strategic risks to the mission and the corresponding guardrails:

| Risk | Guardrail |
|---|---|
| Feature pressure toward offensive tooling ("red team just needs a small module…") | Categorical refusal; documented in CLAUDE.md § Defensive-Only Policy; enforced in code review checklist (ARCH-12). |
| Vendor pressure to lock to one AI provider | Provider-independent AI runtime is a hard requirement in ARCH-09. Every model call goes through the router. |
| Cloud pressure to require SaaS-only | Self-hosted and air-gapped remain first-class; every release must pass a "cloud-off" integration test (ARCH-16). |
| SIEM feature-parity race | v0 keeps the six-capability limit. Adding a capability requires a documented threat-model update. |
| AI hype override of policy | Every AI call passes the Policy Engine at the boundary. No "just this once" bypass. |
| Time pressure from investors / customers | Definition of Done (CLAUDE.md) is a hard gate. No feature ships without threat-model update, security review, tests, monitoring, rollback. |

## 9. Strategic Decisions

Each decision is presented in the required format (CLAUDE.md § Additional Principle 7).

### D-01-1. Ship v0 as the "Security Brain" (no endpoint agent yet)

- **Advantages.** Delivers a full ingest → detect → reason → narrate → prove loop in one release; endpoint agent is a large parallel workstream that would fragment focus; the Brain is valuable *with any* endpoint source, so customer choice is preserved; delaying the agent avoids the security-of-the-agent problem (kernel drivers, self-protection, tamper resistance) until foundations are solid.
- **Disadvantages.** Without an endpoint agent, initial customers must have alternate telemetry sources (cloud logs, other EDRs, syslog). Reduces addressable market at launch. Delays a differentiation point.
- **Security Impact.** *Positive.* An endpoint agent is a privileged, kernel-adjacent surface with enormous blast radius (see CrowdStrike July-2024 incident). Deferring it until the Brain is trustworthy reduces risk of shipping a fragile agent.
- **Operational Impact.** Smaller surface to run, monitor, and support at launch.
- **Scalability.** Higher — the Brain scales with data plane, not with per-endpoint fleet.
- **Maintainability.** Higher — one product, one release cadence at launch.
- **Future Expansion.** Endpoint agent, network sensors, cloud connectors all feed into the same Brain contract.
- **Risk Assessment.** *Medium-low.* Some market segments require an agent; those are simply out-of-scope for v0.
- **Alternatives considered.**
  - *Agent-first v0.* Faster to a "complete EDR" story, but forces us to solve kernel-level engineering, self-protection, and multi-OS support before the Brain is stable. Rejected.
  - *Agent + Brain simultaneous v0.* Fragments engineering effort; risks shipping both shallow. Rejected.
- **Reason for final decision.** Trust > breadth. A trustworthy Brain enables safe agent development later; the reverse ordering does not.

### D-01-2. Defensive-only is categorical

- **Advantages.** Removes ambiguity for every future contributor and customer; enables recruiting on mission; simplifies threat-model of *our own* product (we are not a target for offensive tool trade); aligns with regulatory direction on dual-use.
- **Disadvantages.** Forfeits revenue from red-team tooling market; requires vigilance against feature creep.
- **Security Impact.** *Strongly positive.* Prevents platform from becoming a force multiplier for attackers.
- **Operational Impact.** Simpler export-control posture.
- **Scalability.** Neutral.
- **Maintainability.** Higher — no ambiguous features to audit.
- **Future Expansion.** Adjacent defensive categories (DFIR, deception, threat-intel curation) remain open.
- **Risk Assessment.** *Very low.*
- **Alternatives considered.**
  - *Dual-use with strong access control.* History shows access control is bypassed under commercial pressure. Rejected.
  - *"Purple team" mode.* Same failure mode; rejected.
- **Reason for final decision.** Constitution binds; category exists for a reason.

### D-01-3. Provider-independent AI runtime

- **Advantages.** No frontier-provider lock-in; enables air-gap; enables local-first; enables switching providers on pricing, quality, safety, or policy grounds.
- **Disadvantages.** Higher engineering cost (router, adapters, evals per provider); requires abstraction that some cutting-edge features may not fit into cleanly.
- **Security Impact.** *Positive.* Reduces single-point-of-failure on a critical dependency.
- **Operational Impact.** Slightly higher — must maintain multiple provider adapters.
- **Scalability.** Positive — can route across providers based on load, cost, availability.
- **Maintainability.** Requires discipline in the router abstraction.
- **Future Expansion.** New providers plug in; local model quality improvements plug in.
- **Risk Assessment.** *Low.* Abstraction leakage is the main risk; mitigated by strict adapter contracts.
- **Alternatives considered.**
  - *Single provider (e.g., Claude only).* Fastest to build; unacceptable single-point-of-failure and violates air-gap requirement. Rejected.
  - *Two providers (one hosted, one local).* Insufficient — still a lock-in with two vendors. Rejected.
- **Reason for final decision.** Long-term durability requires optionality on the fastest-moving dependency in the stack.

### D-01-4. Ten-year horizon over three-year horizon

- **Advantages.** Every choice weighted for durability; discourages fashionable-but-fragile tech; aligns with enterprise procurement realities.
- **Disadvantages.** Slower to launch; some near-term novelty deferred.
- **Security Impact.** *Positive.* Discourages "we'll fix it later" security debt.
- **Operational Impact.** Neutral in the long run.
- **Scalability / Maintainability.** Positive.
- **Future Expansion.** Baked in — the horizon *is* future expansion.
- **Risk Assessment.** *Low.*
- **Alternatives.** *Move-fast v0.* Rejected — inconsistent with mission.
- **Reason.** Mission is trust; trust is compounded over years.

## 10. Assumptions Requiring Later Validation

These are stated openly so ARCH-02 (SRS) and ARCH-03 (Threat Model) can test them:

1. Customers accept a self-hosted deployment path even if a hosted option is later offered.
2. A meaningful fraction of prospective customers require air-gap.
3. Local open-weights models at 7–14B are sufficient for L2 tasks (enrichment, summarization, classification).
4. Rule-based correlation (Sigma) plus deterministic detectors cover ≥ 70% of detection load in v0.
5. OCSF (or a similar open schema) is acceptable as the canonical event model.

## 11. Open Questions

The following remain open and will be resolved during Phase A / B:

- Q-01-1. Target regulatory certifications for v1 (SOC 2 Type II is baseline; ISO 27001, HIPAA-ready, FedRAMP-Moderate readiness are candidates). Resolved in ARCH-02.
- Q-01-2. Default local model family for L2 (Llama 3.x, Qwen 2.x, Mistral). Resolved in ARCH-09.
- Q-01-3. Canonical event schema commitment (OCSF, ECS, custom). Resolved in ARCH-07/08.
- Q-01-4. Single-tenant-first vs multi-tenant-first for the hosted path. Resolved in ARCH-06/10.

## 12. Change Log

- **0.1 (2026-07-10)** — Initial draft for Phase A review.