Independent security audit package
This dossier is ready to hand to an external assessor. It does not claim that an independent audit has occurred. The reviewer must be contractually and operationally independent from the implementer.
Audit objective
Determine whether an attacker controlling an agent, connector or ordinary operator can cause an unauthorized, stale, replayed, over-broad or silently unaudited Kubernetes quarantine; suppress its restoration obligation; forge an independent observation; or make the system fail open when identity, policy, state, storage or signing is unavailable.
In scope
- canonical JSON, hashes and Ed25519 signature verification;
- signed missions, evidence provenance/fault domains and policy derivation;
- AuthZEN signed decisions and embedded/external evaluator disagreement;
- capability and grant single-use semantics, time and audience binding;
- proof-carrying admission and the typed Kubernetes executor;
- PostgreSQL transactions/roles, Temporal restoration and emergency stop;
- SPIFFE URI validation, TLS configuration, SPIRE selectors and RBAC;
- observer separation, proof/receipt replay and attestation semantics;
- audit checkpoints, exports, transparency receipts and S3 WORM sink;
- backup/restore, key rotation/removal and dependency/container/IaC posture.
Explicitly out of scope unless separately contracted: the correctness of Kubernetes, Cilium, SPIRE, PostgreSQL, Temporal, OpenBao, RustFS, Node.js or the cloud provider themselves; social engineering; physical access; and any customer production system.
Entry material
- architecture and threat model;
- action-finality protocol and executable Quint
model under
formal/; - Kubernetes executor contract;
- independent observer;
- WORM/SCITT profile;
- key-compromise runbook;
- OpenAPI contract, SBOM, lockfile and dated qualification evidence.
Generated private material and .aegis-lab/ are excluded from the audit
archive. Provide public key bundles, redacted reports and immutable evidence
exports through a controlled transfer instead.
Reproduction commands
This dossier is addressed to an external assessor, and until 2026-09-01 every command in it went through PowerShell — so a reviewer on Linux or macOS, the common case, could run none of them. That was an adoption blocker in front of this gate rather than a security property. What follows states exactly what is reproducible on each platform.
Portable — Linux, macOS and Windows
These need only Node.js 22+, and for the verifier a Rust toolchain:
npm ci --ignore-scripts
npm run verify # lint, typecheck, tests with coverage thresholds,
# formal sampling, trace conformance, demo
npm run build
npm run verifier:check # the independent Rust verifier against the shared
# vector corpus, 25 000 generated values, and a real
# signature it did not produce
npm run formal:conformance # kernel traces replayed against the Quint model
npm run load:campaign
npm run perf:budget # the same campaign, against a committed budget
npm run keys:compromise
npm run sbom
The authoritative-store test needs a PostgreSQL the reviewer supplies, and deliberately does not install one:
AEGIS_PG_ADMIN_URL=postgresql://user:pass@127.0.0.1:5432/aegis_lab npm run test:postgres
npm run formal:verify performs bounded model checking with Apalache and needs
a JVM. It has not been run on the qualification host; see the model note in
qualification-evidence-2026-08-29.md.
Linux with Docker — the SOTA profile
The sota:* commands dispatch to scripts/wsl-*.sh directly on a POSIX host;
the PowerShell only ever existed to cross into WSL:
npm run sota:cluster:start
npm run sota:cilium:install
npm run sota:spire:install
npm run sota:spire:qualify
npm run sota:security:install
npm run sota:security:scan
npm run sota:pause
Windows only — the hardened application lab
lab-bootstrap.ps1 and lab-start.ps1 are roughly 33 KB of genuine
provisioning logic: short-lived certificate issuance, verified binary downloads,
process supervision, and OpenBao recovery material protected with Windows DPAPI.
They are not wrappers, and no POSIX translation exists yet.
npm run lab:bootstrap
npm run lab:start
npm run lab:smoke
npm run lab:postgres:backup
npm run lab:postgres:restore-test
npm run sota:install
npm run sota:qualify
npm run sota:webhook:qualify
npm run sota:worm:qualify
An assessor without a Windows host therefore cannot reproduce the hardened
application lab, the WORM retention campaign or the proof-webhook qualification.
They can reproduce the protocol suite, the adversarial corpus, the
cross-language verifier, the trace conformance, the load and key-compromise
campaigns, the supply-chain scan and the SBOM. Running npm run lab:start on
Linux prints that limitation and where it is tracked rather than failing with
powershell: command not found.
The SOTA and lab commands operate only on the repository's isolated lab. The assessor should use a disposable host and independently inspect the scripts before execution.
Required adversarial cases
- Tamper every signed field and substitute each key/issuer/audience.
- Replay capabilities, grants, SIEM nonces, PDP decisions and Kubernetes admission requests concurrently and after restart.
- Mutate policy, target state, evidence, clock and restoration deadline between proposal, commit, admission, execution and observation.
- Compromise separately: agent, connector, executor, observer, PDP, scheduler, database role, workload CA/SPIRE selector and one signing key.
- Kill each component before and after every durable commit boundary.
- Attempt Kubernetes writes outside the exact pod label and deny-all policy, from both executor and observer identities.
- Delete, roll back, fork and reorder local audit/WORM artifacts.
- Restore backups to a clean host and measure actual RPO/RTO.
Acceptance gates
| Gate | Required evidence |
|---|---|
| Unauthorized mutations | Zero successful cases in the agreed corpus |
| Replay | Zero second effects under race, timeout, retry and restart |
| Observer forgery | No attestation without observer key plus fresh read-only observation |
| Failure behaviour | Every ambiguous dependency stops new writes |
| Restoration | No lost obligation; every conflict is preserved and escalated |
| Audit | Every transition is chained, signed and externally retained |
| Privilege | No agent write credential; observer has no write verb |
| Key incident | Removed key has zero active authority; history remains labelled/verifiable |
Known residual risks the auditor must not waive silently
- one local cluster/CNI/version combination, no HA or multi-region semantics;
- application services are not yet all deployed as continuously rotated SPIRE workloads, although the SPIRE mTLS path is exercised end to end;
- local OpenBao is not an HSM or separate company/account;
- RustFS WORM is local and the JSON receipt profile is not a SCITT conformance claim;
- policy publication, emergency stop and some lab administration still share an operator/host failure domain;
- no vendor-certified SIEM retry/backpressure campaign;
- no customer data, 30-day shadow record, professional pentest or production DR exercise.
Deliverables expected from the external assessor
- signed scope and exact commit/image digests;
- attack-surface and trust-boundary review;
- reproducible findings with severity, exploit preconditions and invariant;
- retest result for every accepted fix;
- explicit residual-risk register and go/no-go recommendation;
- cryptographically signed final report whose digest is archived externally.
Only that final external report may close the independent-audit gate.