# AEGIS — Trust Boundary Diagram

- **Document ID:** ARCH-05
- **Phase:** B.1 — Structural Foundations
- **Status:** Draft for review (post independent architecture review)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect
- **Depends on:** ARCH-01 through ARCH-04, CLAUDE.md
- **Consumed by:** ARCH-06 through ARCH-16

---

## 1. Purpose

Define every trust boundary in AEGIS and specify what is required to cross each one. In the post-Phase-A architecture, boundaries are no longer traversed by direct peer-to-peer engine calls — every crossing goes through the **Security Kernel** (ARCH-06). This document defines the boundaries, the crossings, and the enforcement contract each crossing must satisfy.

## 2. Boundary Model

AEGIS is composed of **trust zones** separated by **boundaries**. A zone is a set of components sharing an identity anchor and a threat expectation. A boundary is where two zones meet; every crossing is a *sensitive operation* under the constitutional contract (Authorized, Logged, Auditable, Traceable, Recoverable).

Zones:

| Zone | Members | Trust posture |
|---|---|---|
| **Z0 — Root of Trust** | HSM/KMS, offline signing ceremony material, root CA | Highest; hardware-anchored where possible |
| **Z1 — Security Kernel** | Kernel processes, capability broker, policy enforcement point, audit gateway | High; small footprint, verifiable, mediates all Z2↔Z2 traffic |
| **Z2 — Engines** | AI, Policy, Identity, Audit, Detection, Response (deferred), Storage, Recovery, Telemetry, Connector, Plugin, Normalization, Case | Trusted per-engine, isolated from each other |
| **Z3 — Data Planes** | ClickHouse (events), PostgreSQL (control), Kafka/Redpanda (ingest bus), NATS (control bus), Object store (archival) | Trusted operators; access mediated |
| **Z4 — Sandboxes** | Plugin runtimes, AI model runtimes when running untrusted models | Untrusted; isolated |
| **Z5 — Tenant Actors** | Analysts, admins, service accounts inside a tenant | Authenticated + authorized per operation |
| **Z6 — External Systems** | IdP, hosted AI providers, threat-intel feeds, cloud APIs, log sources | Untrusted by default; contract-bound |
| **Z7 — Internet / Public Networks** | Anywhere outside the deployment perimeter | Hostile |

## 3. Boundary Enforcement Contract

Every boundary crossing MUST satisfy the following. Deviation requires an explicit, audited exception with Owner approval — no ad-hoc bypasses.

| # | Requirement | Enforced by |
|---|---|---|
| **BC-1** | Both endpoints are cryptographically identified (mTLS or signed message) | Cryptographic Identity Model (ARCH-09) |
| **BC-2** | The caller presents a **capability** authorizing the specific operation on the specific resource | Capability Model (ARCH-08) |
| **BC-3** | The Security Kernel evaluates policy at the crossing | Security Kernel (ARCH-06) |
| **BC-4** | Data classification is attached to the message; downstream honors it | Policy Engine + Kernel |
| **BC-5** | The crossing produces a Layer-A audit event (hash-chained) | Audit Engine via Kernel |
| **BC-6** | A trace ID propagates through the crossing | Kernel + telemetry contract |
| **BC-7** | Fail-secure: if any of BC-1..BC-5 cannot be verified, the operation fails closed | Kernel |
| **BC-8** | Cross-tenant crossings additionally require an active break-glass grant | Kernel + Identity Engine |
| **BC-9** | Crossings involving L3 (hosted AI) additionally require an active tenant consent record | Kernel + Policy Engine |
| **BC-10** | Every crossing has a **budget** (rate + concurrency + payload-size) that Kernel enforces | Kernel |

## 4. Boundary Map

Boundaries labeled `Bxx` and described by direction, purpose, and any special requirement beyond the base BC-1..BC-10.

### 4.1 Ingress from Untrusted Networks

- **B-01 — Z7 → Connector Engine (Z2).** Log sources push/pull. Additional: TLS 1.3 termination, per-source auth, rate limits, DoS controls, prompt-injection quarantine on content.
- **B-02 — Z7 → Identity Engine (Z2).** IdP callbacks (OIDC). Additional: strict URL allow-list, replay protection, audience-bound tokens.
- **B-03 — Z7 → Next.js UI → API gateway (Z2).** Human sessions. Additional: MFA per policy, session binding, CSRF/XSS defenses per ARCH-12.
- **B-04 — Z7 → Support ingress (Z2).** Support break-glass. Additional: consent capture, recording, time-boxed capability.

### 4.2 Engine ↔ Kernel

- **B-10 — Any Z2 engine → Z1 Kernel.** Every privileged request. Additional: request signed by engine identity; capability presented; response signed by Kernel.
- **B-11 — Kernel → Engine (callback/notification).** Kernel returns decisions and event notifications. Additional: signed responses; engine verifies Kernel identity.
- **B-12 — Kernel → Audit Engine (Z2).** Layer-A audit writes. **Special:** MUST NOT be blocked by Audit; if Audit is unreachable, Kernel MUST fail closed on the mediated operation (per D-03-3) but MUST NOT stall on Audit's Layer-B path.

### 4.3 Engine ↔ Data Plane

- **B-20 — Storage Engine (Z2) → PostgreSQL (Z3).** Control-plane persistence. Additional: least-privileged DB role per operation; connection-level tenant context.
- **B-21 — Storage Engine (Z2) → ClickHouse (Z3).** Event-plane persistence and query. Additional: tenant-scoped query; result-size caps per capability; exfil detection hooks.
- **B-22 — Connector/Ingest → Kafka (Z3).** Ingest bus write. Additional: per-topic ACLs; per-record integrity hash.
- **B-23 — Kernel → NATS (Z3).** Control-plane RPC and realtime. Additional: mTLS to NATS; subject-level authz.
- **B-24 — Recovery Engine → Object Store (Z3).** Backup/restore. Additional: keys from separate KEK hierarchy (AS-K-08); immutability policy on target.

### 4.4 Engine ↔ Engine (via Kernel)

Peer-to-peer engine calls are **not permitted**. Every engine-to-engine interaction is expressed as:

- **B-30 — Engine A → Kernel → Engine B.** The Kernel evaluates capability, policy, classification, and rate/quota before forwarding. Both legs use B-10 rules.

There is one exception, tightly bounded:

- **B-30x — Event streaming via NATS/Kafka.** Engines may consume from published topics, but topics themselves are Kernel-mediated resources: only the Kernel grants publish capabilities. Consumer identity is enforced by NATS/Kafka ACLs bound to engine mTLS identity. The Kernel is not on the hot path for each message; it is on the hot path for authorization and for each capability change.

### 4.5 Engine ↔ Sandbox

- **B-40 — Plugin Engine (Z2) → Plugin Sandbox (Z4).** Plugin invocation. Additional: per-plugin capability set; egress network policy; filesystem policy; resource limits; audit on every capability use inside sandbox. Detailed in ARCH-14 / ARCH-15 (Phase B.3).
- **B-41 — AI Engine (Z2) → Model Runtime (Z2 or Z4).** L1 rules run in-process; L2 local models run in a hardened runtime (Z2 if AEGIS-managed, Z4 if untrusted); L3 calls are *egress* to Z6.

### 4.6 Egress to External Systems

- **B-50 — AI Engine → Hosted AI Provider (Z6).** L3 calls. Additional: consent check, classification check, redaction manifest signed and stored, egress egress-allow-list enforced, cost budget check, response signature/verification when available. L3 is **off by default** for HR classification.
- **B-51 — Connector Engine → Cloud audit log source (Z6).** Pull ingest. Additional: least-privileged cloud IAM; per-tenant credential vault.
- **B-52 — Identity Engine → IdP (Z6).** OIDC token exchange. Additional: audience-bound, PKCE, JWKS pinning.
- **B-53 — Recovery Engine → Backup target (Z6/Z3).** Additional: bundle signing (AS-K-08); immutability policy.
- **B-54 — Telemetry Engine → optional external observability (Z6).** Additional: opt-in per tenant; scrubber pipeline; disabled in air-gap.

### 4.7 Zone Roots

- **B-60 — Z1 Kernel bootstrap ← Z0 Root of Trust.** Kernel identity is signed by the offline root; documented ceremony; multi-party signing; long-lived + rotation ceremony (ARCH-09/11).
- **B-61 — Engine bootstrap ← Z1 Kernel.** Engine identities are signed by the Kernel-operated intermediate CA on first attestation. First-boot attestation binds to hardware or Kubernetes attestation where available (Future Readiness: TEE/HRoT).

## 5. Immutable Event Sourcing at Boundaries

Applying constitutional constraint #4: at any boundary crossing that carries a security event or derivative, the crossing MUST NOT overwrite the source. The receiver stores a reference (`event_id + integrity_hash`) and, if it derives from the source, stores the derivation as an additive derived object with a link back. Detailed rules in ARCH-11 (Evidence Chain, B.2).

## 6. Data Classification Propagation

Every message crossing a boundary MUST carry a classification. Downstream MUST enforce classification-appropriate handling:

- **P (Public)** — no restriction.
- **I (Internal)** — no egress to Z6 without explicit capability.
- **C (Confidential)** — no L3 by default; egress to Z6 requires explicit capability + audit.
- **R (Restricted)** — no L3 without per-tenant consent + explicit capability; break-glass required for cross-tenant reach.
- **HR (Highly Restricted)** — L3 forbidden by default; L2 requires stricter Safety Layer validation; access requires 4-eyes on the capability grant path.

Downgrade of classification requires an audited policy decision; the Kernel does not permit silent downgrade.

## 7. Independent Architecture Review

I sat down as an independent Principal Security Architect and attacked this boundary model. The findings and revisions:

### 7.1 SPOFs and Bottlenecks Found

| Finding | Original | Revised |
|---|---|---|
| **F-1.** *Kernel as SPOF: if Kernel goes down, all boundary crossings halt, so the whole platform halts.* | Original design was strict "all crossings synchronous via Kernel." | Split synchronous mediation (BC-1..BC-10 verification) from **capability caching**: engines may cache short-TTL capability tokens signed by the Kernel and re-use them until expiry or revocation notification arrives via NATS. Kernel restarts are transparent for the cache window. Kernel is HA (active-passive minimum, quorum for hosted). |
| **F-2.** *Ingest hot-path via Kernel bottlenecks at high event volume.* | Original design routed every ingest handshake through Kernel. | Kernel authorizes the *topic publish capability* once per source; per-event authorization is enforced by Kafka/Redpanda ACLs bound to the source's cryptographic identity. Kernel is on the control path, not the data path per event. |
| **F-3.** *Audit is downstream of Kernel; if Audit is down, Kernel fails closed on every operation, so Audit outage = platform outage.* | Original design coupled Kernel to Audit synchronously. | Kernel writes Layer-A entries to a **local append-only integrity ring** (per-Kernel-instance, small, on fast local storage) synchronously. Layer-A ring is replicated to the Audit Engine asynchronously. Audit Engine's Layer-B archival is an even later hop. The Kernel needs only its local ring to be healthy for the fast path; loss of the Audit Engine degrades archival, not availability. |

### 7.2 Privilege Escalation Paths Considered

| Finding | Response |
|---|---|
| **F-4.** *Engine A obtains a capability legitimately, then re-uses it to act on behalf of a different tenant.* | Capabilities are tenant-scoped and Kernel enforces `tenant_id` match at BC-3. Cross-tenant capability grants require break-glass (BC-8). |
| **F-5.** *Compromised Kernel = compromised platform.* | Kernel is deliberately small (see ARCH-06). Its identity is Z0-anchored. Its behavior is auditable independently: any capability grant produces a signed Layer-A record verifiable outside the Kernel. Kill-switch: revoke Kernel's issuance certificate at Z0 to freeze all new grants. |
| **F-6.** *An engine caches a stale capability past its intended revocation.* | Two mechanisms: (a) short TTL (default ≤ 5 min for privileged capabilities; ≤ 60 min for low-privilege); (b) revocation broadcast on NATS with cryptographic revocation-list update; engines refuse cached tokens once a revocation is seen. Data-plane ACLs are the second layer if a token slips past. |
| **F-7.** *Plugin Engine grants a plugin a capability broader than requested.* | Every capability grant produces an audit event; over-grant is detectable by policy on the Kernel side and by anomaly detection on the Detection Engine side. Kernel refuses grants for capabilities the caller does not itself hold + the delegation right for. |

### 7.3 Trust-Boundary Violations Considered

| Finding | Response |
|---|---|
| **F-8.** *Telemetry Engine leaks tenant secrets to external observability.* | B-54 is opt-in; scrubber pipeline is on the boundary; disabled in air-gap; scrubber has its own audited capability. |
| **F-9.** *Normalization writes back into raw and violates immutable event sourcing.* | Raw store is write-once-per-event; Normalization writes to a separate normalized store keyed by `raw_ref`. Storage Engine enforces this at the DB level (append-only tables + no UPDATE grant on raw). |
| **F-10.** *AI Engine calls L3 with tenant secrets embedded in a prompt.* | Redaction manifest is required by BC-9 and verified by the AI Safety Layer (ARCH-14) before egress. Manifest is stored (AS-M-04). |

### 7.4 Scalability Bottlenecks Considered

| Finding | Response |
|---|---|
| **F-11.** *Kernel becomes a global mutex on capability issuance under load.* | Capability issuance is per-tenant stateless verification against Kernel state; horizontally scalable behind consistent hashing on `tenant_id`. Kernel is a set of processes, not a single process. |
| **F-12.** *NATS revocation broadcast fails to reach all engines during partition.* | Engines default to *shorter* TTLs when heartbeat with Kernel is lost; on total partition, engines revert to the last-known-good policy set within their local ring's replay window and only for read-scope capabilities. Write capabilities expire immediately on partition. |
| **F-13.** *Cross-tenant queries by MSSP operator (future) create N² policy checks.* | Batched-capability model: MSSP operator holds a *batch capability* proving eligibility across a set of tenants; the Kernel verifies scope once per batch, not per query. Design placeholder for Phase 3. |

### 7.5 Supply Chain Risks Considered

| Finding | Response |
|---|---|
| **F-14.** *Compromised NATS/Kafka client library injects into control plane.* | mTLS + signed messages beyond mTLS; message integrity verified by Kernel/engine on receipt, not trusted from library. |
| **F-15.** *Compromised OCSF-mapping library taints normalization output.* | Raw preserved (F-9); Normalization output flagged with `normalization_version` and library provenance; re-normalization is possible from raw. |

### 7.6 AI-Specific Risks Considered

| Finding | Response |
|---|---|
| **F-16.** *An L3 provider records prompts for training and leaks sensitive data long-term.* | Every L3 call carries a signed redaction manifest; providers must offer zero-data-retention modes (Vercel AI Gateway offers this; direct providers may also); for HR, L3 is forbidden by default; for R, L3 requires tenant consent event; per-vendor policy set in Policy Engine. |
| **F-17.** *Model runtime (Z4) tries to exfiltrate via unusual egress.* | Runtime has an explicit egress policy: no network by default; only Kernel-mediated calls out. Enforced by Kubernetes NetworkPolicy + inner-sandbox firewall. |

### 7.7 Operational Risks Considered

| Finding | Response |
|---|---|
| **F-18.** *Boundary contract too complex for operators to reason about.* | Contract is expressed as a small set of BC-1..BC-10 rules; every violation surfaces the failing BC number in the audit event. Runbook documents each. |
| **F-19.** *Cache TTLs make debugging revocation issues hard.* | Every engine exposes `/capabilities` introspection endpoint (auth-required) that lists cached capabilities with expiry and provenance. Detectable operationally. |

### 7.8 Hidden Assumptions Surfaced

| Assumption | Handling |
|---|---|
| Kernel HA topology is available in single-node deployments. | Single-node deployments run Kernel as an in-process primary with a warm standby process; RTO for Kernel restart target ≤ 1s; Recovery Engine handles this per ARCH-16. |
| NATS is reachable for revocation broadcast. | If not, engines default to short TTLs and read-only degraded mode. Documented degraded-mode matrix in ARCH-16. |
| Engines can be trusted to enforce classification once received. | Boundaries enforce structurally, but engines must too; SAST rules and property tests in ARCH-12 ensure this. |
| Kafka/Redpanda ACLs correctly bind to engine identity. | Verified by integration tests; documented in ARCH-16. |

## 8. Decisions

### D-05-1. Kernel-mediated boundaries with capability caching

- **Advantages.** Structural enforcement of the Security Pipeline; auditable at every crossing; capability model allows fine-grained control; caching removes the Kernel from every per-message hot path.
- **Disadvantages.** Complexity is higher than direct peer calls; caching adds a small revocation-latency window.
- **Security Impact.** *Strongly positive.* Eliminates a large class of "we forgot to check policy here" bugs.
- **Performance Impact.** *Neutral to positive.* Hot paths bypass Kernel via cached capabilities + broker ACLs; cold paths pay one Kernel round-trip.
- **Operational Complexity.** *Higher* than direct calls; mitigated by clear contracts and introspection.
- **Maintainability.** *Positive* — one enforcement point, small surface.
- **Scalability.** *Positive* — Kernel is stateless-verified, horizontally scaled per tenant partition.
- **Alternative Designs.** *(a) Direct peer calls with per-service policy* — brittle, drift-prone; rejected. *(b) Service-mesh-only policy (Istio/Linkerd sidecar)* — better than nothing but not fine-grained enough for capabilities; sidecars can be co-adopted for network policy but not as the primary policy point. Rejected as primary. *(c) Kernel-in-every-engine as a library* — creates 13 places to keep in sync; rejected.
- **Reason for Final Selection.** Kernel-as-mediator best fits the microkernel principle and the Security Pipeline requirement; caching addresses the SPOF/bottleneck concerns without compromising enforcement.

### D-05-2. Capability caching TTLs: ≤5 min for privileged, ≤60 min for low-privilege

- **Advantages.** Bounds the revocation latency to a small, defensible window; independent of NATS reachability; simple to reason about.
- **Disadvantages.** Some operations may be re-authorized more often than strictly needed.
- **Security Impact.** *Positive.* Bounded exposure.
- **Performance Impact.** *Small overhead* per TTL expiry; well under 1% of privileged-op budget in typical loads.
- **Operational Complexity.** Low.
- **Maintainability.** High.
- **Scalability.** High.
- **Alternatives.** *No caching* — Kernel becomes SPOF; rejected. *Longer TTLs* — increases revocation window; rejected. *Client-driven refresh* — adds complexity; rejected.
- **Reason.** Right balance for the 2026-era threat profile; revisit at v1.

### D-05-3. Layer-A audit via per-Kernel local integrity ring, replicated asynchronously

- **Advantages.** Kernel is not blocked by Audit Engine health; still tamper-evident locally; asynchronous replication concentrates durability in the Audit Engine.
- **Disadvantages.** Loss of Kernel-instance local storage before replication loses the tail records for that instance.
- **Security Impact.** *Positive* net; loss window is bounded and detectable via chain gap.
- **Performance Impact.** *Positive* — local write is sub-ms.
- **Operational Complexity.** Moderate — Kernel instances have durable local storage; documented in ARCH-16.
- **Maintainability.** Moderate.
- **Scalability.** *Positive.*
- **Alternatives.** *Synchronous Layer-A to Audit Engine* — creates the exact bottleneck we rejected in F-3; rejected. *No local ring, direct to Kafka* — Kafka failure blocks Kernel; rejected.
- **Reason.** Preserves both availability and integrity; the tradeoff (bounded tail loss on Kernel-instance failure) is acceptable given HA topology and Kernel monitoring.

## 9. Open Questions

- Q-05-1. Kernel HA topology in single-node deployments (in-process warm standby vs external supervisor). Resolved in ARCH-06 + ARCH-16.
- Q-05-2. Service-mesh adoption for the NetworkPolicy layer (Linkerd is a candidate for its minimal footprint). Resolved in ARCH-16.
- Q-05-3. Precise capability TTL defaults per named capability. Resolved in ARCH-08.

## 10. Change Log

- **0.1 (2026-07-10)** — Initial draft after independent architecture review.