# AEGIS — Kernel Self-Verification & Zero Single Point of Trust

- **Document ID:** ARCH-13
- **Phase:** B.2 — Data, Evidence, Supply Chain
- **Status:** Draft for review (post two-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect
- **Depends on:** ARCH-06, ARCH-08, ARCH-09, ARCH-11, ARCH-12
- **Consumed by:** ARCH-14 through ARCH-16

---

## 1. Purpose

Specify how the Security Kernel — the single most privileged component — is itself made verifiable, tamper-detectable, and structurally unable to silently compromise the platform. Implements elevation mandates #1 (Zero Single Point of Trust), #2 (Kernel Verification), and #10 (Recovery Integrity) as they apply to the Kernel itself.

Guiding principle: **the Kernel enforces trust for everything else; therefore the Kernel's own integrity must be enforced by something other than the Kernel itself.**

## 2. Threat Frame

A compromised Kernel could:
- Mint a broad capability to attacker-controlled identity (silently privileged escalation).
- Approve any policy consultation without asking the Policy Engine (silent policy bypass).
- Fake or omit audit records (evidence tampering).
- Substitute engine SVIDs (identity spoofing).

Each of these must be **detectable by mechanisms outside the Kernel**, on a bounded latency, without relying on the Kernel to be honest about itself.

## 3. Layered Defense

Four layers, each independently useful, mutually reinforcing:

| Layer | Purpose | Owner |
|---|---|---|
| **L-1 Boot Integrity** | The Kernel binary loaded matches the signed release | Secure Boot Chain + release-signing hierarchy |
| **L-2 Runtime Integrity** | The running Kernel process has not been tampered mid-flight | Runtime Integrity Verification + hardware attestation (where available) |
| **L-3 Behavioral Integrity** | The Kernel's decisions match what an independent verifier expects | Watchdog engines + Layer-A shadow verification |
| **L-4 Recovery Integrity** | When a Kernel is deemed compromised, replacement is verifiable | Secure Recovery Mode + Kernel Rotation ceremony |

## 4. L-1 — Boot Integrity

### 4.1 Signed Kernel Components
- Every Kernel binary is signed under the **Release Signing Hierarchy** (AS-K-09) at build time, with reproducible-build attestation (ARCH-14 supply chain).
- Container images are signed with cosign (or equivalent); OCI referrers include SLSA provenance.
- Kubernetes admission control (Kyverno / OPA Gatekeeper on the customer side) can be configured to admit only signed Kernel images. Deployment guides ship default policies.

### 4.2 Secure Boot Chain
Where hardware supports it:
- **UEFI Secure Boot** → **measured boot to TPM** → **container platform attestation** → **Kernel binary hash committed to attestation record**.
- Where hardware does not support it: documented as a **lower-trust posture**; software equivalents (dm-verity for base image, in-repository attestation) close some of the gap.

### 4.3 Configuration Attestation
- Kernel loads its configuration from a signed configuration bundle. Startup verifies the signature against a Z0-anchored public key hardcoded in the Kernel image.
- Any post-boot configuration reload requires a signed bundle; unsigned config is refused fail-secure.

### 4.4 Air-gap topology
- Air-gap deployments use offline-signed release bundles (ARCH-14). The verification chain is identical; the difference is the delivery vector.

## 5. L-2 — Runtime Integrity

### 5.1 Runtime Integrity Verification (RIV)
A subsystem inside the Kernel process that computes rolling attestations over:
- The mapped code segment (via `/proc/self/maps` + `mmap` + hashing on a rolling schedule).
- Loaded shared libraries and their hashes.
- Kernel's own configuration in memory (matched against startup-committed hash).
- Per-request nonce challenges to signing keys (proof-of-liveness).

RIV publishes signed **Integrity Beacons** at fixed cadence (default: every 30s) to a dedicated `kernel.integrity.{instance}` NATS subject. Beacons include a monotonic sequence + previous-beacon-hash → self-forming hash chain.

### 5.2 Self-Integrity Monitoring
- The Kernel monitors its own **beacon skew**: if the local beacon fails to match the expected chain, it fails closed on new operations, alerts, and enters **Isolation Mode** (§7.1).
- Cross-replica beacon comparison: each Kernel replica verifies peers' beacons against expected key material.

### 5.3 Tamper Detection
- Any beacon-chain break, unexpected code hash, or unexpected library hash → high-severity alert to Watchdog Engines (§6).
- Signature counter monotonic invariants: signature counters that go backward or repeat indicate rollback attacks; automatic isolation.

### 5.4 Hardware Root of Trust (Future Readiness)
- TPM `TPMS_QUOTE` can be included in Integrity Beacons where TPM is available.
- TEE quote (SGX, TDX, SEV-SNP, ARM CCA) can be included where TEE hosts the Kernel; future readiness.

## 6. L-3 — Behavioral Integrity via Watchdog Engines

The core Zero-SPOT invention for the Kernel.

### 6.1 Concept
An independent verifier subscribes to Kernel decisions and re-derives what a well-behaved Kernel *should* have decided from the same inputs. Divergence is evidence of Kernel compromise.

### 6.2 Watchdogs

- **Audit Watchdog** (embodied in the Audit Engine, E-08). Reads Layer-A entries as they arrive; independently verifies:
  - Every entry's previous-hash link.
  - Every entry's signer key against the current Kernel identity chain.
  - Beacon-chain freshness for each Kernel instance.
  - Absence of gaps.
  Divergence alerts *and* halts Layer-B archival of subsequent entries until reconciled — an attacker cannot silently rewrite history without breaking archival.

- **Policy Watchdog** (embodied in the Policy Engine, E-06). For a sampled fraction of Kernel-mediated decisions, the Policy Engine re-evaluates the decision independently from the Layer-A record and compares. A Kernel that skips Policy consultation produces divergence.

- **Capability Watchdog** (embodied in the Identity Engine, E-07). Periodically reconstructs the expected capability directory from the RBAC + delegation history and compares against Kernel's directory. A silent over-grant is detected here.

- **Evidence Watchdog** (embodied in the Evidence Engine, E-15). Verifies that recommendations claimed as validated actually traversed the Multi-Stage Decision Pipeline stages by cross-referencing signed sub-decisions.

### 6.3 Independence

- Watchdogs live in different engines with different SVIDs and different signing keys.
- Watchdogs run against **replicated** copies of the record they verify (not against a copy the Kernel can rewrite).
- A **watchdog quorum** (default: 2 of 4) can raise a high-severity **Kernel Integrity Alarm** that triggers Isolation and Recovery.

### 6.4 Alarm response
- Isolate: the alarmed Kernel instance is drained from the load balancer; remaining replicas serve read-only.
- Forensic capture: full local ring, memory dump if policy allows, beacon chain preserved.
- Recovery: §7.

## 7. L-4 — Secure Recovery Mode and Kernel Rotation

### 7.1 Isolation Mode
- Triggered by any of: self-integrity failure, watchdog alarm, external emergency signal.
- In isolation: no new capabilities minted, no configuration changes accepted, no key operations initiated. Existing cached capabilities continue to expire naturally.
- Duration: bounded to the time until an emergency Kernel rotation completes or the isolation is cleared by ceremony.

### 7.2 Secure Recovery Mode
- **Purpose.** Bring the Kernel back online from a known-good state without trusting the potentially compromised state.
- **Flow.**
  1. Isolate suspected Kernel instances.
  2. **Ceremony:** revoke Kernel intermediate CA at Z0; issue new intermediate.
  3. Deploy new Kernel instances from a signed release image; verify boot integrity end-to-end.
  4. Force re-attestation of every engine; issue new engine SVIDs from new intermediate.
  5. Replay Layer-A tail from replicated copy; verify no gap.
  6. Cross-verify state (capability directory, revocation list, policy corpus) against dual-store copies.
  7. Resume operations.
- Recovery Engine owns this runbook. Rehearsed at least yearly.

### 7.3 Recovery Integrity Checks (mandate #10)

Every recovery answers, and every answer is signed by the Recovery Engine and by the Audit Engine as watchdog:

1. **Was recovery complete?** — new Kernel is serving, all engines re-attested, no active isolations.
2. **Was evidence preserved?** — Layer-A tail replayed; no gaps in hash chain; Audit Engine cross-verified.
3. **Was rollback possible?** — pre-recovery state snapshotted and retained per Recovery Engine policy.
4. **Did recovery introduce drift?** — configuration diff between pre- and post-recovery reported; any change requires an audit event.
5. **Was integrity re-established?** — post-recovery watchdog quorum passes; alarm cleared.

## 8. Zero Single Point of Trust — how it composes

The Kernel remains privileged, but it is **structurally unable to silently misbehave**:
- **Its identity** is verifiable via boot chain + Z0-anchored signatures (L-1).
- **Its runtime** is attested via beacons + hardware where available (L-2).
- **Its decisions** are shadow-verified by four independent watchdogs (L-3).
- **Its replacement** is a ceremony-controlled rotation with signed verification (L-4).

A silent compromise requires simultaneously defeating all four layers *and* preventing the watchdog quorum from raising an alarm. The Zero-SPOT posture is not that the Kernel can't be attacked — it's that no successful attack can remain silent.

## 9. Kernel Independence from Business Engines

To keep watchdog independence real:
- Watchdog engines run under separate identities, separate deployment schedules, separate credentials.
- Watchdogs pull from *replicated* copies of records, not from Kernel-served copies. Storage Engine replicates Layer-A independently to a watchdog-readable store.
- Kernel does not host any watchdog code; watchdogs never depend on Kernel-served data for their verification loops.
- Watchdogs themselves run at reduced Kernel privilege — they read, they alarm, they do not decide.

## 10. Independent Architecture Review

### 10.1 Hidden Assumptions

| Assumption | Handling |
|---|---|
| Watchdogs are trustworthy enough to raise valid alarms. | Watchdogs use signed records + immutable stores; they can *only* raise alarms, never grant privilege; false alarms are cheap (isolation), false negatives are the risk — mitigated by watchdog quorum + drift monitoring. |
| Beacon channel is available. | If NATS is unavailable, beacons queue locally; sustained outage triggers precautionary isolation. |
| Ceremony participants are honest. | Multi-party at every ceremony; recorded; auditor visibility; but ultimately, culture + governance is the last-mile — accepted residual risk. |

### 10.2 SPOFs

| Finding | Response |
|---|---|
| **F-1.** *Watchdog quorum failure would delay alarms.* | Watchdogs in 4 different engines; quorum of 2 is tolerant to two-engine outage; documented sizing. |
| **F-2.** *Z0 root is still a SPOF for recovery.* | HSM-anchored with multi-party access; threshold cryptography roadmap; recovery ceremony rehearsed. |
| **F-3.** *If all Kernel replicas alarm simultaneously, the platform is down.* | Correct — that is the intended fail-secure posture; recovery ceremony targets ≤ 4 h RTO per NF-1.2. |

### 10.3 Privilege Escalation

| Finding | Response |
|---|---|
| **F-4.** *Compromised Kernel disables its own beacons.* | Absence of beacons at expected cadence is itself an alarm; watchdogs raise if beacons stop or drift. |
| **F-5.** *Compromised Kernel signs beacons but lies about content.* | Beacons include committed hashes for code segments + configuration; independent verifier compares against release-hash registry; discrepancy alarms. |
| **F-6.** *Compromised Kernel replays old beacons.* | Beacons include monotonic sequence + previous-hash link; replay breaks the chain. |
| **F-7.** *Insider corrupts release-hash registry to accept a bad Kernel image.* | Registry is signed; changes are ceremony-controlled; two-party attestation on registry updates. |

### 10.4 Trust-Boundary Violations

| Finding | Response |
|---|---|
| **F-8.** *Watchdog engines are themselves compromised.* | Different engines, different signing hierarchies, different code paths; compromising all four is much more expensive than compromising one. |
| **F-9.** *Watchdog reads Kernel-served copy instead of replicated copy.* | Watchdog implementation reads only from Storage Engine's replicated stream; integration test verifies. |

### 10.5 Bottlenecks

| Finding | Response |
|---|---|
| **F-10.** *Beacon frequency of 30s is too coarse for real-time detection.* | Configurable; can be 5s in high-security environments; costs are modest (small NATS traffic). |
| **F-11.** *Full-mem hashing has runtime overhead.* | Rolling-window hashing amortizes; typical overhead < 1% CPU. |

### 10.6 Supply Chain

| Finding | Response |
|---|---|
| **F-12.** *Compromised release-signing key produces a signed bad Kernel.* | Release-signing key HSM-anchored, ceremony-controlled; time-window compromise mitigated by post-release verification and drift-monitor; transparency log for release hashes (Future Readiness). |
| **F-13.** *TPM firmware backdoor undermines HRoT.* | HRoT is a strong layer, not a sole layer; multi-layer defense in §3 protects even without HRoT. |

### 10.7 AI-Specific Risks

| Finding | Response |
|---|---|
| **F-14.** *AI is used to write watchdog logic and is prompt-injected to relax a check.* | Watchdog logic is not AI-generated in v0; deterministic code; changes require security-code-review. |

### 10.8 Operational Risks

| Finding | Response |
|---|---|
| **F-15.** *False-positive Kernel alarms cause frequent isolations.* | Watchdog quorum + tunable thresholds + human-in-the-loop for policy-changing alarms; rehearsed. |
| **F-16.** *Ceremony fatigue leads to rushed recoveries.* | Rehearsals build muscle memory; runbooks scripted for safe automation; post-ceremony sign-off checklists. |

## 11. Adversarial Architect Review

| Attack path | Design response |
|---|---|
| **A-1.** Compromise Kernel + one watchdog simultaneously and lie in concert. | Quorum of 2 out of 4 watchdogs; you must compromise ≥ 3 independent engines to silence the alarm. |
| **A-2.** Insider tampers with the release-hash registry the moment before deployment. | Registry updates ceremony-controlled; two-party attestation; post-deploy verification against Z0-anchored public key. |
| **A-3.** Cloud compromise substitutes the Kernel image after signing. | Boot chain measures the loaded image against registry; substitution alarms unless the attacker also updates the registry (which requires ceremony). |
| **A-4.** Insider disables the beacon publisher. | Beacon absence is an alarm; automatic isolation of the silent instance. |
| **A-5.** Supply-chain compromise of a Kernel dependency causes silent misbehavior. | RIV includes library hashes; unexpected hash triggers alarm; SBOM matches expected; SLSA-3+ attestation. |
| **A-6.** Prompt-inject a human operator via a chat interface to accept a bad ceremony. | Ceremony steps are scripted with clear on-screen hashes to verify; verification tool independent from any AI chat. |
| **A-7.** Long-term persistent attacker slowly corrupts state via legitimate-seeming ceremonies. | Ceremony log is Layer-A + Layer-B audited; auditor visibility; drift-monitor compares state trajectory against expected baselines. |
| **A-8.** Compromised Kernel triggers a fake alarm to force a recovery to an attacker-prepared image. | Recovery uses release-registry images verified against Z0-anchored key; alarm cannot select the recovery image; ceremony participants verify by hash. |

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

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

**The watchdog quorum consensus mechanism.** Reason: it's the single point where "silent compromise → alarm" is decided. If an attacker can subvert quorum — either by suppressing enough watchdogs, or by corrupting the alarm channel, or by making legitimate alarms look like noise — they turn all of §6 into decoration.

**Redesign response.**

1. **Watchdogs run on distinct engines, distinct signing keys, distinct storage substrates**. Any one watchdog silence is not a quorum failure. Compromising the quorum requires compromising ≥ 3 independent engines with distinct SVIDs, distinct storage backends, distinct code paths.
2. **Alarm channel diversity.** Watchdogs raise alarms via *two* independent channels: NATS control bus (primary) and Storage-Engine-mediated PostgreSQL row insert (secondary). Suppression of both requires compromising both control-plane and control-plane storage.
3. **External alarm mirror.** Deployments MAY subscribe alarms to an external notification target (email, Slack, PagerDuty) via Telemetry Engine's opt-in egress. This provides a *fifth* independent alarm path outside the AEGIS deployment, mitigating cloud-wide compromise. Off in air-gap.
4. **Alarm noise reduction is done by the Auditor role, not by the Kernel or watchdogs.** An attacker cannot bury alarms in noise by tuning suppression settings inside the Kernel — those settings live in the ceremony-controlled catalog.
5. **False-negative red-teaming.** Recovery Engine periodically injects synthetic Kernel-integrity-drift events into a test tenant; watchdogs must alarm on schedule; failure to alarm is itself an alarm. This is a live canary against watchdog degradation.
6. **Second attack target after redesign:** the **Recovery Engine's own runbook**. If Recovery is compromised, it could restore to attacker-controlled state. Response: recovery ceremonies are multi-party; the Recovery Engine cannot unilaterally restore anything privileged — every restore step is a Kernel-mediated capability with 4-eyes.

Repeated: another candidate: the **release-hash registry**. See A-2 response. Registry is ceremony-controlled + Z0-signed + drift-monitored.

No further high-impact silent-compromise vector identified at this abstraction.

## 13. Decisions

### D-13-1. Four-layer defense with watchdog quorum

- **Advantages.** Multiple independent detection paths; no single-layer failure is silent.
- **Disadvantages.** Complexity; four coordinated systems.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** Small (beacons and sample verification).
- **Operational Complexity.** *Moderate.*
- **Maintainability.** Positive — layers are cleanly separated.
- **Scalability.** Positive.
- **Alternatives.** *Single-watchdog design.* Concentrates trust; rejected by adversarial review. *No runtime integrity.* Rejected — boot-only integrity is insufficient.
- **Reason.** Mandates #1 + #2 + #10.

### D-13-2. Watchdogs embodied in existing engines, not a new engine

- **Advantages.** Uses existing SVIDs and code paths; watchdog perspectives are naturally different (Audit, Policy, Identity, Evidence); no new deployment surface.
- **Disadvantages.** Cross-engine coordination for quorum.
- **Security Impact.** *Positive.*
- **Performance Impact.** Small.
- **Operational Complexity.** Neutral.
- **Maintainability.** Positive.
- **Scalability.** Positive.
- **Alternatives.** *Dedicated Watchdog Engine.* One more engine; concentrates the "verify Kernel" concern in a single component that then becomes an attack target. Rejected.
- **Reason.** Distributed trust extends to watchdogs.

### D-13-3. Secure Recovery Mode with mandatory Recovery Integrity checks

- **Advantages.** Every recovery answers the five integrity questions; auditable; ceremonies rehearsed.
- **Disadvantages.** More runbook overhead.
- **Security Impact.** Strongly positive.
- **Performance Impact.** N/A.
- **Operational Complexity.** Higher — mitigated by scripting.
- **Maintainability.** Positive.
- **Scalability.** N/A.
- **Alternatives.** *Ad-hoc recovery.* Rejected — mandate #10.
- **Reason.** Recovery must not be its own SPOT.

### D-13-4. Diverse alarm channels + external mirror

- **Advantages.** Alarm suppression is structurally harder; external mirror survives internal compromise.
- **Disadvantages.** External mirror opt-in complicates air-gap.
- **Security Impact.** Strongly positive.
- **Performance Impact.** Neutral.
- **Operational Complexity.** Moderate.
- **Maintainability.** Positive.
- **Scalability.** Positive.
- **Alternatives.** *Single channel.* Rejected.
- **Reason.** Addresses the adversarial-review first target.

## 14. Open Questions

- Q-13-1. Beacon cadence defaults per topology (5s/30s/60s). Resolved in ARCH-16.
- Q-13-2. HRoT adoption timeline per topology. Resolved in ARCH-16.
- Q-13-3. Transparency-log-style public witness for release hashes. Roadmap.

## 15. Change Log

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