Tamper-evident agent audit trail.

A cryptographically chained record of every AI agent action where any modification is mathematically detectable, verifiable offline, without contacting the vendor.

What it is

A tamper-evident agent audit trail is an append-only record of every action an AI agent takes, along with the runtime's verdict on that action, structured so that any later change to any record is detectable with cryptographic certainty.

It is the answer to the auditor's question: show me what happened, and prove no one edited the log.

Tamper-evident vs tamper-resistant

"Tamper-evident" is a stronger property than "tamper-resistant". A tamper-resistant log is hard to modify.

A tamper-evident log guarantees that if it is modified, even by an insider with full access to the storage, the modification cannot go unnoticed.

Why it matters

Regulators, insurers, and courts have had decades to become skeptical of application logs. A log is only as trustworthy as the party that operates it. And the party that operates it usually also has a motive to fix embarrassing entries.

In AI agent governance, this problem is acute: agents can act at machine speed, so a single unreviewed action might affect thousands of customers before anyone reads the log.

A tamper-evident audit trail changes the trust model:

• Offline verifiability. An auditor with a public key and the log file can verify every entry without any online service.
• Insider-safe. Even the system administrator cannot silently rewrite history. Any edit invalidates the chain from that point forward.
• Regulator-ready. Frameworks including the EU AI Act (Article 12, logging), HIPAA (audit controls), and SOC 2 (log integrity) can all be satisfied with a signed chain plus a documented verification procedure.

How it works

A verifiable trail is built from three primitives applied in a specific order — canonicalisation, content hashing, then chain linking — plus a signing layer that turns integrity into checkable origin.

1. Canonicalisation

Before hashing, each record is transformed into a byte-exact form using a defined specification. Field order, key sorting, whitespace, string encoding, and null handling are all fixed by rule. Two independent implementations of the canonicaliser produce byte-identical output from the same input.

Without canonicalisation, two verifiers computing "the hash of this record" can disagree over trivial formatting differences and the trail is not really verifiable. This is the primitive most descriptive-log systems skip.

2. Content hashing

The canonical form is hashed with SHA-256. The output is a fixed-size, deterministic, collision-resistant digest. This becomes the record's payload_hash.

3. Chain linking

Each new record includes the payload_hash of the previous record in the same tenant's sequence, stored as prev_hash. The result is a hash chain: any modification to record N invalidates the hash comparison at record N+1, and every record after that. To hide a change, an attacker would have to recompute the entire suffix of the chain and re-sign it.

Signing: origin as a checkable property

Hash chains prove integrity and ordering. They do not prove origin — any party with write access to the storage could produce a valid chain. Origin comes from signing.

The Veldt runtime uses HMAC for high-throughput per-entry integrity (fast, symmetric, suits the hot path) and Ed25519 signatures for offline verifiability of periodic chain roots and exported compliance packs (asymmetric, so a third party can verify without holding the secret).

Auditors fetch the Veldt runtime's public key by signing_key_id from a well-known URL; from that point on, they can verify any exported log slice without contacting Veldt.

What every entry captures

The five fields captured in every entry are:

• The action requested
• The delegation chain that authorized it (see delegation attribution)
• The runtime verdict (allow, redact, throttle, escalate, or block) and the trust score that produced it
• The policy that produced the verdict
• The timing metadata for the perimeter decision

Descriptive logs are not audit trails

OpenTelemetry traces, application logs, and LLM call records give you timestamps, correlation IDs, request/response bodies, latency, error stacks, and resource attribution. They do not give you signatures, hash chains, canonicalisation, published verification keys, or chain-of-custody metadata.

An OpenTelemetry trace can be modified by anyone with write access to the trace backend. Nothing in the trace protocol prevents this. Nothing in the trace protocol lets an outside party detect it.

This is not a criticism of OpenTelemetry — it is superb for operational visibility. It was never designed to produce evidence. When a vendor markets an observability stack as "the audit trail for AI agents", they are conflating two different disciplines: the trail satisfies operational questions ("what did the system do?") but not evidentiary questions ("can you prove what the system did to an outside party?").

Verification checklist

If you are evaluating an audit-trail implementation for verifiability, the floor is:

• Records are cryptographically hashed with a documented canonicalisation and a modern hash function (SHA-256 or better).
• Records are chained via prev_hash linking each to its predecessor within a tenant scope.
• Chain heads or compliance packs are signed with Ed25519 (or an equivalent modern signature scheme), not just hashed.
• Public verification keys are published at a well-known URL, versioned, and indexed by key id.
• Retired keys remain published long enough to cover the platform's evidence retention window — otherwise packs older than the last rotation cannot be verified independently.
• Key revocation state is distinguishable from routine rotation, so a compromised-then-revoked key is not silently mixed in with safely retired ones.
• Compliance packs include chain-segment metadata so gaps in coverage are detectable.
• A reference verifier is provided and the canonicalisation is documented precisely enough that an independent verifier can be built from the specification alone.
• Chain-of-custody metadata is captured on records that will be forwarded between systems.

Anything less than this list is descriptive logging with cryptographic decoration. It looks like evidence at a glance and stops looking like evidence the moment a serious verifier examines it.

How it appears in the KYA paper

The KYA paper introduces the tamper-evident trail as one of five architectural primitives for runtime governance. The paper specifies the exact record format, the hash-chaining rule, and the export format that auditors verify against.

Two properties are proven: any single-entry modification is detectable in constant time, and the ordering of entries is preserved under any legal export.

Combined with only-tighten composition, the trail gives you a complete accountability picture. Not just what happened, but who authorized it and why the runtime allowed it. All of it verifiable without trusting Veldt.

What it enables in practice

The tamper-evident trail is what turns runtime governance into a legal artifact. Three examples:

• A financial services firm can hand a signed log slice to its regulator and defend the AI agent decisions in it.
• A hospital can produce a signed record of every clinical-AI action for a PHI audit.
• A defense contractor can prove, to a customer's auditor, that a specific agent action was authorized under a specific human's delegation.

None of these workflows work with an ordinary log: the auditor has to trust the operator. All of them work with a tamper-evident trail, because the math replaces the trust.