{"slug": "designing-an-ai-evidence-gateway-durable-wal-portable-mmr-proofs-and-bounded", "title": "Designing an AI Evidence Gateway: Durable WAL, Portable MMR Proofs, and Bounded Formal Checks", "summary": "Aegis Latent Core, an AI governance and evidence gateway for governed LLM traffic, implements durable evidence records, portable Merkle Mountain Range inclusion proofs, and narrowly scoped formal checks. The gateway uses an append-only JSONL write-ahead log as the authoritative replay authority, with an optional Rust-backed segment for auxiliary streaming frames. The project emphasizes the boundaries of its guarantees, noting that fsync does not prove power-loss behavior or external custody.", "body_md": "AI gateways are often discussed as routing layers: authenticate a caller, apply policy, forward a request, and record what happened. For higher-assurance deployments, the harder engineering question is what evidence remains after a request completes—and exactly what that evidence proves.\n\n[Aegis Latent Core](https://github.com/JuanLunaIA/aegis-latent-core) is an AI Governance and Evidence Gateway for governed LLM traffic. Its current source implements provider-aware request controls, bounded streaming redaction, durable evidence records, portable Merkle Mountain Range (MMR) inclusion proofs, Python and TypeScript integrations, and narrowly scoped formal checks.\n\nThis article walks through those mechanisms and, just as importantly, their boundaries.\n\nVersion note:GitHub currently exposes a Release labeled[, while the source anchors, all ten named Release assets, and the published SDKs identify version]`v4.0.1`\n\n`4.0.0`\n\n. The`v4.0.1`\n\nref points directly to a commit, making it a lightweight tag. Treat`v4.0.1`\n\nas the GitHub Release label—not as evidence that the artifacts were rebuilt as 4.0.1, that the tag is signed, or that the tag-triggered publication workflows produced the public objects.\n\nAt a high level, Aegis sits between an application and a configured model provider. The non-streaming and streaming paths share admission controls, but they cross the evidence boundary differently.\n\n```\nClient application\n    |\n    | request\n    v\nAegis gateway\n    |-- authenticate caller and assign request identity\n    |-- enforce body bounds and canonicalize input\n    |-- apply WAF, egress, session, and rate-limit controls\n    |\n    | admitted request\n    v\nConfigured upstream model provider\n    |\n    | response or terminal error\n    v\nAegis gateway\n    |\n    |-- non-streaming ---------------------------------------|\n    |   canonicalize outcome                                |\n    |   hash and commit evidence to authoritative JSONL WAL |\n    |   flush + fsync                                       |\n    |   return governed response                            |\n    |                                                       |\n    |-- SSE streaming --------------------------------------|\n        incrementally sanitize canonical events             |\n        emit through a bounded, byte-accounted queue        |\n        hash the exact bytes emitted                         |\n        commit one terminal summary                          |\n        emit the protocol terminal marker only after commit |\n                                                            v\n                                                proof lookup / audit views\n```\n\nFor non-streaming traffic, the response crosses the durable evidence gate before it is returned. For admitted Server-Sent Events (SSE), sanitized non-terminal events can be emitted incrementally. Initial evidence and proof status is therefore `pending-terminal`\n\n; the success terminal marker is withheld until the terminal summary commits.\n\nThe replay authority is an append-only JSONL WAL at the configured storage path. It stores chain linkage, request and response hashes, portable proof metadata, signature metadata, and request identity. Calling `fsync`\n\nmeans the process asked the operating system to synchronize the descriptor; it does not by itself prove power-loss behavior, replicated-volume durability, immutable retention, or external custody. Those remain deployment questions.\n\nThe repository includes an optional native `RustWal`\n\n. When the extension is available, it receives an auxiliary copy of terminal streaming frames in a bounded memory-mapped, CRC32-framed segment at `<wal_path>.stream.rwal`\n\n.\n\nThat distinction matters: the Rust segment is not the replay authority. The authoritative record is the fsynced JSONL WAL. Describing the architecture as a purely Rust-backed ledger, a zero-copy path, or a latency-free evidence layer would overstate the implementation.\n\nStreaming privacy controls have a chunk-boundary problem. An identifier can begin in one event and finish in the next. Aegis addresses supported identifier forms with a finite character holdback rather than buffering an entire response.\n\nThe stream path also applies per-admitted-stream bounds to queue bytes, queue items, event size, cumulative output, preview retention, de-identification window, and duration. SHA-256 covers the exact emitted bytes, and the implementation commits one terminal outcome. On byte, event, duration, cancellation, incomplete-upstream, or upstream-error paths, it closes the upstream iterator where applicable and omits the success terminal marker.\n\nThese are useful, testable controls—not universal de-identification. Aggregate retained memory still scales with admitted concurrency, so deployment-level admission and concurrency controls remain necessary.\n\nAegis uses the `aegis-mmr-inclusion-v1`\n\nformat so a client can verify that a disclosed leaf digest is included relative to a supplied root without possessing the gateway's in-memory MMR state.\n\nThe construction is deliberately specific:\n\nFor a durable non-streaming response, proof data can be returned in `X-Aegis-MMR-*`\n\nheaders. An SSE response cannot update its initial headers after streaming begins, so its proof must be retrieved from the authenticated proof link after terminal commit.\n\nThe trust anchor is crucial. A verifier must pin or otherwise obtain the root through an independent trust policy. Copying a root from the same untrusted response does not make it independent. A valid proof establishes inclusion relative to that root; it does not establish that the source event is true, that timestamps are externally trusted, that storage is immutable, or that the evidence is legally admissible.\n\nThe published Python distribution is [ aegis-latent-sdk==4.0.0](https://pypi.org/project/aegis-latent-sdk/4.0.0/). The install name uses hyphens; the import namespace is\n\n`aegis_sdk`\n\n. Python 3.11 or newer is required.\n\n```\npython -m pip install 'aegis-latent-sdk[openai]==4.0.0'\npython\nimport os\nfrom aegis_sdk.openai import OpenAI\n\nclient = OpenAI(\n    aegis_api_key=os.environ[\"AEGIS_API_KEY\"],\n    gateway_url=os.environ[\"AEGIS_GATEWAY_URL\"],\n    tenant_id=os.environ[\"AEGIS_TENANT_ID\"],\n)\n\nresponse = client.chat.completions.create(\n    model=\"gpt-4.1-mini\",\n    messages=[{\"role\": \"user\", \"content\": \"hello\"}],\n)\n```\n\nThe package supplies tested OpenAI and Anthropic subclasses within declared dependency ranges. Subclassing does not make every vendor route available through the gateway. Native Anthropic Messages ingress requires the gateway to be configured with `AEGIS_PROVIDER=anthropic`\n\n.\n\nFor automatic non-streaming proof verification, callers can set `verify_proof=True`\n\nand provide a pinned `trusted_mmr_root`\n\n. Streaming proofs are retrieved after terminal commit instead of being completed in the initial headers.\n\nThe npm package is [ aegis-latent-sdk@4.0.0](https://www.npmjs.com/package/aegis-latent-sdk). The current package declares Node.js 18 or newer and provider SDKs as peer dependencies.\n\n```\nnpm install aegis-latent-sdk@4.0.0 openai@^6.49.0\npython\nimport OpenAI from \"openai\";\nimport { openAIGatewayOptions } from \"aegis-latent-sdk\";\n\nconst client = new OpenAI(openAIGatewayOptions({\n  aegisApiKey: process.env.AEGIS_API_KEY!,\n  gatewayUrl: process.env.AEGIS_GATEWAY_URL!,\n  tenantId: process.env.AEGIS_TENANT_ID!,\n}));\n```\n\nProof verification is available as a separate operation:\n\n``` js\nimport {\n  parseInclusionProof,\n  verifyInclusionHash,\n} from \"aegis-latent-sdk/proof\";\n\nconst proof = parseInclusionProof(untrustedJson);\nconst valid = await verifyInclusionHash(\n  leafHashHeader,\n  proof,\n  pinnedRoot,\n);\n```\n\nThe verifier uses Web Crypto-compatible primitives. The package also offers provider-native integration surfaces, but compatibility remains bounded to the versions, routes, and behaviors covered by its tests.\n\nThe repository's formal gate combines two SMT-LIB checks, one Lean 4 theorem, and three finite TLA+/TLC models. Its declared checks include token-bucket arithmetic, per-stream retained-memory arithmetic, a durable-before-emission phase theorem, append-only ledger prefixes, commit-before-emission in a finite request model, and session-to-ledger binding.\n\nThis is stronger and more precise than saying “formally verified.” The artifacts verify their stated formulas and bounded abstractions. They do not provide a machine-checked refinement proof connecting every Python or Rust transition—or the operating system and target filesystem—to those models. In particular, the lifecycle abstraction does not model every incremental SSE event as withheld; it models committed outcomes and the terminal transition.\n\nFrom a source checkout, the formal entry point is:\n\n```\nbash scripts/verify_formal_artifacts.sh\n```\n\nTreat a successful run as evidence about those named artifacts and bounds, not as certification of the whole product.\n\nThe repository includes a read-only dashboard for health, retained ledger views, proof lookup, current metrics, and bounded forensic export. The dashboard uses the sibling TypeScript SDK through a local file dependency, so build that source package first even though an SDK is now published on npm.\n\n```\ngit clone https://github.com/JuanLunaIA/aegis-latent-core.git\ncd aegis-latent-core\ngit checkout 6469904380218584ae0b5221334bc9a46500f5ba\n\ncd sdk/typescript\nnpm ci\nnpm run build\n\ncd ../../dashboard\nnpm ci\nexport AEGIS_PRIMARY_BASE_URL='https://aegis.internal'\nexport AEGIS_DASHBOARD_API_KEY='read-only-audit-token'\nnpm run build\nnpm start\n```\n\nFor interactive development, run `npm run dev`\n\ninstead of the final build/start pair. Use a dedicated least-privilege audit token and place the dashboard behind an authenticated reverse proxy. Although the UI does not mutate ledger records, the Forensics page can request a bounded evidence ZIP and requires `audit:export`\n\n; treat that as a sensitive export operation.\n\nThe dashboard does not fabricate missing data. An unavailable endpoint remains unavailable rather than becoming a zero or a demo value. Its MMR page can run the shared verifier in the browser, but a root returned by the same gateway is still not an independent trust anchor.\n\nA useful review starts with narrow questions:\n\n`fsync`\n\nfailure?`pending-terminal`\n\n?Aegis implements technical controls and produces structured cryptographic evidence under declared conditions. It is not, by repository evidence alone, a compliance certification, a legal-admissibility ruling, a production SLO, a WORM guarantee, or proof of external immutability.\n\nIf you review the project, feedback on the authoritative/auxiliary WAL boundary, portable-proof trust anchoring, and streaming terminal semantics would be especially useful.", "url": "https://wpnews.pro/news/designing-an-ai-evidence-gateway-durable-wal-portable-mmr-proofs-and-bounded", "canonical_source": "https://dev.to/luna_ia/designing-an-ai-evidence-gateway-durable-wal-portable-mmr-proofs-and-bounded-formal-checks-40pm", "published_at": "2026-08-26 10:30:31+00:00", "updated_at": "2026-08-26 10:43:45.853415+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-safety", "ai-products"], "entities": ["Aegis Latent Core", "JuanLunaIA", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/designing-an-ai-evidence-gateway-durable-wal-portable-mmr-proofs-and-bounded", "markdown": "https://wpnews.pro/news/designing-an-ai-evidence-gateway-durable-wal-portable-mmr-proofs-and-bounded.md", "text": "https://wpnews.pro/news/designing-an-ai-evidence-gateway-durable-wal-portable-mmr-proofs-and-bounded.txt", "jsonld": "https://wpnews.pro/news/designing-an-ai-evidence-gateway-durable-wal-portable-mmr-proofs-and-bounded.jsonld"}}