Sealed Snapshots: Audit-Grade AI Architecture

By Joseph McCann, Founder of Axiom

In 2019, I spent four months rebuilding the financial infrastructure of a $12M nonprofit spun out from the Tides Foundation. The exit audit required me to produce documentation that did not exist — board resolutions, journal entries, grant reconciliation trails. I had the numbers. I did not have the provenance.

I found it. It cost me weeks and a VP of Finance who had left two years prior. But I found it.

That experience taught me something about compliance that most people in AI don't understand yet: regulators don't ask for the answer. They ask for the lineage — where each number came from, what decisions were made, who signed off, what changed and when.

AI agents are about to create a compliance crisis that makes my nonprofit audit look like a parking ticket.

The Problem With Logging AI Behavior After the Fact

Every AI agent framework on the market logs what happened. They log outputs. They log timestamps. They log user queries. And if you're using one of these systems in a regulated environment — healthcare, finance, legal, critical infrastructure — you are already in trouble.

Here is why.

A log entry is a record someone wrote down after the fact. It has no cryptographic integrity. It can be edited, deleted, backdated, or selectively removed. In a legal proceeding, an opposing counsel will ask: "How do we know this log wasn't modified after the incident?" And you will have no good answer.

This isn't hypothetical. It's the same problem that plagued electronic health records for a decade. The HIPAA security rule requires access controls and audit trails — but it does not require cryptographic integrity. So hospitals have audit logs that say "no unauthorized access" while plaintiffs' lawyers produce evidence of unauthorized access. The logs were editable. They were edited.

The only architecture that satisfies a regulator is one where the evidence is sealed before the act, not assembled after it.

What a Sealed Snapshot Is

A sealed snapshot is a cryptographic execution receipt generated at the moment an AI agent skill completes — before the output is returned, before any human reviews it, before any post-processing modifies it.

The snapshot contains:

The skill that was invoked — the function name, the model, the version
The inputs — serialized, canonicalized, hashed with SHA-256
The output — same treatment
A timestamp — microsecond precision, server-authoritative
A signature — HMAC-SHA256, computed from the payload, using a per-tenant signing key

The signature is the critical piece. It is computed before the receipt leaves the system. Any subsequent modification — changing the skill name, the timestamp, the output — will break the signature. Verification is deterministic: recompute the expected signature from the stored fields, compare it to the stored signature using constant-time comparison, report valid or invalid.

A sealed snapshot is tamper-evident, not tamper-proof. You can tell if it was modified. You cannot prevent modification. That's the right tradeoff. What you need in a compliance context is integrity you can check: a signature that detects any change to the record, verifiable by a party who holds the signing secret.

The Regulatory Landscape

Four frameworks matter for AI agent deployments. They are different in scope and mechanism, but they converge on one requirement: evidence that is self-authenticating, time-stamped, and derived from the execution itself.

EU AI Act (Articles 12 and 13)

High-risk AI systems must maintain logs of operation. Article 12 requires "logging facilities" for high-risk systems. Article 13 requires "oversight mechanisms" that enable humans to understand, monitor, and correct system outputs.

The problem with "logging facilities" as written: a log file is not a logging facility. A logging facility is a system with integrity guarantees. The text does not specify cryptographic integrity — but the regulatory guidance from the AI Office has moved in that direction. The practical interpretation for any compliance team: if you cannot prove your logs weren't modified after the fact, you cannot prove compliance.

Axiom's receipts satisfy Article 12 by providing cryptographic execution receipts that are sealed at execution time, not assembled afterward.

SOC 2 (CC7.2 and CC7.3)

CC7.2 requires the ability to detect anomalies and potential security incidents. CC7.3 requires monitoring of system components and their operational state.

AI agents create a new problem here: what counts as an anomaly when the system is probabilistic? A model returning a hallucinated number is not a security incident in the traditional sense — it's a normal system operation that happened to produce a wrong output. Standard SIEM tools cannot distinguish "model hallucination" from "model compromise." You need evidence of what the model actually did, not what it logged after the fact.

Axiom's receipts give SOC 2 auditors the execution provenance needed to scope anomaly detection for AI systems.

HIPAA (164.312(b))

The technical safeguard requires: "Audit controls to record and examine activity in information systems that contain or use electronic protected health information."

"Record and examine" is the operative phrase. A receipt that records what skill was invoked, on what inputs, producing what outputs, with a timestamp and a cryptographic signature — that is an audit control. A log file is not.

The HIPAA Security Rule does not mandate cryptographic integrity for audit logs. But it also doesn't mandate paper audit trails. What it requires is that you can demonstrate what happened. A sealed snapshot does that. A log file might — if no one ever touches it — but you cannot prove that.

Axiom's receipts satisfy HIPAA's audit control requirements by providing cryptographic evidence of each PHI-adjacent AI invocation.

DORA (Article 12)

The EU's Digital Operational Resilience Act requires financial institutions to log all system events and maintain "complete and accurate records." The guidance around AI operational resilience — still evolving as of 2026 — points toward requiring execution provenance for AI-driven decisions.

For financial institutions using AI agents for credit decisions, trade routing, risk calculations, or customer communication: you need to prove not just what the model output, but what inputs it received, when, and under what configuration. A sealed snapshot gives you that.

Axiom's receipts satisfy DORA's logging requirements with self-authenticating, time-stamped execution records.

Why Verification Must Be Independent

The most common objection I hear from security teams: "Why should we trust Axiom's signature? If Axiom's servers are compromised, the signatures could be forged."

This is the right question to ask. And it is why Axiom's verification is designed to be independent of Axiom's infrastructure.

An auditor or compliance team can verify any receipt using only:

The receipt itself (fields + signature)
The per-tenant signing key (held by the customer, not Axiom)
The Axiom open-source verifier (github.com/josephmccann/verifier)

The verifier is MIT-licensed, has zero external dependencies, and runs in any Node.js or Python environment. It recomputes the expected signature from the receipt fields, compares it to the stored signature using crypto.timingSafeEqual(), and reports valid or invalid.

Verification does not require Axiom to be online, trustworthy, or even in business. If Axiom disappears tomorrow, every receipt ever issued can still be verified independently. That is the property that makes this useful for long-term regulatory compliance — the same reason you can verify a PGP signature from 1998 without PGP Corporation still existing.

The Architecture Regulators Will Accept

Every compliance framework — EU AI Act, SOC 2, HIPAA, DORA — converges on the same underlying requirement: prove what the system actually did, not what someone wrote down about what it did.

Logs after the fact are not proof. They are assertions. Assertions require trust in the system that produced them.

Sealed snapshots are different. The cryptographic signature is generated from the execution itself, before the output is returned. The signature is deterministic and verifiable independently. Modification is detectable, not preventable.

This is the only architecture that satisfies a regulator who asks the right question — which is always: "How do we know this wasn't changed?"

The answer Axiom gives: because it would break the signature. And the signature can be verified without us.

That is the architecture the AI agent era needs. That is what we built.

Joseph McCann is the founder of Axiom. He previously built AI.FO — a production CFO-reasoning system with 2,000+ deterministic assertions and a sealed-snapshot architecture. He has run Federal Single Audits, GAAP compliance, and ITGC controls across US, UK, France, and Spain.

For inquiries about Axiom's pilot program, contact us. For technical documentation, see the quickstart.