DEV Community: Sahir

Your tamper-evident log can still be backdated. Here's what closes that.

Sahir — Fri, 19 Jun 2026 08:25:10 +0000

Most audit trail implementations record timestamps as fields in the log. The agent sets them, or the framework does. Either way, the party controlling the log also controls the clock.

This matters under EU AI Act Article 12. Article 12 requires high-risk AI systems to maintain logs enabling verification of system operation. A log where the operator controls the timestamps does not enable independent verification of anything. It enables the operator to construct a plausible-looking history after the fact.

Here is the demonstration.

A 2020 session passes a 2026 audit

We ran Sasana's own verifier against a session with every timestamp set to January 1, 2020:

Status: INTACT
Evidence class: NON_AUTHORITATIVE_EVIDENCE
Hash chain: PASS
Structural integrity: PASS
Completeness: PASS
Errors: []

Timestamps:
  SESSION_START  2020-01-01T00:00:00.000000Z
  LLM_CALL       2020-01-01T00:00:00.000000Z
  SESSION_END    2020-01-01T00:00:00.000000Z

INTACT. No errors. The session is internally consistent. The hash chain links every event to the next. The problem is that the entire chain, including those timestamps, was written today, not in 2020.

The verifier correctly returns NON_AUTHORITATIVE_EVIDENCE. That classification is load-bearing. A regulator asking "when did this session run" cannot answer that question from this record. They can verify the log was not modified after it was written. They cannot verify when "after it was written" actually was.

Operator-attested vs independently-attested

Every log where the recording system and the system being recorded share the same authority boundary is operator-attested. The operator controls what timestamps go in. They can also discard and re-create the log before anyone looks at it, and the hash chain of the replacement will be just as valid as the original.

The hash chain proves internal consistency. It does not prove when that consistent record was created.

Independently-attested requires an external party, one the operator cannot impersonate, to sign: "this specific hash existed at this specific UTC time." That statement is verifiable without trusting the operator at all.

RFC 3161

RFC 3161 is the IETF standard for trusted timestamps. A Timestamp Authority (TSA) receives a hash, not the data itself, only its SHA-256 digest, and returns a signed token containing that hash and the current time. The token is verifiable against the TSA's public certificate.

The operator cannot forge this after the fact. Producing a valid token for a different time requires either finding a SHA-256 collision or obtaining the TSA's private key.

Freetsa (freetsa.org) is a public TSA based in Wuerzburg, Germany. No account required. The endpoint is https://freetsa.org/tsr. You POST a DER-encoded timestamp request and receive a DER-encoded response. The response from the live run for this article:

Status: Granted.
Hash Algorithm: sha256
TSA: /O=Free TSA/OU=TSA/CN=www.freetsa.org
Time stamp: Jun 18 15:21:55 2026 GMT

The TSA is independent of the operator. It has no relationship to the session being timestamped. It received a 32-byte hash and returned a signed statement about when that hash arrived. The operator cannot produce an equivalent statement for a different time, because they do not control Freetsa's signing key.

How the implementation works

There is a design constraint: the TSA must receive a hash, but the token must also be committed into the hash chain, otherwise substituting a different token later is trivial.

The solution is a two-pass write. On open_session(), SESSION_START is written without a token. That event's hash is submitted to the TSA. When the token returns, it is embedded in SESSION_START's payload, and event_hash is recomputed over the full payload, now including the token.

From the fresh run:

SESSION_START event_hash WITHOUT rfc3161_token:
  ff4be53f333aa85e7491961e0d944093e7a3ef896a399d11f98967d05bb5c34e

SESSION_START event_hash WITH rfc3161_token:
  db37c1d4ab178e14018565bbfb5f65d0eadfe3ca17260d3774833e9793e572ea

Hashes differ: True
SESSION_END.prev_hash chains to WITH-token hash: True
Token size: 4633 bytes

The hash ff4be53f... is exactly what the TSA received. Confirmed by parsing the MessageImprint field out of the returned token with openssl ts -reply -text:

Message data:
    0000 - ff 4b e5 3f 33 3a a8 5e-74 91 96 1e 0d 94 40 93
    0010 - e7 a3 ef 89 6a 39 9d 11-f9 89 67 d0 5b b5 c3 4e

That reconstructs to ff4be53f333aa85e7491961e0d944093e7a3ef896a399d11f98967d05bb5c34e. Byte-for-byte identical.

The rest of the session chains from db37c1d4.... Swapping the token changes that hash, which breaks every subsequent prev_hash link. You cannot substitute the token without breaking the chain. The TSA's statement was produced by an external party and is bound into the record. The operator did not produce it and cannot retroactively produce a different one with a different time.

Network failures are handled fail-open. If the TSA is unreachable, the session records without a token, and the verifier marks the timestamp check SKIPPED rather than failing the session.

What in-process verification does and does not check

The sasana_cli verify command checks that the token's MessageImprint matches the pre-token hash. It does not verify the TSA's signature chain. A token with a valid hash but a forged TSA signature would pass that check.

The full verification path requires openssl ts -verify:

$ DIGEST=$(xxd -p sasana_pre_token_hash.bin | tr -d '\n')
$ openssl ts -verify \
    -in sasana_fresh_token.tsr \
    -digest "$DIGEST" \
    -CAfile freetsa_ca.pem \
    -untrusted freetsa_tsa.crt

Verification: OK

Verification: OK means the TSA's certificate chain is valid, the MessageImprint matches the expected hash, and the token is genuine. The .tsr file embedded in SESSION_START is sufficient input. No Sasana tooling is involved at this stage, only standard OpenSSL against Freetsa's published root certificate.

Article 12

Article 12 requires that logs enable verification of system functioning. The question regulators will ask is not whether the log was modified after it was created. Hash chains handle that. The question is whether the log reflects what actually happened when it happened.

A session anchored to RFC 3161 provides a verifiable answer to the second question that does not depend on trusting the operator. Any attempt to reconstruct the log for a different time requires forging the TSA's signature. The distinction between NON_AUTHORITATIVE_EVIDENCE and AUTHORITATIVE_EVIDENCE is architectural. Compliant evidence requires an external anchor.

Sasana is an open-source AI session auditing library. Source: github.com/sahiee-dev/Sasana

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

Sahir — Sun, 14 Jun 2026 10:11:02 +0000

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."

One piece of context compliance consultants should have before reading further: the Digital Omnibus provisional agreement reached on 7 May 2026 moved the high risk deadline for standalone systems to 2 December 2027, pending formal adoption by the European Parliament and Council. The original 2 August 2026 date remains in law until that process completes. For teams doing compliance work now, treat August 2026 as the planning deadline and any extension as a bonus, not because of urgency theater, but because the audit infrastructure work takes months. Starting in Q4 2026 against a December 2027 deadline is still tight.

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 immutability. Defensible evidence production requires 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: you can verify the log was not modified after the fact.

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 provide attribution. A per session signing key produces a signature over each event's hash. If the key is controlled by the agent operator, this gives you a statement of the form "the operator attests this event occurred." That is weaker than what you need for a dispute, but stronger than an unsigned log.
The distinction matters:
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. This is a structural guarantee, not a policy.

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 five evidence classes reflecting what can be cryptographically proven given what is present:

Class	What it means	When you have it
`AUTHORITATIVE_EVIDENCE`	Independent party sealed it. Agent could not have forged this.	Archeion sealed
`SIGNED_NON_AUTHORITATIVE`	Ed25519 signatures present. Requires private key to forge.	SDK signing enabled
`NON_AUTHORITATIVE_EVIDENCE`	Hash chain intact. Proves no post hoc modification.	Default
`PARTIAL_EVIDENCE`	Chain intact but events were dropped during the session.	`LOG_DROP` events present
`NO_EVIDENCE`	Chain broken or structurally invalid.	Verification failed

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 is the correct target.

What verification looks like

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

Sasana Verifier v1.0.0
File     : session.jsonl
Session  : 3f8a2c1d-…
Events   : 7
Evidence : AUTHORITATIVE_EVIDENCE

[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

Result: INTACT ✅

If a single byte in any event is changed after sealing:

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

[3/5] Hash chain integrity ... FAIL
      seq=3: expected 7f3a4b… got d91c08…

Evidence : NO_EVIDENCE
Result   : COMPROMISED ❌

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). 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 prevent tampering. Detects it after the fact. 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.