# AEGIS — Configuration Management Standard

- **Document ID:** ARCH-22
- **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-06, ARCH-08, ARCH-09, ARCH-11, ARCH-14, ARCH-19, ARCH-20
- **Consumed by:** ARCH-23, ARCH-24, and every implementation-phase document.

---

## 1. Purpose

Codify how AEGIS configuration is authored, signed, distributed, loaded, verified, changed, rolled back, and audited. Configuration is treated as security-critical because it steers every engine's behavior — a misconfigured Policy corpus, Risk weight catalog, or redaction ruleset can silently invalidate every other control.

Implements Phase-C mandate #26 (Configuration Integrity), aligns with #29 (Cryptographic Agility), #30 (Docs-as-Code), #32 (Operational Simplicity), and #33 (Internal Threat Modeling — assume compromise).

## 2. Configuration Classes

| Class | Examples | Impact | Governance |
|---|---|---|---|
| **C-A Kernel-critical** | Kernel identity chain root, capability schema, boundary contract, signing hierarchies | Catastrophic if wrong | Ceremony + Z0 + Owner + Auditor |
| **C-B Policy catalog** | OPA/Rego rules, sensitive-op list, invariant rules | Silent bypass if wrong | Ceremony + Owner + Security Engineer + Auditor |
| **C-C Weight/Trust catalogs** | Risk weights, Trust weights, Redaction rules, Confidence formula | Bias security decisions | Ceremony + Owner + Auditor |
| **C-D Detection content** | Sigma rules, Detection templates | Detection quality | Signed contributor + review + fixture tests |
| **C-E Engine runtime config** | Feature flags, timeout values, tier routing knobs | Behavior change per engine | Two-approver + audit |
| **C-F Tenant configuration** | Per-tenant policies, retention, connectors, RBAC | Per-tenant impact | Tenant Admin + audit; some fields require 4-eyes |
| **C-G Deployment config** | Sizing, replicas, network topology | Availability | Ops-approved + upgrade audit trail |

Every class has its own signing hierarchy and its own change process, both defined below.

## 3. Requirements

- **REQ-1.** Every configuration is a signed, versioned artifact — no unsigned config loads.
- **REQ-2.** Every load is verified; verification failure fails-secure (fall back to previous good version or refuse to serve).
- **REQ-3.** Every change goes through the Multi-Stage Decision Pipeline (ARCH-11).
- **REQ-4.** Every change is reproducible from source (`docs-as-code`).
- **REQ-5.** Every drift between declared and effective config is detected and alarmed.

## 4. Mandatory Rules

### 4.1 Signing and Versioning

- **M-1.** Configuration artifacts are Protobuf/CBOR structures with a top-level `manifest` containing `class`, `version`, `owner`, `signer_key_id`, `signer_key_alg`, `previous_version_hash`, `content_hash`, and `signature`.
- **M-2.** `version` follows semver at the schema level; content changes bump the artifact's monotonic ID.
- **M-3.** `previous_version_hash` links versions into a hash chain per class (like Layer-A but per-class).
- **M-4.** Signature algorithm agile (mandate #29): `signer_key_alg` supports hybrid signatures.
- **M-5.** Signed artifacts are stored in the control plane (PostgreSQL) *and* an immutable object-store copy (dual-store, like ARCH-12 transformation ledger).

### 4.2 Change Workflow

- **M-6.** Every change is a **ConfigurationChangeProposal (CCP)** submitted as a PR against `config/` in the repo.
- **M-7.** CCP includes: (a) rationale, (b) risk assessment, (c) rollback plan, (d) validation results, (e) affected tenants (if any), (f) drill outcome for high-impact changes.
- **M-8.** Approval workflow per class (§ 2). Kernel-critical + Weight/Trust catalogs require Ceremony.
- **M-9.** Ceremony produces a signed artifact whose hash lands in Layer-A audit + Layer-B batch + release-hash registry.
- **M-10.** Distribution: signed artifact pushed to control plane, immutable object store, transparency log (per Q-14-1 resolution).

### 4.3 Validation Before Load

- **M-11.** Signature verification: signer key valid, not revoked, algorithm supported.
- **M-12.** Schema validation: artifact conforms to class schema (versioned).
- **M-13.** Semantic validation: class-specific invariants. Examples:
  - Policy catalog: invariant rules (e.g., "audit cannot be disabled") must remain.
  - Weight catalog: no negative weights unless explicitly allowed; sum properties preserved.
  - Detection content: fixture tests pass.
  - Redaction rules: canary regression passes.
- **M-14.** Cross-store consistency: PostgreSQL row and object-store blob must match (both signature and content hash). Divergence → fail-secure to last-known-good.
- **M-15.** Time-integrity: artifact's `issued_at` reasonable per NTP + monotonic markers (per ARCH-20 M-25/26).

### 4.4 Rollback

- **M-16.** Every class has a *rollback window* (last N versions retained) with a minimum policy (Kernel-critical: last 10 + pinned baselines).
- **M-17.** Rollback is a Multi-Stage pipeline operation: `Rollback-Config` capability (4-eyes for C-A/B/C, 2-approver for others).
- **M-18.** Rollback carries an audit event; post-rollback watchdogs (ARCH-13) re-verify.

### 4.5 Drift Detection

- **M-19.** Every engine reports its currently-loaded config hash (versioned) at `/version` endpoint and via periodic Integrity Beacons.
- **M-20.** A **DriftMonitor** service (implemented as a watchdog inside the Audit Engine) compares reported hashes across replicas + against the control-plane catalog + against the object-store copy. Divergence → alarm.
- **M-21.** Effective-vs-declared drift is a metric (ARCH-24).

### 4.6 Reproducibility

- **M-22.** Every configuration artifact reproducible from source in the repo. Signed artifacts also carry a `source_ref` (git commit hash of the config definition).
- **M-23.** Compilation from source to signed artifact is deterministic. Two builders produce the same hash for the same source ref.

### 4.7 Secrets in Configuration

- **M-24.** No secrets in config. Config may **reference** secrets by ID; engines resolve via Kernel-mediated `Read-Secret` at use time (per ARCH-19 M-13).
- **M-25.** Encrypted per-tenant DEK references live in config; the DEK itself lives in the KEK-wrapped store.

### 4.8 Cryptographic Agility

- **M-26.** Signature format includes `alg`; verifiers accept multiple algorithms.
- **M-27.** Migration between algorithms happens by signing artifacts with hybrid; a policy switch changes required accepted algorithms; documented migration playbook.

### 4.9 Ceremony Requirements

- **M-28.** Ceremonies for C-A/B/C changes require:
  - Two operators + Auditor observer.
  - Recorded session; hash of recording stored.
  - Documented step-by-step; no ad-hoc actions.
  - Independent verification of the produced artifact after ceremony (hash compare + sign verify) before the artifact enters production.
- **M-29.** Ceremony changes are drilled at least twice per year with rehearsed test artifacts.

## 5. Recommended Practices

- **R-1.** Small, focused changes rather than large omnibus PRs.
- **R-2.** Config PRs include automated impact analysis (which engines / which tenants).
- **R-3.** Prefer additive changes over destructive; deprecate before remove.
- **R-4.** Prefer feature-flag-controlled rollout for behavioral changes.
- **R-5.** Reuse standard patterns for retention/rollback windows across classes.
- **R-6.** Every schema field documented with intent + acceptable value range.

## 6. Verification Process

- **Pre-commit**: schema conformance (`ts-json-schema-generator` or `protobuf-lint`) + secret scanning.
- **CI on PR**: signature-simulation using dev keys; semantic validators; fixture tests; canary regression for redaction/detection changes.
- **CI on merge**: sign in a staging channel; deploy to canary tenant subset; drift monitor checks.
- **Post-deploy**: Layer-A audit event; DriftMonitor cross-check; on-call verification per class.
- **Weekly**: full audit of active config vs. repo state; discrepancy alarm.

## 7. Operational Guidance

- **Config repo layout:** `config/kernel/`, `config/policy/`, `config/catalogs/`, `config/detection/`, `config/tenants/<id>/`, `config/deployment/`.
- **Signing environment** for ceremonies is a hardened workstation with HSM connectivity; documented; refreshed on cadence.
- **Air-gap** config delivery: bundled in the ARCH-14 signed release bundle; installation verifies against Z0-anchored public key.
- **UI for tenant admins** offers only C-F (tenant configuration); higher classes are code-only.

## 8. Future Evolution

- **Confidential Config** — encrypted-at-rest with confidential-compute unwrapping when TEEs adopted.
- **Formal-verified invariants** — small critical class of invariants proved via TLA+/Alloy (Q-19-1 pilot).
- **Tenant self-service** — expand C-F safely as platform matures; UI-guided ceremony workflows for advanced tenant knobs.

## 9. Independent Architecture Review (Reviewer 1)

- **F-1.** *Dual-store adds write cost.* Small compared to config change rate (rare); write is amortized.
- **F-2.** *Ceremony discipline erodes.* Drills + auditor visibility + drift monitor + auditability compensate.
- **F-3.** *Semantic validators drift from actual code behavior.* Property tests bind validator to engine behavior; validators are versioned.
- **F-4.** *Rollback windows too small.* Policy-defined; last-known-good pin extra insurance.

## 10. Adversarial Architect Review (Reviewer 2)

- **A-1.** *Insider merges a bad CCP.* Two-approver + Auditor visibility on catalog classes; ceremony gating for high-impact.
- **A-2.** *Attacker forges signed artifact.* Signing keys HSM-anchored; ceremony required; forgery requires ceremony-time compromise.
- **A-3.** *Compromised control plane writes bad artifact.* Dual-store consistency check catches; object-store immutability enforced.
- **A-4.** *Drift monitor silenced.* Watchdog quorum (ARCH-13); drift monitor's own logs are audit records.
- **A-5.** *Attacker exploits validation logic bug to pass invalid config.* Semantic validator + fixture tests + canary regressions; post-deploy drift monitor.
- **A-6.** *Supply-chain compromise of validator dependencies.* Hash-pinned; ARCH-14 rules apply.

## 11. Operational Reliability Review (Reviewer 3)

- **O-1. 15-year config archive.** Immutable object store + verifier CLI accepts historical versions.
- **O-2. Ceremony logistics.** Rehearsed; documented; multi-party; time-of-day scheduling published.
- **O-3. Change review burden.** Governance graduated by impact class; not every knob is ceremony-controlled.
- **O-4. Observability.** Config version per engine per replica visible in dashboard; drift alerts routed to on-call.
- **O-5. Upgrade safety.** Feature flags default off; canary rollout; signal-based rollback.
- **O-6. Documentation.** Every config field documented; changes require doc update in same PR.
- **O-7. Multi-tenant impact.** Impact analysis surfaces affected tenants; tenant communication process for tenant-facing changes.

## 12. Self-Critique (Reviewer 4)

- **S-1.** *"Configuration is code" but tenants can't code.* C-F class has a UI; other classes are code-only. But if the UI drifts from what the code accepts, we've created a hidden-knowledge trap. Added: UI generated from schema; schema is source of truth. Roadmap.
- **S-2.** *Ceremony discipline scales with staff maturity.* Documented drills + auditor observer + video recording help, but ceremonies are still expensive. Consider whether all C-C catalogs need full ceremonies or some could use lighter (2-approver + Auditor async). Deferred; standard current defaults are conservative.
- **S-3.** *Dual-store consistency check.* If the two stores diverge, we fail-secure to last-known-good. But if last-known-good is *also* stale or itself divergent, we're stuck. Added: DriftMonitor validates last-known-good weekly; canary drill exercises the divergence path.
- **S-4.** *"Semantic invariants must remain"* — enforcement of specific invariants (e.g., audit cannot be disabled) needs to be structural, not just review. Made explicit — Policy Engine loads an *invariant set* separately, and the invariant set is a build-time constant, not run-time configurable.
- **S-5.** *Rollback windows* — 10 versions is arbitrary. Should be tied to time (e.g., 90 days of versions) or events (last N ceremonies). Made time-based default; class policies can override.
- **S-6.** *Ceremony is a bureaucratic surface.* Attack path A-6 (validator dependency) is real; standard already addresses. But *ceremony fatigue* → shortcut culture → future problem. Added metric (ARCH-24) — ceremony completion time; anomalously fast = review.

Revising in place:
- Added **M-13a.** Invariant set (bind-secure) loaded as a build-time constant into Policy Engine; not runtime configurable.
- Added **M-16a.** Rollback window is time-based (90 days default) with class-specific overrides.
- Added **M-19a.** DriftMonitor weekly-validates last-known-good.
- Added metric tie-in to ARCH-24.

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

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

**The signing environment for ceremonies.** Reason: ceremonies are the highest-privilege moments; the signing environment is where the actual key operations happen. Compromising the workstation, its HSM PIN entry, or the operator's session at ceremony time turns everything downstream into forgeries with legitimate signatures.

**Redesign response.**

1. **Signing environment is a dedicated, hardened, air-gapped-ish workstation.** No general-purpose email/browser; managed image; scanned before every use; access requires MFA + physical presence.
2. **HSM PIN entry is out-of-band.** Split PIN across operators; never entered on the network.
3. **Multi-party at ceremony.** Two operators + Auditor observer (video). Any one operator alone cannot complete a ceremony.
4. **Post-ceremony verification.** Independent verifier (Auditor's tool, uses public key of the just-created artifact hash) compares the produced artifact against the intended source; catches "signed but wrong content."
5. **Ceremony rehearsals** in a staging environment quarterly; catches configuration drift in the ceremony process itself.
6. **Ceremony logs on Layer-A.** Every ceremony step audited; watchdog quorum covers.

**Second target after redesign.** The DriftMonitor watchdog. If DriftMonitor is silenced, drift persists undetected. Response: watchdog quorum (ARCH-13); multi-engine cross-verify; DriftMonitor logs are themselves audit records.

**Third target.** Object-store immutability provider policy. Response: multi-provider air-gap copy (ARCH-18); canary deletes test policy enforcement; multi-store consistency check.

## 14. Decisions

### D-22-1. Dual-store signed config + hash-chain per class

- **Advantages.** Compromise on one store detectable; hash chain provides continuity.
- **Disadvantages.** Two writes per change.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** Neutral (config rate is low).
- **Operational Complexity.** Moderate.
- **Maintainability.** Positive.
- **Scalability.** Positive.
- **Alternatives.** *Single-store.* Rejected.
- **Reason.** Zero SPOT applied to config.

### D-22-2. Class-graduated ceremony vs. lightweight change

- **Advantages.** Governance proportional to risk; avoids ceremony fatigue on low-impact changes.
- **Disadvantages.** More classes to manage.
- **Security Impact.** Positive.
- **Performance Impact.** N/A.
- **Operational Complexity.** Moderate.
- **Maintainability.** Positive.
- **Scalability.** Positive.
- **Alternatives.** *Full ceremony for all.* Rejected — fatigue = shortcut culture. *Light for all.* Rejected — too weak for Kernel-critical.
- **Reason.** Operational Simplicity + risk-proportional design.

### D-22-3. Invariant set as build-time constant (M-13a)

- **Advantages.** Structural — cannot be turned off by config; catches self-critique S-4.
- **Disadvantages.** Changes require release, not just config change.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** N/A.
- **Operational Complexity.** Moderate.
- **Maintainability.** Positive.
- **Scalability.** N/A.
- **Alternatives.** *Runtime-configurable invariants.* Rejected — defeats purpose.
- **Reason.** Some things must not be turn-off-able at runtime.

## 15. Open Questions

- Q-22-1. Config UI generated from schema. Recommendation: generate; deferred to Phase D.
- Q-22-2. Ceremony video-recording retention policy. Resolved in ARCH-23.
- Q-22-3. Air-gap ceremony procedure differences vs. connected. Resolved in ARCH-23.

## 16. Change Log

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