Aegis Latent Core

AI Governance and Cryptographic Evidence Gateway

Aegis sits between your application and your model provider. For every governed call it applies policy, forwards the request, and commits a signed, hash-linked evidence record before the response reaches your caller — together with a portable inclusion proof a third party can verify without trusting the gateway that produced it. It is self-hosted: you hold your evidence, your keys, and your data.

Current release candidate: v4.3.0, with fourteen synchronized anchors. Nothing is published for 4.3.0 — no tag, release, package or image exists for it yet, so it cannot be installed from any registry. There is no 4.2.0; the number was skipped.

Most recent published release: 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 release object also exists but was created outside the pipeline and carries no assets; ignore it. The two PyPI gateway artifacts are byte-different from the release assets of the same name — same content, different build host — so does not cover the PyPI downloads. See for provenance and readback.

Why Aegis

• Evidence before emission. For an admitted non-streaming call the record is durable before your caller can observe the response. A record that might not exist is not evidence.
• Verifiable without trusting us. Each record is a leaf in a Merkle Mountain Range. A portable inclusion proof lets a third party verify a disclosed record against a root they obtained independently.
• You keep custody. Self-hosted. The licensor holds no evidence, no keys, no payloads, and has no access to your deployment.
• Provider independence. An OpenAI-compatible surface; your upstream is a configured endpoint, not a lock-in.
• Fail-closed by default. No signer, no distributed limiter, no durable storage means no service — rather than quietly serving unevidenced traffic.
• A broken chain stops traffic. If WAL replay cannot read the ledger back, governed endpoints refuse with 503 before forwarding or committing. Appending onto a prefix you failed to replay produces records that each verify individually while the chain as a whole is unrecoverable — the failure the evidence contract exists to prevent.
• Claims you can check. Every public claim carries an evidence locator and a stated boundary in Claims Matrix, and CI rejects unsupported assurance language.

How it works

 client                    Aegis                         provider
   │                         │                               │
   │─ request ──────────────►│                               │
   │                    admission: auth, scope, bounds,       │
   │                    WAF, rate limit                       │
   │                         │── forward ───────────────────►│
   │                         │◄──────────────── response ────│
   │                    redact → sign → write → fsync         │
   │◄─ response ─────────────│  (only after the commit)      │

Non-streaming. The evidence record is committed before the response is observable. The response carries X-Aegis-Evidence-Status, X-Aegis-Request-ID and the MMR proof headers.

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 — a client that treats connection close as success will accept an unevidenced stream, so check for the marker.

Refused requests are evidence too. When the WAF blocks or a quota is exceeded, the refusal is committed to the same signed chain before the error is returned, and the response carries X-Aegis-Rejection-ID and X-Aegis-Evidence-Status: durable-rejection. The request body is hashed, never stored. A refusal is never conditional on the commit succeeding: if evidence cannot be written the request is still refused, and the header reads rejection-uncommitted rather than implying a durability that was not achieved.

Details: Architecture · Failure Semantics

Two deployment shapes

The same controls — WAF, redaction, signed Merkle ledger, portable proofs — run in either of two places. Records from both verify with the same tooling.

Gateway. A separate process the application cannot bypass. This is the right shape when the boundary is organisational: several teams or languages, one enforcement point.

aegis     # or aegis-server

Embedded. The same controls inside a process that already holds a provider client and cannot add a network hop — a Lambda handler, a batch job:

import aegis, openai

client = aegis.wrap(openai.OpenAI())          # or anthropic.Anthropic(), sync or async
reply = client.chat.completions.create(model="gpt-4o", messages=[...])
reply._aegis_evidence.node_hash               # signed, chained, proof-carrying

wrap recognises a client by shape, so neither provider SDK is a dependency of this package. Blocked prompts raise AegisBlockedError and are never dispatched. Streaming is redacted within a bounded holdback, and the terminal record is committed before the final chunk is yielded.

The difference that matters for a threat model. The gateway is a process the application cannot bypass. The embedded engine runs inside the application, so it constrains calls made through the client it wrapped and nothing else — code in the same process can call the provider directly, hold a second unwrapped client, or edit the WAL. It is an evidence and policy layer for cooperative code, not a containment boundary against the process it runs in. Where the application is itself the thing being constrained, use the gateway.

Details: aegis/embedded.py

Agent-to-agent receipts

When one agent calls another's tool, a receipt lets the caller show a third party that the execution was recorded — without either side disclosing the arguments or the result, which travel only as SHA-256 digests.

from aegis.core.a2a import generate_receipt, verify_receipt

receipt = generate_receipt(ledger, caller_agent_id="planner", target_agent_id="research",
                           tool_name="web.query", input_bytes=args, output_bytes=result)
verify_receipt(receipt, trusted_root)   # also in both SDKs

A valid receipt establishes that the execution's canonical envelope is included under the root you supplied — and nothing else. It does not establish that the tool ran, that either agent identifier is authentic, that the caller was authorised, or that the timestamp is accurate; that is the issuer's unattested clock. The root must be obtained independently of whoever handed you the receipt.

Details: aegis/core/a2a.py

Quickstart

Install

Three channels, because they install different things:

pip install aegis-latent-core     # the engine: aegis.wrap(), plus the aegis / aegis-server CLIs
pip install aegis-latent-sdk      # the verifier: check a proof you were handed
npm  install aegis-latent-sdk     # the same verifier, in TypeScript

aegis-latent-core carries both deployment shapes — importing aegis.wrap for embedded use and the aegis / aegis-server console scripts for the gateway — so the choice between them is a deployment decision, not a different package. For the gateway as a container, see Deployment Profiles:

docker pull ghcr.io/juanlunaia/aegis-latent-core:4.1.2

The published wheel is py3-none-any: the complete feature set runs on pure Python, with no compiler and no native dependency. The aegis_rust extension is an optional accelerator, is not part of this wheel, and is not on any registry — it is built from source or taken from the platform wheels attached to the GitHub Release. What it buys, measured rather than estimated, is in Verified metrics and Rust build; evidence produced with and without it verifies identically, because both paths agree on the MMR root.

Verify what you installed before relying on it — a version on a registry is not provenance. Release Status §2 has the readback commands and the digests observed on 2026-09-04.

Worked examples for every mode, with the output they actually produce, are in Usage Examples.

From source

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --require-hashes -r requirements.lock
python -m pip install --no-deps -e .
pytest -q

For isolated local evaluation, against a mock upstream:

export AEGIS_SECURITY_ENFORCEMENT_MODE=development
export AEGIS_DEBUG_MODE=true
export AEGIS_AUTH_DISABLED=true
export AEGIS_BACKEND_URL=http://127.0.0.1:9999
aegis

Development mode disables the controls that make records meaningful. It is for reading the API, not for evaluating security. Use single-node hardened for anything you intend to conclude from.

With Docker Compose

docker compose up --build

The root docker-compose.yml runs an evaluation profile bound to 127.0.0.1 with in-memory rate limiting. It is not a governed deployment; see Deployment Profiles.

A governed call

curl -sS http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'x-session-id: demo-session' \
  -d '{"messages":[{"role":"user","content":"Hello, Aegis."}]}'

Inspect the evidence headers

curl -sS -D - -o /dev/null http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'x-session-id: demo-session' \
  -d '{"messages":[{"role":"user","content":"Hello, Aegis."}]}' \
  | grep -i '^x-aegis'

Expect X-Aegis-Evidence-Status, X-Aegis-Request-ID, X-Aegis-Proof-Status, and the X-Aegis-MMR-* proof headers.

More: Developer Quickstart

SDKs

Python and TypeScript SDKs provide gateway configuration, OpenAI and Anthropic integration, and portable-proof verification.

# Python, from the source tree
pip install -e ./sdk/python

# TypeScript, from the source tree
cd sdk/typescript && npm ci && npm run build

Registry caution. PyPI carries aegis-latent-sdk at 4.1.2, matching this source tree. npm still carries 4.0.0 — installing the SDK from npm gets you different code from what these documents describe. Check which registry you are installing from.

Proof verification caution. A proof verified against a root supplied by the same gateway that produced it establishes internal consistency only. Obtain the trusted root through an independent channel, or the verification is circular.

Integrations Guide · SDK Guide · MMR Proof v1

Dashboard

A Next.js read-only forensic view over the audit API: ledger window, integrity, MMR proof verification in the browser, current metrics, and bounded evidence export. It renders explicit empty and unavailable states rather than synthesising records.

There is no hosted dashboard. You run it, and browser-facing authentication is your responsibility.

Setup and boundaries

Security and evidence model

• Authenticated principals derived from the credential, never from a client-supplied header; scopes gate audit reads and exports separately.
• Hash-linked, signed records with tamper detection on read; one writer per WAL path, enforced by an advisory lock.
• A ledger that failed to replay refuses governed traffic at ingress; /health and /metrics stay reachable so the fault is diagnosable rather than silent.
• Bounded requests and streams; deterministic pattern-based redaction before the record is written.
• Tampering is detected, not prevented. An operator with filesystem access can alter or delete records. Every integrity claim terminates at that boundary.
• Redaction protects the record, not your provider. The request reaches them as sent.

SECURITY.md · Threat Model · Security Controls · Storage Requirements · Boundaries

Formal verification

Bounded models under specs/ check core invariants in CI: commit-before-emission, append-only ledger prefixes, session-to-ledger binding, and per-stream retained-byte arithmetic. The toolchain is Z3, Lean 4, and TLA+/TLC, gated by scripts/verify_formal_artifacts.sh.

These are abstractions, not runtimes. Nothing mechanically connects a model to the Python or Rust that executes, and the state spaces are bounded. The models can be correct while the implementation is wrong.

Separately, Kani 0.67.0 model-checks the native WAL's frame-bounds arithmetic over the whole usize domain. Those five harnesses run against the real functions rather than an abstraction, so the refinement gap above does not apply to them — but they cover two functions, not a system. Kani models no mmap, no filesystem and no concurrency, so nothing there establishes durability or crash safety.

Formal Verification · Limits

Compliance contributions

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.

Compliance Mapping

Verified metrics

Two coverage figures appear because two runs measured differently on different dates; both are recorded rather than one being selected. Suite counts move as tests are added — run pytest -q on the commit you are evaluating.

None of this is a capacity claim. Offered load is not accepted throughput. The absolute latencies above are properties of one shared, unpinned four-CPU container; what transfers is the shape — that per-commit cost stopped growing with chain length — not the numbers. Re-run the harnesses in your own environment before planning against any of them.

A clean static-analysis run is not a correctness result. mypy --strict and Bandit reporting zero says those two checkers found nothing on this source, which is weaker than an absence of defects or of vulnerabilities.

Evidence Index · Benchmark Method

Roadmap

Not built. No dates.

• Registry publication automation, so a release either publishes and confirms or fails
• Durable WAL backend options, and MMR continuity across replicas rather than only across restarts
• Wider OCI attestation coverage and a documented consumer verification path
• Framework integrations beyond the current provider surfaces
• OpenTelemetry span model across the evidence lifecycle
• Published benchmarks for a representative target deployment
• An enterprise assurance evidence pack

ROADMAP.md

Community and governance

Support is community best-effort with no SLA. This is a single-maintainer project; weigh that in any adoption decision. See Support Model.

Boundaries and limitations

• No certification. No SOC 2, ISO 27001, HIPAA attestation, or FedRAMP. None in progress.
• No independent assurance. No third-party audit or penetration test exists.
• No compliance determination. The system produces technical inputs; you and your assessor decide.
• No legal admissibility. Admissibility is a judicial determination, and no chain of custody is created.
• Not immutable. Tampering is detected, not prevented; an operator with root can alter records.
• No universal PII removal. Deterministic pattern matching over specific fields; it does not protect data already sent upstream.
• No production SLO or capacity claim. Benchmarks are local measurements.
• No cross-replica global ordering. Each replica is an independent chain.
• No guaranteed prompt-injection prevention. Bounded heuristic detection; the record is the product.

Full statements: Boundaries · Claims Matrix · Unsupported Claims

_{Copyright © 2026 Juan Luna. Licensed under AGPLv3 or a commercial agreement. Full documentation index: docs/INDEX.md}