AEGIS Security Assumptions

Architectural Enforcement & Governance of Intelligent Systems

Version: 0.2
Status: Informational
Part of: AEGIS Architecture
Author: Kenneth Tannenbaum
Last Updated: March 6, 2026


Purpose

This document captures explicit assumptions required for AEGIS security claims. Each assumption is paired with verification controls and failure response.

Security assertions are valid only while these assumptions hold.

Assumption Register

IDAssumptionValidation ControlIf Violated
SA-01Kernel is trusted and uncompromisedHost attestation, patch baseline, EDR telemetryEnter safe mode, halt high-risk capabilities
SA-02Cryptography is correctly implementedApproved algorithms, key rotation, TLS policy checksInvalidate sessions, rotate keys, deny execution
SA-03Policy store integrity is preservedSigned policy bundles, checksum verification, immutable logsReject policy load, revert to last known-good
SA-04Actor identity is attributableStrong auth, non-repudiable IDs, token validationDeny unauthenticated requests
SA-05Governance path cannot be bypassedNetwork segmentation, proxy-only execution path, eBPF/OS controlsFail closed and alert
SA-06Time source is trustworthyNTP hardening, drift monitoringMark audit data degraded, escalate decisions
SA-07Audit store is durable and tamper-evident 1WORM/append-only logs, replication checksSwitch to emergency deny mode if durability is lost
SA-08Runtime dependencies are trustedSBOM + signature verification + pinned versionsBlock startup and require operator intervention

Core Security Assumptions

SA-01 Kernel and Host Integrity

Assumption:

Required controls:

Failure behavior:

SA-02 Cryptographic Integrity

Assumption:

Required controls:

Failure behavior:

SA-03 Policy Authenticity and Integrity

Assumption:

Required controls:

Failure behavior:

SA-04 Identity and Attribution

Assumption:

Required controls:

Failure behavior:

SA-05 Governance Engine Isolation

Assumption:

Required controls:

Failure behavior:

Assumption Monitoring

Each assumption MUST have health signals.

Examples:

Any critical signal entering failed state SHOULD trigger incident workflow.

Break-Glass Model

Break-glass capability is allowed only under strict controls:

Break-glass is an exception path, not a standard operating mode.

Residual Risk Acknowledgment

Even with assumptions validated, residual risk remains:

AEGIS mitigates but does not eliminate systemic risk.

Review Cadence

This document MUST be reviewed:


References

Footnotes

  1. J. P. Anderson, “Computer Security Technology Planning Study,” Deputy for Command and Management Systems, HQ Electronic Systems Division (AFSC), Hanscom Field, Bedford, MA, Tech. Rep. ESD-TR-73-51, Vol. II, Oct. 1972. See REFERENCES.md. 2 3