# AEGIS — Incident Response Standard

- **Document ID:** ARCH-21
- **Phase:** C — Standards & Operations
- **Status:** Draft for review (post four-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect
- **Depends on:** ARCH-03, ARCH-06, ARCH-11 through ARCH-14, ARCH-18, ARCH-19, ARCH-20
- **Consumed by:** ARCH-22 through ARCH-24 and every operational playbook.

---

## 1. Purpose

Codify how AEGIS responds to security incidents. Two categories:

- **AEGIS-self incidents** — the AEGIS platform (as software + service) is under attack, misbehaves, or fails.
- **Customer-facing incident support** — how AEGIS helps a tenant respond to incidents *in their environment* through recommendations, evidence, and integration.

The standard implements the constitutional lifecycle (Detection → Verification → Containment → Isolation → Evidence Preservation → Analysis → Recovery → Validation → Lessons Learned) as prescriptive rules.

## 2. Requirements

- **REQ-1.** Every AEGIS-self incident produces a signed **IncidentRecord** with timeline, evidence links, and IntegrityAttestation.
- **REQ-2.** Every incident category has a **Runbook** — versioned, executable, drilled at least quarterly.
- **REQ-3.** Every runbook is executable by a well-trained security engineer without hidden knowledge (mandate #32).
- **REQ-4.** Incident evidence is preserved and independently verifiable per ARCH-12.
- **REQ-5.** Communications (internal + external) are prescribed by severity + jurisdiction.

## 3. Severity Levels

| Level | Definition | Examples |
|---|---|---|
| **SEV-1 Critical** | Active compromise of Kernel, KMS/HSM, Root of Trust, audit chain; or platform outage affecting all tenants | Kernel integrity alarm, watchdog quorum breach, KMS compromise, ransomware on backups |
| **SEV-2 High** | Compromise of a subset of engines/tenants; possible data exposure; sensitive-op abuse | Compromised engine SVID, missed redaction, single-tenant exfil pattern |
| **SEV-3 Medium** | Confirmed anomaly not yet proven to be exploitation | Odd capability grant, plugin misbehavior, provider-trust anomaly |
| **SEV-4 Low** | Suspected anomaly requiring investigation | Alarm from watchdog canary, drift monitor delta |

Severity is set at first assessment and may only be *raised* automatically; downgrade requires Incident Commander approval + audit event.

## 4. Roles

- **Incident Commander (IC).** Runs the incident. Named per rotation; at least one qualified IC on-call at all times. Has authority to invoke break-glass, activate Emergency modes, coordinate communications.
- **Investigator.** Drives root-cause analysis and evidence preservation.
- **Communicator.** Owns internal + external comms; assembles disclosures.
- **Recovery Lead.** Coordinates Recovery Domain operations (ARCH-18).
- **Scribe.** Maintains the incident timeline; notes decisions and their rationale.
- **Auditor Liaison.** For SEV-1/2, ensures independent verification and regulator readiness.

Every role has a documented backup; no single individual is a SPOF for the on-call roster.

## 5. Lifecycle (Mandatory)

### 5.1 Detection
- **M-1.** Every alarm channel is monitored 24/7 (opt-out for non-critical). Sources: Kernel integrity alarms, watchdog quorum alarms, Safety Layer alarms, Recovery Engine alarms, external alerts (per ARCH-13 §12).
- **M-2.** Detection produces a signed **IncidentInitiation** record (audit event, high severity).
- **M-3.** Auto-generated candidate IncidentRecord opens on alarm; IC assigned via rotation.

### 5.2 Verification
- **M-4.** IC verifies the alarm is not a false positive (canary comparison, cross-check with independent signal).
- **M-5.** Verification produces a `verification_verdict` (real / false-positive / needs-more-data) with cited evidence.

### 5.3 Containment
- **M-6.** Contain first, investigate later. Preferred containment is *reversible*: revoke capabilities, freeze issuance (`Freeze-Kernel-Issuance`), disable a plugin, quarantine an ingest source. Irreversible actions (kill engine, revoke KEK) require IC + a second approver.
- **M-7.** Containment actions are Multi-Stage Decision Pipeline operations (ARCH-11), with Recovery Impact reviewed before execution.

### 5.4 Isolation
- **M-8.** Where a specific engine instance is suspect, isolate: drain from load balancer, remove from Kernel identity chain, preserve state for forensics.
- **M-9.** In extreme cases: platform enters Emergency Mode (per each engine's mode definitions).

### 5.5 Evidence Preservation
- **M-10.** Snapshot: engine memory (per policy), audit tail, Layer-A local ring, relevant config catalogs, capability directory. Snapshot is signed and stored in Recovery Domain object store.
- **M-11.** Chain of custody per ARCH-12 §6. Every access to evidence during IR is itself an audit event.
- **M-12.** External evidence (provider logs, cloud logs) captured with signed metadata (source, method, time).

### 5.6 Analysis
- **M-13.** Root-cause investigation uses the Evidence Chain reproducibility (ARCH-12 §5.2). Every conclusion cites evidence by ID + hash.
- **M-14.** AI Engine may assist analysis but does not gate conclusions (Human Authority).
- **M-15.** Analysis is time-boxed at Analysis Session level (typically 2h blocks with checkpoint reviews).

### 5.7 Recovery
- **M-16.** Recovery follows ARCH-18 flows: Recovery Domain-executed, Multi-Stage Decision Pipeline gated, four-eyes + break-glass for destructive operations.
- **M-17.** Recovery Integrity Attestation produced (per five-question checklist, ARCH-18 §8).

### 5.8 Validation
- **M-18.** Post-recovery: watchdog quorum passes; sample restore verification; canary drills re-run.
- **M-19.** Tenant impact statement produced with evidence.

### 5.9 Lessons Learned
- **M-20.** Post-Mortem within 5 business days of resolution. Blameless. Deliverables: root cause narrative, timeline, evidence links, corrective actions (with owners + due dates), residual risk update, ARCH-03 threat model diff.
- **M-21.** Corrective actions tracked; SLO for completion; auditor visibility.

## 6. Runbook Structure (Prescriptive)

Every runbook is a versioned, signed markdown file with the sections:

```
Runbook: <slug>
Version: <semver>
Owner: <team>
Depends on: <engines, keys, capabilities>
Preconditions:
Steps:
  1. <action> — expected outcome — verification
  2. …
Rollback:
Post-checks:
Time budget:
Escalation:
Change log:
```

Runbooks execute in the operator's session; every step is optionally scriptable via CLI; every action is Kernel-mediated so it inherits audit + approval.

## 7. Categories and Their Runbooks (v0 baseline)

- **KernelIntegrityAlarm** — isolate, capture forensics, watchdog cross-verify, escalate to Kernel Rotation ceremony (ARCH-13 §7).
- **WatchdogQuorumFailure** — inspect watchdog health, replace faulty watchdog, restore quorum.
- **AuditChainGap** — halt Layer-B for affected instance, capture forensics, cross-verify replicated Layer-A, reconstruct if possible.
- **RedactionFailure** — freeze log egress for affected class, ruleset update, back-scan retention window.
- **CapabilityAnomaly** — freeze issuance for anomalous identity, investigate, revoke if warranted.
- **PluginMisbehavior** — kill-switch plugin instance, investigate, potentially revoke publisher.
- **RansomwareOnRuntime** — Emergency Mode on runtime engines, verify Recovery Domain isolation, execute restore from immutable backup.
- **KMSCompromise** — rotate keys in ceremony, force re-attestation, review audit for prior key use.
- **ProviderTrustDrop** — route away from provider, investigate cause, tenant communication if service impacted.
- **AIHallucinationTrend** — pause tier / route down, incident review, re-eval model.
- **DataResidencyBreach** — halt affected data flows, root-cause, tenant + regulator notification per policy.

Each category has: definition, detection sources, severity mapping, mandatory containment, evidence collection, recovery, communication.

## 8. Customer-Facing Incident Support

- AEGIS assists tenants during their own incidents. AEGIS does **not** take action *in tenant environments* in v0 (no Response Engine execution). Assistance is:
  - **Evidence surfacing.** Cases, timelines, correlated findings, signed evidence bundles.
  - **AI recommendation.** Multi-Stage Decision Pipeline outputs with alternative explanations + false-positive/negative reasoning + recovery advice.
  - **Runbook integration.** Tenants can consume AEGIS-published response playbooks (structured; ARCH-19-compliant format).
  - **Regulator support.** Signed exports; verifier CLI; jurisdiction-aware retention.

## 9. Communications

### 9.1 Internal
- SEV-1: real-time channel, cross-team; IC updates every 30 min minimum.
- SEV-2: cross-team channel; IC updates hourly.
- SEV-3/4: normal channel; scheduled updates.

### 9.2 External
- Tenants notified within SLO defined by contract; SEV-1 within 4 h of confirmed impact minimum.
- Regulator notifications per jurisdiction; templates versioned.
- Public disclosure aligns with responsible-disclosure norms; coordinated with any affected upstream (per ARCH-19 vulnerability process).

### 9.3 Draft Messages
- Templates versioned per severity; approved by Communicator; reviewed by Legal for regulator notifications.

## 10. Verification Process

- **Runbook drills** per category, at least quarterly per rotation.
- **Chaos drills** inject synthetic alarms; on-call must run the runbook against a synthetic incident; pass rate is a metric (ARCH-24).
- **Table-top exercises** for SEV-1 scenarios every 6 months, cross-team.
- **Post-drill review** produces artifacts that update runbooks.

## 11. Operational Guidance

- Runbooks live in `docs/runbooks/`; version-controlled; PR review required.
- Every runbook has an owner and a "last drilled" date; expired drills alarm.
- Incident post-mortems are public within AEGIS; tenant-affecting details classified per policy.
- **Blameless culture** enforced; performance reviews do not use IR performance as a punitive signal.

## 12. Future Evolution

- **Automated response** (Phase 3) — Response Engine executes containment for a subset of high-confidence, low-risk actions; strict policy gates; ARCH-11 pipeline unchanged.
- **AI-assisted investigation** — enhanced but always advisory; Human Authority.
- **Cross-tenant threat intel** — sharing patterns across tenants requires explicit consent + differential privacy analysis; roadmap.

## 13. Independent Architecture Review (Reviewer 1)

- **F-1.** *IC rotation resilience.* Backup ICs; secondary escalation; documented.
- **F-2.** *Runbook drift.* Version-controlled; drill freshness a metric; expired drills alarm.
- **F-3.** *Evidence preservation vs. containment.* Explicit ordering (contain reversibly, preserve, then irreversibly if needed).
- **F-4.** *Legal-notification latency.* SLO documented; Legal integrated in the runbook.

## 14. Adversarial Architect Review (Reviewer 2)

- **A-1.** *Attacker triggers a false SEV-1 to force a bad-restore decision.* Verification stage mandatory; Recovery uses Multi-Stage pipeline; canary comparisons.
- **A-2.** *Attacker exhausts on-call by generating alarm floods.* Rate limits, alarm deduplication, tier-1 triage, escalation only on distinct patterns.
- **A-3.** *Insider IC leaks incident details to attacker.* Least-privileged access; audit; separation of duties (Analyst ≠ Communicator); post-hoc review.
- **A-4.** *AI-suggested recovery target is attacker-preferred.* Recovery target is human-approved with structured verification; AI is advisory only.
- **A-5.** *Attacker corrupts runbook to introduce a bad step.* Signed runbooks; ARCH-22 config governance; drift monitor.
- **A-6.** *Attacker abuses "blameless" culture to hide malicious intent.* Blameless applies to human error; malicious intent triggers separate HR / legal process.

## 15. Operational Reliability Review (Reviewer 3)

- **O-1. 24/7 on-call sustainability.** Rotation modeled; sustainable per team size; documented burnout thresholds; back-fill process.
- **O-2. Runbook lifecycle.** Drill schedule + owner + "last drilled" metric; drift alarms.
- **O-3. Alarm quality.** Continuous tuning; noisy-alarm reviews; automated deduplication.
- **O-4. Post-mortem cadence.** 5-day SLO; template; corrective-action tracking with SLO.
- **O-5. Tenant communications.** Templates; approval workflow; jurisdictional routing.
- **O-6. Legal integration.** Legal on runbook review for regulator-notification steps; jurisdictional matrix maintained.
- **O-7. Cross-team coordination.** Documented escalation; cross-team drills for SEV-1.

## 16. Self-Critique (Reviewer 4)

- **S-1.** *"Contain reversibly first" is easy to say; some incidents demand irreversible fast action.* Standard gives IC discretion + second-approver rule; may still slow response. Accept for structural-safety reasons.
- **S-2.** *"Blameless" culture is fragile.* Real cases where an individual's action matters (malicious intent) need a bright-line distinction. Clarified in A-6.
- **S-3.** *Cross-tenant threat-intel is a big future value with big privacy risk.* Standard just parks it. Should flag as future decision requiring ARCH doc rather than tucked in "future evolution."
- **S-4.** *AI as investigation aid.* Real value; standard should articulate constraints more clearly — AI can summarize, prioritize, and cite, but every claim resolvable to signed evidence.
- **S-5.** *Rate-limit anti-alarm-flood* is on the alarm side; there's a second attack — attacker throttles alarms low so nothing surfaces. Distributional drift monitors on alarm cadence are needed. Added.
- **S-6.** *"Drill freshness metric"* is an ARCH-24 metric; standard should require it to be a SEV-3 alarm when stale.

Revising in place:
- Added **M-2a.** Distributional drift monitor on alarm cadence — sustained low-alarm periods themselves alarm (defends against attacker throttling).
- Added **M-14a.** AI-in-investigation is bounded: summarization, prioritization, citation. Every claim resolvable to signed evidence per ARCH-12 §7. No conclusions from AI alone.
- Added **M-21a.** Stale runbook drills raise SEV-3 alarms and block certain change classes until refreshed.

## 17. Attacker's First-Target Analysis and Redesign

**"If I were an experienced attacker, what part of this standard would I target first?"**

**The IC's decision authority.** Reason: the IC has broad authority under time pressure. If an attacker can shape the incident narrative (e.g., prompt-inject their way into what the IC sees; falsify alarms to fatigue; supply bad root-cause hypotheses via a compromised tool), the IC may authorize actions that help the attacker — a bad restore, a wrong containment, a wrong disclosure.

**Redesign response.**

1. **Second-approver rule for irreversible or high-blast-radius actions** (M-6). IC alone cannot decide destructive containment; a second qualified operator must concur, with structured presentation of the proposed action.
2. **Structured verification of alarm origins.** IC sees signed evidence per alarm (source, chain, integrity). Ambient chat summaries are not sources of truth.
3. **AI in investigation is advisory** (M-14, M-14a). AI cannot conclude; every claim traces to signed evidence.
4. **Runbook actions are Kernel-mediated.** IC executes runbooks; runbook step invokes Kernel-mediated operations with capabilities; each action is audited; policy still applies.
5. **Time-boxed IC sessions.** Long incidents rotate ICs; fresh eyes; documented handoff (Scribe artifact).
6. **Independent post-hoc review** by Auditor. Every SEV-1 gets a review; discrepancies feed into corrective actions.

**Second target.** Runbook integrity. Response: signed runbooks (ARCH-22); ceremony to change; drift monitor.

**Third target.** Tenant communications channel. Response: templates versioned + approved; templates prevent hasty misstatements; Communicator role separate from IC.

## 18. Decisions

### D-21-1. IC + second-approver for destructive actions

- **Advantages.** Blast-radius bounded; prevents single-actor mistake or coercion.
- **Disadvantages.** Slightly slower.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** Small in incident timelines.
- **Operational Complexity.** Moderate.
- **Maintainability.** Positive.
- **Scalability.** Positive.
- **Alternatives.** *Sole IC authority.* Rejected — attack target too rich.
- **Reason.** §17 first-target analysis.

### D-21-2. Blameless post-mortem with bright-line malicious-intent carve-out

- **Advantages.** Fosters honest reporting; retains accountability for malicious action.
- **Disadvantages.** Cultural nuance to sustain.
- **Security Impact.** *Positive.*
- **Performance Impact.** N/A.
- **Operational Complexity.** Moderate.
- **Maintainability.** Positive.
- **Scalability.** Positive.
- **Alternatives.** *Punitive post-mortems.* Rejected — hides information. *Fully blameless without carve-out.* Rejected — no accountability for insider action.
- **Reason.** Culture + safety.

### D-21-3. Runbook-execution goes through Kernel-mediated capabilities

- **Advantages.** IR operations inherit audit + policy; no bypass.
- **Disadvantages.** Slightly more infra to hit during an incident.
- **Security Impact.** Strongly positive.
- **Performance Impact.** Small.
- **Operational Complexity.** Moderate.
- **Maintainability.** Positive.
- **Scalability.** Positive.
- **Alternatives.** *Break-glass shell access.* Rejected — no audit continuity.
- **Reason.** Consistency with the platform's own principles.

## 19. Open Questions

- Q-21-1. SEV-1 tenant-notification SLO per contract. Resolved in commercial terms.
- Q-21-2. Cross-tenant threat-intel sharing. Roadmap; requires separate ARCH.
- Q-21-3. Jurisdictional notification matrix maintenance. Resolved in ARCH-23.

## 20. Change Log

- **0.1 (2026-07-10)** — Initial draft after four-reviewer discipline.