# AEGIS — Multi-Stage Decision Pipeline, Distributed Trust, and Adaptive Trust

- **Document ID:** ARCH-11
- **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-07, ARCH-08, ARCH-10
- **Consumed by:** ARCH-12 through ARCH-16

---

## 1. Purpose

Formalize the pipeline every security-consequential decision in AEGIS traverses; specify the Runtime Risk Engine (E-14); specify Adaptive Trust (dynamic trust scoring); and specify Continuous Validation (no permanent authorization). Together these implement elevation mandates #3 (Distributed Trust), #4 (Multi-Stage Decision Pipeline), #7 (Risk Engine), #8 (Adaptive Trust), and #9 (Continuous Validation).

Cardinal principle from the constitution: **AI advises. Platform decides.**

## 2. Scope

A **security-consequential decision** is any operation that:
- alters state visible to a security workflow (case, timeline, finding, policy, rule, capability grant), OR
- affects trust posture (identity, cert, RBAC, capability), OR
- crosses a classification boundary in either direction (egress or elevated read), OR
- produces an artifact treated as evidence (Layer-A record, signed bundle).

Every such decision passes through the pipeline in §3. Other operations (e.g., simple health probes, telemetry writes to Telemetry Engine's own store) do not require the full pipeline but are still audited.

## 3. The Pipeline

### 3.1 Stages

Eleven stages, in order. Each stage has a **question** it answers, an **owning engine**, an **input contract**, and an **output contract**.

| # | Stage | Question | Owner | Output |
|---|---|---|---|---|
| **S-1** | **Evidence** | *What did we observe?* | Evidence Engine (E-15) | `EvidenceBundle` with provenance |
| **S-2** | **Confidence** | *How much should we trust this evidence?* | Evidence Engine | `ConfidenceReport` per evidence element and aggregate |
| **S-3** | **Policy** | *Is this operation permitted at this classification for this actor?* | Policy Engine (OPA/Rego) | `PolicyDecision` |
| **S-4** | **Risk** | *What is the risk score of proceeding, given context?* | Runtime Risk Engine (E-14) | `RiskScore + ThreatContext` |
| **S-5** | **Business Impact** | *If we proceed, what does it change for the tenant?* | Risk Engine + Recovery Engine | `BusinessImpactEstimate` |
| **S-6** | **Recovery Impact** | *Is this reversible? At what cost?* | Recovery Engine | `RecoverabilityAssessment` |
| **S-7** | **Approval Requirement** | *Who must approve? How many? Break-glass?* | Kernel (from Policy) | `ApprovalPolicy` |
| **S-8** | **Execution** | *Perform the operation.* | The engine that owns the resource (e.g., Case Engine, Storage Engine) | `ExecutionResult` |
| **S-9** | **Verification** | *Did execution produce what was intended?* | Owning engine + Evidence Engine | `VerificationReceipt` |
| **S-10** | **Audit** | *Record everything.* | Kernel + Audit Engine | `AuditRecord` (Layer-A + Layer-B) |
| **S-11** | **Continuous Monitoring** | *Was the decision correct in hindsight? Adjust trust scores.* | Risk Engine + Detection Engine | `TrustAdjustments` |

### 3.2 Pipeline invariants

- **In-order.** No stage may be skipped for security-consequential decisions. Missing stage = fail-secure.
- **Composable.** Every stage's output is a signed structure; the composed *DecisionRecord* carries all stage outputs.
- **Independently verifiable.** A third party with the public keys can verify the DecisionRecord end-to-end, without access to the platform.
- **Immutable.** Once produced, DecisionRecords are append-only under the Evidence Chain (ARCH-12).
- **AI never gates.** AI Engine produces advisory input to S-1 (evidence surfacing) and can *propose* a recommendation, but S-3..S-7 are non-AI engines. The final green-light in S-7 is *always* a human or a policy-authorized non-AI approver.

### 3.3 Reduced-form pipeline for read operations

Read-only operations (Read-Case, Read-Findings, etc.) traverse S-1 → S-2 → S-3 → S-7 → S-8 → S-10. Risk, Business Impact, Recovery Impact are shortcut with defaults; Continuous Monitoring adjusts trust for anomalous read patterns.

## 4. Runtime Risk Engine (E-14) Specification

### 4.1 Purpose
Compute a real-time risk score for each pipeline invocation, contextualized by tenant, asset criticality, threat landscape, evidence trust, and observed platform state. The Risk Engine is a *first-class* engine, not a subroutine of Policy or AI.

### 4.2 Responsibilities

1. **Dynamic Risk Score** — numeric 0–100 for a proposed operation, computed from a set of signals with published weights.
2. **Context Awareness** — join with recent detections, active incidents, external threat-intel state (post-v0), and platform posture.
3. **Threat Escalation** — increase the risk baseline when specific triggers are observed (large deviation from source baseline, correlated activity across tenants for MSSP, kill-chain progression, etc.).
4. **Asset Criticality** — per-tenant asset criticality catalog (post-v0 full inventory; v0 accepts a manual criticality tag).
5. **Business Impact** — weighted composite of asset criticality + recoverability + tenant-declared sensitivity.
6. **AI Confidence Adjustment** — takes the AI's self-reported confidence, adjusts down by trust-score of the AI provider and the evidence, then reports an *adjusted* confidence used downstream.
7. **Adaptive Response Level** — output a ceiling for what response actions are permitted at this risk score (v0 is advisory only, but the ceiling determines UI framing and approval requirements).

### 4.3 Interfaces

Every risk score is a signed structure:

```
RiskScore {
  request_id       : UUID
  tenant_id        : TenantId
  score            : uint8            // 0..100
  components       : {
     evidence_confidence,
     source_trust,
     asset_criticality,
     recoverability_penalty,
     threat_context,
     ai_confidence_adjusted,
     anomaly_score
  }
  weights_version  : string           // signed weights catalog reference
  triggers         : [Trigger]        // what pushed the score up/down
  ceiling_action_level : enum
  timestamp        : Time
  signature        : Ed25519Sig       // Risk Engine SVID
}
```

### 4.4 Recovery-First answers

1. *How does it fail?* Slow response; wrong score; over-cautious ceiling; under-cautious ceiling.
2. *Detection.* Latency SLO; distribution of score components; comparison against baseline; sanity-check invariants (e.g., no score < 0, no ceiling above Kernel policy).
3. *Initiation.* Automatic fallback to a conservative default score (high risk = fail-secure) on evaluation timeout; human runbook for score-model drift.
4. *Automated?* Yes for transient; yes for fallback; **no** for weight-catalog changes (those require ceremony — see §7).
5. *Rollback?* Weight-catalog versioned; instant rollback via version pin.

### 4.5 v0 scope

- Baseline scoring model with a small, published, weighted signal set.
- Manual asset-criticality tag per tenant (auto-inventory in Phase 2).
- Trust-scoring loop (§6) partially implemented; full adaptive learning at v1.

## 5. Distributed Trust — how decisions are composed

### 5.1 Model

Every stage produces a signed sub-decision. The Kernel composes them into the DecisionRecord. The **composition rule** is:

- **Any single sub-decision may deny.** Any engine can veto (Policy denies, Risk denies, Evidence denies for missing citations, Recovery denies for irreversible-with-inadequate-approval).
- **All required sub-decisions must allow.** Positive requires unanimity across required stages.
- **Optional advisory inputs.** AI Engine's opinion is advisory; its rejection does not veto; its acceptance does not grant.
- **Escalation on disagreement.** If AI recommends allow but Risk or Evidence disagrees, the disagreement is presented to a human approver with all rationales.

### 5.2 Consequence

A single-engine compromise cannot silently produce a wrong-allow decision. To fake an "allow", an attacker must forge signatures from *every* required stage — each held by an independently-attested engine with its own SVID. This is the operational form of Zero SPOT for decisions.

### 5.3 Example — Policy modification

Modify-Policy is high-risk; every stage runs:
- **S-1 Evidence**: what is being changed and why?
- **S-2 Confidence**: is the change traceable to a case / an audit finding / an admin request?
- **S-3 Policy**: is the actor entitled? (yes, if role + break-glass)
- **S-4 Risk**: does this change loosen policy? (score-inflating)
- **S-5 Business Impact**: what breaks if wrong?
- **S-6 Recovery Impact**: can we revert? (yes, via versioning)
- **S-7 Approval**: 4-eyes required
- **S-8 Execution**: Policy Engine writes new version
- **S-9 Verification**: policy corpus reloads; unit tests re-run against the new version
- **S-10 Audit**: Layer-A + Layer-B, high severity
- **S-11 Continuous Monitoring**: watches for behavior anomalies caused by the change

## 6. Adaptive Trust

### 6.1 Trust Vectors

Every trust-bearing entity has a **Trust Vector** — a small structured record of trust across multiple dimensions:

| Dimension | Applies to | Signal |
|---|---|---|
| **Behavior** | Engines, plugins, humans, sources | Deviation from baseline |
| **Integrity** | Engines, plugins, models | Attestation freshness + integrity checks |
| **Verification** | AI outputs, sources | Rate of successful downstream verification |
| **History** | Sources, AI providers, plugins | Long-term reliability record |
| **Cryptographic Validation** | Any signed artifact producer | Signature validity, key freshness |
| **Observed Risk** | Everything | Rolling risk-score exposure |

### 6.2 Trust Decay and Recovery

- Trust decays over time absent positive signals; forces revalidation.
- Trust decays sharply on negative signals (integrity failure, verification failure, unusual behavior).
- Trust recovers slowly on sustained positive signals.
- Trust below a threshold triggers a policy-defined action (require additional approval, refuse L3 for that tenant, quarantine plugin, halt source, etc.).

### 6.3 Consumers of Trust Vectors

- **Policy Engine** uses trust vectors as one input alongside classification and role.
- **Risk Engine** weights signals in the score by trust of the signal source.
- **AI Engine** adjusts routing (L2 fallback when L3 provider's trust drops).
- **Detection Engine** raises sensitivity when local trust drops for a source.

### 6.4 Storage and Governance

- Trust Vectors are stored in the control-plane (PostgreSQL via Storage Engine), versioned, signed by the Evidence Engine (E-15) on update.
- Changes to weighting are ceremony-controlled (§7).
- Trust reset (e.g., after a legitimate ownership change) requires break-glass.

## 7. Continuous Validation

### 7.1 Principles

1. **No authorization is permanent.** All capabilities have TTL (ARCH-08 §7); sessions have TTL; workload identities have TTL; roles have review cadence.
2. **Every trust relationship is revalidated.** Engines re-attest; humans re-consent to sensitive contexts; L3 providers re-verify their configuration (e.g., zero-data-retention mode).
3. **Signals decay.** Positive validations lose weight over time; negative signals retain weight until affirmatively cleared.
4. **Silent trust is never permitted.** Any trust that has not been revalidated within its window is *not* trust — it defaults to a stronger challenge (re-attestation, MFA prompt, capability re-issuance).

### 7.2 Validation Windows (defaults; policy-configurable)

| Trust relationship | Default window | Notes |
|---|---|---|
| Engine attestation | 24 h | Re-attest to Kernel |
| Kernel identity | 90 d | Ceremony re-issue |
| Human session | 8 h | Re-auth for privileged ops on 2 h |
| Capability token | ≤ 60 min (broad read) / ≤ 5 min (privileged) / ≤ 60 s (one-shot) | ARCH-08 |
| L3 provider trust | 30 d | Provider config verification (zero-data-retention, etc.) |
| Plugin trust | 24 h | Attestation + capability confirmation |
| Model trust | Per release | Provenance re-verified on load |
| Source trust | Rolling 7 d window | Behavior baseline + volume |
| Tenant BYOK trust | Per rotation | Key ceremony |

### 7.3 The "silent re-trust" trap and mitigation

The subtle failure mode: a stale trust is treated as valid because "it hasn't been revoked." Continuous Validation flips this: **trust that hasn't been recently reasserted is degraded to null**, forcing an explicit reassertion. Detection Engine watches for entities whose reassertion cadence slips.

## 8. Weight-Catalog Ceremony

Any change to Risk-Engine weights, Trust-Vector dimensions, or validation windows is governed:
- Proposed change signed by a Security Engineer.
- Reviewed by a second Security Engineer.
- Approved by Owner + Auditor.
- Ceremony records the change to a signed catalog version; Risk Engine pins to a specific version at each request.
- Rollback is instant via version pin.

## 9. Independent Architecture Review

### 9.1 Hidden Assumptions

| Assumption | Handling |
|---|---|
| Every engine can respond within budget for every stage. | Per-stage timeout; timeout = deny (fail-secure). Latency SLOs published. |
| Trust vectors converge across replicas. | Trust Vector is a CRDT-style monotonic update where possible; explicit merge policy where not; documented. |
| Risk-Engine weights are actually right. | Weights are catalog-versioned and rehearsed against synthetic incidents; wrong weights are reversible; wrong-weight incidents feed §11 improvement loop. |

### 9.2 SPOFs

| Finding | Response |
|---|---|
| **F-1.** *Risk Engine down → pipeline halts.* | Fail-secure default: use last-known catalog + conservative score; alert; degraded-mode allows read-only ops only. |
| **F-2.** *Evidence Engine down → S-1/S-2 halt.* | Same fail-secure; raw data preserved; queued for later processing. |
| **F-3.** *Policy Engine down → all mediation halts.* | Already addressed in ARCH-06 §8 F-3: cached decisions + Kernel-side timeout. |

### 9.3 Privilege Escalation

| Finding | Response |
|---|---|
| **F-4.** *An engine spoofs a sub-decision signature.* | Each sub-decision signed by a distinct engine SVID; verification is cross-SVID; per-engine key compromise contained by identity scope. |
| **F-5.** *An engine chooses to omit a stage output to bias composition.* | Composition rule requires *all* required stages; missing stage = deny. Structural. |
| **F-6.** *Weight catalog changed to bias scoring toward allow.* | Ceremony + versioning + Auditor visibility + rollback; drift-monitor watches score distribution. |

### 9.4 Trust-Boundary Violations

| Finding | Response |
|---|---|
| **F-7.** *AI Engine's advisory turns de-facto authoritative through UI framing.* | UI must display each stage's contribution; specific text patterns forbid framing AI as "authoritative"; UX guidelines in ARCH-16. |
| **F-8.** *Adaptive trust punishes benign sources during a transient anomaly.* | Trust decay is bounded; sudden drops trigger a review by human before permanent policy change; recovery-slow-decay-fast rule reversed for tenants with documented context. |

### 9.5 Bottlenecks

| Finding | Response |
|---|---|
| **F-9.** *11-stage serial pipeline adds latency.* | Independent stages parallelised where causally allowed (S-3, S-4, S-5, S-6 can run in parallel once S-1/S-2 complete); target end-to-end p95 for non-blocking pipeline ≤ 1s excluding AI reasoning time. |
| **F-10.** *Every operation hits every engine.* | Only security-consequential ops (§2); read-only ops use reduced-form pipeline. |

### 9.6 Supply Chain

| Finding | Response |
|---|---|
| **F-11.** *OPA/Rego dependency vulnerability affects Policy Engine.* | Hash-pinned; ARCH-14/B.2 supply chain; Policy Engine replaceable per engine contract. |
| **F-12.** *A malicious catalog upload during ceremony.* | Ceremony requires multi-party; signed catalog; drift-monitor detects post-hoc. |

### 9.7 AI-Specific Risks

| Finding | Response |
|---|---|
| **F-13.** *Prompt injection influences AI's self-reported confidence.* | AI's self-report is adjusted by Risk Engine using out-of-band trust signals (§4.2 point 6); adjusted confidence is what downstream uses. |
| **F-14.** *AI outputs designed to pass Safety Layer but not Multi-Engine adjudication.* | Any single-gate defeat is insufficient; all required stages must concur (§5.1). |

### 9.8 Operational Risks

| Finding | Response |
|---|---|
| **F-15.** *Analysts fatigue on approvals.* | Reduce approvals to genuinely high-risk operations; tune weights to keep 4-eyes rare; auditor visibility on approval fatigue metric. |
| **F-16.** *Trust decay disables features unexpectedly.* | Advance warnings + revalidation reminders; UI surfaces trust posture. |

## 10. Adversarial Architect Review

Assuming full attacker capability set:

| Attack path | Design response |
|---|---|
| **A-1.** Compromise Risk Engine and lower risk scores globally. | Zero SPOT applies at the sub-decision layer: Risk Engine's signed RiskScore is one input; Policy + Evidence + Recovery independently gate. Anomaly detection watches for score-distribution drift; catalog integrity independently verified by Audit Engine's watchdog (ARCH-13). |
| **A-2.** Compromise Evidence Engine and forge citations. | Every citation resolves to a raw event whose integrity hash exists in the immutable store. Forged citations fail resolution. |
| **A-3.** Insider changes weight catalog to allow attacker-preferred ops. | Ceremony requires multi-party + Auditor; catalog changes are Layer-A + Layer-B audited and reviewable independently; drift-monitor alerts. |
| **A-4.** Steal an engine's SVID to forge a stage output. | SVIDs are short-lived (hours); stolen SVID window is bounded; detection via impossible-parallel-use, geographic anomaly (cloud-context), and behavior anomaly. |
| **A-5.** Prompt-inject through a case to inflate AI confidence. | Adjusted confidence (§4.2 point 6) discounts AI's self-report by out-of-band signals; Multi-Engine Adjudication makes AI confidence one factor, not dispositive. |
| **A-6.** Supply-chain compromise of OPA/Rego to loosen policies silently. | Policy corpus signed; rule diffs audited; SBOM tracked; runtime hash-verifies loaded rules; Kernel refuses signature-mismatched corpora. |
| **A-7.** Cloud provider compromise reveals Risk Engine's telemetry stream. | Telemetry Engine's egress is opt-in; risk internals are not egressed; if egress is enabled, per-tenant DEK + redaction pipeline. |
| **A-8.** Continuous Validation window mis-set very long → attacker enjoys stale trust. | Windows have policy-defined ceilings; ceiling changes are ceremony-controlled; drift alerts. |

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

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

**The weight catalog for the Risk Engine.** Reason: it is a single artifact whose values shape *every* risk decision. If an attacker can flip a few weights (e.g., lower the weight of "evidence_confidence" and raise the weight of "ai_confidence_adjusted"), they shift the risk-scoring balance toward permitting bad decisions across the entire tenant fleet — without needing to compromise any per-decision component.

**Redesign response.** Original design placed the catalog in the Storage Engine with a ceremony-approved edit path. Revisions:

1. **Dual-store catalog.** The active catalog is stored in two independent substrates (PostgreSQL control plane + an immutable object-store blob signed at ceremony). Risk Engine loads from PG but verifies against the immutable object-store copy on every load; divergence halts risk scoring.
2. **Ceremony strengthened.** Weight catalog changes require: Owner + Auditor + a second Security Engineer (three roles); the ceremony produces a signed catalog artifact whose hash is embedded in the platform's audit chain. No back-door edit path.
3. **Score-distribution drift monitor.** Detection Engine watches per-tenant score distributions; a step-change post-ceremony triggers automatic hold of new privileged ops for the affected tenants until Auditor re-approves.
4. **Read-only replicas of the catalog** live in each Risk Engine replica in memory; hot-swap is only via signed catalog version pin. Attacker cannot flip weights at runtime.
5. **Second attack target after redesign:** Continuous Validation windows. Similar mitigation: window changes require ceremony; ceiling values live in the same signed catalog artifact.

Repeated: is there another target? Third candidate: the **AI Engine's advisory input path** — if an attacker can quietly enable "AI can also veto" instead of "advise-only", they weaponize prompt injection into denial-of-service on legitimate ops. Response: veto vs. advise flag is not a Policy Engine setting; it is a **Kernel-hardcoded constant** for v0 with a documented change path (Owner + Z0 approval, ceremony, catalog artifact). Elevated to a build-time invariant rather than a config.

## 12. Decisions

### D-11-1. Eleven-stage pipeline mandatory for security-consequential decisions

- **Advantages.** Structural distribution of trust; auditable; explainable; independently verifiable.
- **Disadvantages.** More engineering; more latency (mitigated by parallelisation).
- **Security Impact.** *Strongly positive.* Zero SPOT for decisions.
- **Performance Impact.** *Moderate.* Parallelised where possible; excluded for non-consequential ops.
- **Operational Complexity.** *Higher* but reflects existing engines.
- **Maintainability.** *Positive* — clean boundaries.
- **Scalability.** *Positive* — per-tenant partition.
- **Alternative Designs.** *Fewer stages.* Concentrates trust; rejected. *Serial-only pipeline.* Higher latency; rejected as primary.
- **Reason for Final Selection.** Directly implements mandates #3, #4.

### D-11-2. Runtime Risk Engine (E-14) as first-class engine

- **Advantages.** Dedicated signal composition, catalog governance, adaptive response ceilings.
- **Disadvantages.** One more engine to run.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** *Neutral.*
- **Operational Complexity.** *Moderate.*
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *Merge into Policy Engine.* Concentrates trust; rejected.
- **Reason.** Mandate #7 makes it a hard requirement; the redesign of A-1 shows the value.

### D-11-3. Adaptive Trust vectors as multi-dimensional, ceremony-governed

- **Advantages.** Nuanced trust; audit-visible; policy-controlled.
- **Disadvantages.** Concept load for operators.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** Neutral.
- **Operational Complexity.** *Moderate* — offset by UI.
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *Single-scalar trust.* Blurry; rejected.
- **Reason.** Mandate #8.

### D-11-4. Continuous Validation with policy-defined ceiling windows

- **Advantages.** No silent stale trust; explicit revalidation cadence.
- **Disadvantages.** Users see more re-auth prompts.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** Small.
- **Operational Complexity.** Moderate — well-supported by identity tooling.
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *Permanent trust until revocation.* Rejected — the constitution disallows it.
- **Reason.** Mandate #9.

## 13. Open Questions

- Q-11-1. Exact initial weight catalog values for v0. Resolved in a signed catalog artifact + Phase B.3 ARCH-14 (Safety Layer detailed).
- Q-11-2. Asset-criticality UX for tenants (v0 manual → v1 auto). Resolved in ARCH-16 / Phase D.
- Q-11-3. Trust-vector merge policy across replicas (CRDT vs. leader-owned). Resolved in ARCH-16.
- Q-11-4. Human UI presentation of stage disagreements. Resolved in Phase D.

## 14. Change Log

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