Your AI agent logs satisfy Article 12. They won’t survive a dispute.

Updated 2026-10-10. Sasana 2.0.0 corrects how verification results should be read. Versions 1.0.0 and 1.1.0 reported AUTHORITATIVE_EVIDENCE for a valid seal even when the verifier had not been given the Archeion public key, and accepted a log whose seal had been removed even when a key was pinned. This post has been revised to match 2.0.0. See the 2.0.0 changelog.

What Article 12 actually says

The regulation text is precise: “High-risk AI systems shall be designed and developed with capabilities enabling the automatic recording of events (‘logs’) throughout the lifetime of the AI system.”

A note on dates, because they moved. The Digital Omnibus (Regulation (EU) 2026/1744) entered into force on 27 July 2026. It moved the start of the high-risk obligations to 2 December 2027 for stand-alone systems (Annex III) and 2 August 2028 for AI built into products already regulated under Annex I. Article 12 is a requirement for high-risk systems, so it applies from the date that applies to your system; check which category yours falls in and confirm the dates against the Official Journal text. There is no August 2026 cliff. The useful way to read the change is lead time: audit infrastructure, key custody and retention take months to stand up, and starting well before your date is cheaper than starting late.

Now, to the logs themselves.

What your current tooling produces

LangSmith, Arize, Langfuse, Helicone, and Datadog are good tools. They were built for what they do: real-time debugging, cost tracking, performance monitoring, and observability. None of this is in dispute.

What they produce, structurally, is mutable records in operator-controlled storage. An administrator with database access or filesystem permissions can modify or delete a record after the fact. There is no detectable trace of that modification. The log still exists. It satisfies Article 12’s “automatic recording” requirement. It does not prove it hasn’t been touched since the event occurred.

This is not a criticism of those tools. It is a structural property of how they were designed. They were not designed for evidence production.

One objection worth addressing directly, because it appears in analyst commentary: “Article 12 does not require tamper-evident logging.” That is technically correct. The regulation uses “logs,” not “tamper-evident logs.” The counterargument is not about the regulatory minimum. It is about what happens when you need to use the log as evidence.

Article 9 requires a risk management system for high-risk AI systems. When an incident occurs (a credit scoring model produces a discriminatory output, a medical AI diagnostic is challenged, an AI recruitment tool is investigated) and a regulator or counterparty demands your logs, “we have logs but cannot prove they weren’t modified” is a gap in your risk management system. The regulation doesn’t mandate cryptographic integrity protection. Defensible evidence production calls for it regardless.

A log that cannot prove its own integrity is not the same as a log that records something.

What tamper-evidence actually requires technically

Three properties make a log forensically credible. Each is a distinct technical problem.

Integrity. Any modification to a historical record must be detectable. The mechanism: SHA-256 hash over RFC 8785 canonical JSON, chained via a prev_hash field. Each event commits to all prior events. Changing any byte in any prior event breaks every subsequent hash. Canonical JSON (RFC 8785) matters because without a deterministic serialization, two implementations can hash the same logical object to different bytes, producing different hashes for identical content, or the same hash for different content. The chain gives you internal consistency: edits to individual events are detectable. It does not stop someone who can write the whole file from rebuilding a consistent chain (see below).

Attribution. A hash chain proves internal consistency. It does not prove who wrote it. An operator who controls the storage can rewrite the entire chain, generating a fresh, internally-consistent chain where every hash is correct and every event is fabricated.

Ed25519 signatures bind events to a key, not to a person. A per-session signing key produces a signature over each event’s hash, and its public key is recorded in the log itself. Whoever rewrites the log can generate a new keypair, replace that key and re-sign everything, so this shows consistency, not identity: at most “whoever held this key signed these events.” That is weaker than what you need for a dispute. Operator-attested evidence and independently-attested evidence are not the same thing.

Independence. The entity that seals the log must be structurally separate from the entity that operates the agent. If the same team controls both the agent and the sealing authority, a sophisticated adversary who owns the team can forge both the log and the seal.

The correct architecture separates these two roles:

┌──────────────────────────────────────────────────┐
│  Agent process  (operator trust boundary)        │
│                                                  │
│  SDK records events → JSONL                      │
│  SDK cannot emit CHAIN_SEAL events               │
└──────────────────────────┬───────────────────────┘
                           │  POST /seal
                           ▼
┌──────────────────────────────────────────────────┐
│  Archeion sealing server  (security team boundary)│
│                                                  │
│  Verifies hash chain integrity                   │
│  Appends CHAIN_SEAL with Ed25519 signature       │
│  Returns sealed JSONL                            │
└──────────────────────────────────────────────────┘

The SDK enforces the boundary at the type level: EventType.is_sdk_authority blocks any attempt by the agent process to emit a CHAIN_SEAL event. The agent cannot produce its own seal. A verifier recognises a seal as Archeion’s only if it checks it against Archeion’s public key, which you record when you deploy it and pass as --trust-key. With that pin, the agent cannot produce a seal that verifies. That is not the same as the operator being unable to get Archeion to seal a rewrite: Archeion authenticates no callers and remembers nothing it has sealed, so the separation holds only against people who cannot reach it. Without the pin, a seal shows only that the file is self-consistent: anyone can generate a key and seal a rewritten log.

Archeion runs inside your security perimeter, controlled by your security team, not the agent developers. No session content leaves: only hashes pass through POST /seal. The sealing authority appends one event and returns the sealed log.

Evidence classes

Not every deployment has an independent sealing authority. The verifier produces six evidence classes reflecting what the log can and cannot show, given what is present and what you tell the verifier to trust:

For most internal compliance purposes, NON_AUTHORITATIVE_EVIDENCE is sufficient. For regulatory submissions and legal proceedings where the operator is a party to the dispute, AUTHORITATIVE_EVIDENCE(a seal verified against the Archeion key you pinned, with Archeion kept out of the operator’s reach) is the correct target.

What verification looks like

$ sasana verify session.jsonl --trust-key <archeion-pubkey> --strict

Sasana Verifier v2.0.0
Events: 5  Evidence: AUTHORITATIVE_EVIDENCE
Trusted key: pinned (--trust-key)
Canonicalization: jcs-rfc8785

[1/5] Structural validity  ... PASS
[2/5] Sequence integrity   ... PASS
[3/5] Hash chain integrity ... PASS
[4/5] Session completeness ... PASS
[5/5] Seal signature       ... PASS  (signed by the pinned key)

Result: INTACT ✅

If a single byte in any event is changed after sealing (abridged output):

$ sasana verify tampered.jsonl --trust-key <archeion-pubkey>

Evidence: NO_EVIDENCE
Trusted key: pinned (--trust-key)
...
[3/5] Hash chain integrity ... FAIL
...
Result: COMPROMISED ❌
  → seq=4 (SESSION_END): event_hash mismatch

The verification binary has no external dependencies. It reads one file, checks five properties, and exits 0 (INTACT), 1 (COMPROMISED), 2 (PARTIAL) or 3 (ERROR), while --strict (which requires --trust-key) fails unless the result is INTACT with AUTHORITATIVE_EVIDENCE. Exit 0 also covers INTACT with a weaker evidence class, so read the class or use --strict. No network calls. No API keys. No running server required. A Rust binary ships alongside the Python implementation for forensic environments where Python is not available.

Archeion is self-hosted: it runs as a container inside your perimeter. The deployment guide covers docker-compose, key lifecycle, and network isolation. The signing key is a CA-root-equivalent: generated once, retained for the lifetime of sealed sessions, rotated only on compromise.

What Sasana does not do

• Does not record raw content. Hashes only. You cannot reconstruct what the agent said from a Sasana log.
• Does not stop a rewrite that the real Archeion seals later. Archeion authenticates no callers and keeps no record of what it has sealed, so anyone who can reach POST /seal can get a consistent chain sealed, including a rewritten copy of an earlier session. Keep Archeion unreachable from the people being audited and seal at session end.
• Does not prevent tampering. Detects it after the fact, and a complete rewrite of the file only with a seal verified against a pinned key. Detection and prevention are different properties.
• Does not replace LangSmith or Arize. Those tools are for debugging and observability. Sasana is for evidence production. The two are complementary.
• Does not rate-limit, filter, or modify agent behaviour.
• Does not currently have a managed cloud offering. Self-hosted only.

Further reading

• EU AI Act Article 12 · EUR-Lex official text
• IETF draft-sharif-agent-audit-trail-00 (March 2026) (Internet-Draft, expires September 2026). Consult the IETF datatracker for current status.
• Sasana on GitHub