Aegis Latent Core

AI Governance and Cryptographic Evidence Gateway

Aegis Latent Core commits signed, hash-linked evidence of every governed AI call — before the response reaches the caller — and issues a portable proof that a third party verifies without trusting the gateway, us, or you.

Every load-bearing claim in this file carries a locator and a stated boundary; the gates that enforce that discipline run in CI.

Current release: v5.0.1 — the latest published release (the checked-out source is v5.0.2, an Apache-2.0 source target that is not published), published 2026-09-24 on every surface (PyPI aegis-latent-core 5.0.1 followed on 2026-09-26), read back the same day (Release Status §1.0a). The Sigstore-signed tag passes gitsign verify-tag; the GitHub Release carries 31 assets and all 15 files listed in its SHA256SUMS re-hash to their digests; PyPI aegis-latent-sdk 5.0.1 and npm aegis-latent-sdk 5.0.1 are byte-identical to the release assets of the same name; and the GHCR gateway and dashboard images pass cosign verify and their build-provenance attestations verify, each against the exact publishing workflow identity. The gateway distribution aegis-latent-core reached PyPI at 5.0.1 on 2026-09-26 (run 36224961909 of publish_pypi_gateway.yml, read back 2026-09-29, Release Status §1.0b); pip install aegis-latent-core resolves to 5.0.1, and its wheel and sdist match the release assets byte for byte. The GHCR images and the Release assets remain available. The previous release, v5.0.0, was published 2026-09-16 on the same surfaces (§1.0). There is no 4.2.0; the number was skipped.

First published version with the gateway on PyPI: v4.1.2, read back on 2026-09-04 — signed annotated tag, GitHub Release with 31 assets, PyPI aegis-latent-core 4.1.2, PyPI aegis-latent-sdk 4.1.2, npm aegis-latent-sdk 4.1.2, and GHCR gateway and dashboard images. 4.1.2 is the first version installable from PyPI as aegis-latent-core; before it the gateway came from source or GHCR only. The npm version list skips 4.1.1, whose publish step failed. A v4.1.0 release object also exists but was created outside the pipeline and carries no assets; ignore it. The two 4.1.2 PyPI gateway artifacts are byte-different from the release assets of the same name — same content, different build host — so SHA256SUMS does not cover those downloads; the 5.0.1 PyPI gateway artifacts match it. See Release Status for provenance and readback.

---

The problem

Your AI decisions are logged to a database your administrators can edit. When someone asks what the model was told six months ago, you answer from records the interested party could have changed.

In a regulated industry that is not a paperwork problem — it is an existential one. The regulator, the court and the auditor each ask the same question, and "our logs are probably fine" is not an answer they accept:

1. A record the interested party could have altered is not evidence — it only reads as evidence until someone with a reason to doubt it asks one question.
2. You already owe someone a record you can stand behind — EU AI Act Art. 12, HIPAA audit controls, SEC 17a-4's audit-trail alternative, MiFID II. Those are your obligations; this software is an input to them, never a discharge of them.
3. The fix has to be checkable by someone who distrusts you, or it is the same problem wearing better clothes.

The Aegis solution

• Append-only, tamper-evident MMR. Every record is a leaf in a Merkle Mountain Range. A portable inclusion proof (O(log n), no zero-knowledge claim) lets a third party verify a disclosed record against a root they obtained independently. verify_integrity() detects tampering on read; tampering is detected, not prevented — see the boundaries below.
• Cryptographic sealing. Each record is hashed into a chain link and signed — HMAC by default, Ed25519 (RFC 8032) or ML-DSA-65 (FIPS 204) where configured, with an HSM path in the enterprise server. Optional per-subject shredding (AES-256-GCM key destruction) erases plaintext from a ciphertext holder's view without changing the MMR root or previously issued proofs.
• Zero-trust verification. Proofs verify offline: a 313-line pure-Python verifier, a TypeScript twin with the same semantics, and zero network calls. No trust in the gateway, the vendor, or the operator who discloses the record — only in a root you obtained through a channel the discloser does not control.
• Regulatory inputs. MiFID II Art. 16(6)/16(7) and MiFIR Art. 25(1) record-keeping framing (durable, ordered-within-process records; no orders — RTS 24 — and no clock traceability — RTS 25); EU AI Act Art. 12 logging inputs (commit-before-response, tamper detection, verifiable inclusion); HIPAA Safe-Harbor-style pattern redaction; ISO/IEC 27037-style extracts. These are technical inputs, not compliance. No certification exists, none is in progress, and whether any obligation is met is a determination for you and your assessor (CLM-039 is LEGAL-REVIEW-REQUIRED).

→ Prove it yourself — twelve lines of Python, no call to our servers, three cases of which two must fail.

pip install aegis-latent-sdk aegis-latent-core   # verifier + gateway, both 5.0.1 on PyPI
python tools/sales/prove_it/prove_it.py --demo   # accepts one record, rejects two forgeries
python -m examples.demo                          # gateway + mock upstream, tamper detected

Both commands run from a checkout of this repository; what each one shows and does not show.

---

Architecture at a glance

 caller ──────────►  Aegis gateway  ──────────────────────────►  upstream provider
                        │  admission: auth · scope · bounds
                        │  WAF · rate limiting · session checks
                        │
                        │  (policy passed) forward
                        │  ◄─────────────── response ─────────
                        │
                        │  redact → hash → sign → WAL append + fsync → MMR leaf
                        │  (refused requests: the refusal is committed to the
                        │   same signed chain before the error returns)
                        │
 caller ◄──────────  response + X-Aegis-Evidence-Status
                        + X-Aegis-Request-ID + X-Aegis-MMR-* proof headers

Non-streaming. The evidence record is committed before the response is observable by the caller.

Streaming. Sanitized events are emitted incrementally through a bounded, byte-accounted queue while evidence status reads pending-terminal. One exact-byte terminal summary is committed, and only then is the terminal marker emitted. If that commit fails, the marker is withheld.