I spent enough years framing houses to know the difference between a notebook that says “I measured twice” and a notebook that can survive a lawsuit. Pages can be torn out. Dates can be changed. If the only person who can vouch for the notebook is the same person being questioned, the notebook isn’t evidence — it’s a story.
We’re about to hit the same wall with AI agents.
The EU AI Act places record-keeping obligations on high-risk systems, phasing in across 2026–2027 depending on the system category. Those systems must automatically record events (Article 12 — logging over the lifecycle), retain those logs (Article 19), and support human oversight that depends on being able to review the records later (Article 14). The Act creates the requirement to keep the logs. It does not yet specify how to prove the logs weren’t rewritten afterward. That gap is the whole story.
NIST’s AI Risk Management Framework (first released January 2023) and ISO/IEC 42001:2023 — the first international standard for an AI management system — both push organizations toward governance, transparency, and accountability through documentation and traceability. Neither one turns an ordinary mutable log file into a cryptographically verifiable record. A system administrator, a compromised service account, or a routine software update can alter a log without leaving any proof the change happened.
For debugging, that’s fine. Observability — inspecting runtime behavior to find a bug — assumes you trust the data because it’s yours. You’re trying to locate a problem, not convince a regulator or an insurer that a record is untouched. Accountability sets a different bar. The obligation is shifting from “we kept records” to “we can demonstrate the records weren’t altered after the fact.”
That’s the difference between observability and provability, and 2026 is the year it starts to bite.
Most agent frameworks still treat logs as debug output. They write to stdout, a database table, or a vendor dashboard. Those are useful right up until someone asks the uncomfortable question: who could have edited this entry, and how would we know? Once that question is on the table, ordinary logs stop being enough.
What the integrity layer looks like¶
Marturia adds that integrity layer for teams already shipping agents that take real actions. Each decision produces a receipt:
- Signed with an Ed25519 key (RFC 8032) scoped to that tenant — a key the tenant controls. Ed25519 signatures are deterministic by construction.
- Hash-chained with SHA-256 — each receipt carries the hash of the previous one, so any insertion, deletion, or reordering breaks the chain.
- Witnessed — periodically a Merkle root over a segment of the chain is signed by independent witness keys and returned to the tenant as an attestation. This is our own in-house witness step. Nothing is posted to a public blockchain or external transparency log; the verification material stays under the tenant’s control.
Verification needs no account and no special access. Anyone given the receipt bundle and the tenant’s public key can run the offline verifier — the witness signatures travel inside the chain, so the check is fully offline once the material is in hand:
pip install marturia-verify
marturia-verify --receipt receipt.json --pubkey-hex <tenant-public-key>
Keys can be rotated or revoked for future receipts while past receipts stay verifiable, because each receipt references the public key that was current when it was signed.
None of this replaces the logs you already have. It wraps the decisions that matter so the subset of records you might one day have to show a third party carries its own proof of integrity. Human oversight under the AI Act gets a lot more practical when the reviewer can trust that the sequence in front of them hasn’t been edited since it was created.
We’re still in closed beta because the engineering details matter more than the announcement. The signing is per-tenant, so one customer’s receipts can’t be confused with another’s. The witness step is in-house, so there’s no external dependency to be subpoenaed or taken offline — the trade-off is honest: verifiers trust the operator’s key-management rather than a public timestamp authority, which is why the keys and witness process are documented, not hand-waved.
This is not legal advice. The Act’s exact timeline and technical expectations will be sharpened in delegated acts and guidance; the official text is Regulation (EU) 2024/1689. What’s already true today: the text creates an obligation to retain reviewable records, and ordinary mutable logs do not, by themselves, prove those records are authentic.
The teams that are ready in 2026 will be the ones who treated the integrity of their decision records as a first-class engineering problem — not a logging config. Everyone else will be the one trying to prove, after the fact, that their records were never touched.
Closed beta is open. You can confirm everything above against a real receipt in about fifteen minutes:
pip install marturia-verifyfor the public verifier/docs/quickstart.htmlfor the agent-side integration
Related Marturia resources - /blog/what-the-ai-act-makes-you-keep.html - /guides/ai-act-iso-42001-crosswalk.html - /guides/marturia-vs-langsmith-vs-sigstore.html