Tamper-evident is not tamper-proof.

Ask a team how they would prove what their AI agent did, and many will reach for signatures. Ed25519. HMAC. A hash chain. These are good cryptographic primitives. But they do not prove what most people think they prove.

"Tamper-evident" is a precise term that is easy to misread. Understanding where it stops — and where a public anchor begins — is the difference between a record an auditor can verify and a record an auditor must simply believe.

What tamper-evident actually means.

A tamper-evident record is one where any modification is detectable after the fact. The mechanism is cryptographic hashing: compute a hash of the record at capture time; later, recompute it. If the hashes match, the record has not changed. If they diverge, it has.

This is fast, reliable, and entirely mathematical. It works. And it answers exactly one question: has this record changed since the reference hash was computed?

It does not answer the question underneath: who computed the reference hash, when, and can I trust that they did so faithfully at the moment the decision happened?

The signature problem.

Most "tamper-evident receipt" systems work like this: the system signs its own records. The party that made the decision holds the signing key. You verify the signature against the public key. If the record and the signature match, the record has not changed since it was signed.

But signing and signing-at-the-right-time are different things. The same party that made the decision also held the key. That means they could, in principle:

• Construct a record after the fact and sign it with the time they choose
• Sign a record that omits a step, softens an output, or reframes what the agent did
• Rotate their key and re-sign an altered historical record

A signature tells you: this record was signed by the holder of this key. It does not tell you: this record was created at the moment the decision happened and faithfully describes it.

To an independent auditor — a regulator, a counterparty, an external compliance team — a signature is still a trust claim. "Trust our key infrastructure" is better than "trust our database entry," but it is not fundamentally different in kind. The party that made the decision is still in the trust path.

This is the gap between tamper-evident and operator-independent.

What a public anchor adds.

A public anchor works differently. Instead of asking a key-holder to attest to the record, you commit the record's digest to a public, append-only log — a log that neither you nor any single party can control or rewrite.

The mechanism in practice: OpenTimestamps takes any SHA-256 digest, aggregates many of them into a Merkle tree, and commits the root to the Bitcoin blockchain. The proof that a specific digest was included in that tree is a compact binary object: an OpenTimestamps proof file. Anyone with that proof file and read access to the public blockchain can verify — independently, offline, without contacting any server — that the digest existed before a specific block's timestamp.

What this changes in the trust model:

• No key to trust. Verification uses only the public blockchain and mathematics. The signer's key infrastructure is not in the path.
• No back-dating. A Bitcoin block's timestamp is backed by proof-of-work — you would need to redo the computational work of the entire network from that block onward to alter it. That is not a practical attack.
• No vendor. Not Determs, not OpenTimestamps, not the calendar operators. The verification depends only on the open-source OTS libraries and the public blockchain, both of which any party can run independently.

A public anchor is the difference between "trust our signature infrastructure" and "check the maths yourself."

For compliance purposes, this matters. An auditor who receives a signature-backed record must decide whether to trust the signing party's key management. An auditor who receives an anchor-backed record can verify existence-in-time without trusting anyone — including us.

What even a public anchor does not prove.

This is equally important to state clearly.

A public anchor proves two things about a record:

• Existence in time: this exact record (and only this record) existed before the anchor's block timestamp. Its digest was committed to public infrastructure at that moment.
• Integrity: the record has not been changed since that commitment. Any modification would break the digest.

What it does not prove:

• That the action described in the record actually occurred as described
• That the tool outputs recorded in the subject field are accurate — the producer wrote those values; the anchor commits to what the producer wrote, not to the underlying reality
• That the decision was the correct or compliant one
• That the producer did not lie in constructing the record before anchoring it

The honest framing is: the record is accountable, not correct. Accountable means the producer is locked into a specific claim. If they stated the model returned X, and the record is anchored, they cannot later claim the model returned Y. The anchor creates accountability for the stated record. It does not validate the underlying reality against which the record was written.

This is not a limitation of the approach — it is an honest description of what cryptographic timestamping can and cannot do. And it turns out that accountability is precisely what auditors and regulators are looking for: not a guarantee that the AI made the right call, but a commitment to what it claimed to have done. That is the layer where an audit starts.

The layered picture.

These distinctions map cleanly onto a layered architecture:

• A runtime receipt — the immediate capture of what happened, at the moment it happened. Deterministic digests. No network required.
• An integrity envelope — the hash chain or signature that lets you verify the receipt has not changed. This is the tamper-evident layer.
• A public anchor (optional) — existence-in-time committed to public infrastructure. This is the operator-independent layer. No key in the trust path.
• A deterministic archive — stored, addressable records with the ability to replay the record and verify the digests on demand.

Most systems implement the first two layers. The public anchor is the layer that makes the record independently verifiable — and the layer that most current AI audit systems skip or treat as optional.

How Determs implements this.

A Verifiable Decision Record carries all four layers in a single self-contained JSON object. The receipt holds the four digests (record, subject, input, output) computed by canonicalizing the record per RFC 8785 (JCS) and hashing with SHA-256. The anchor is pluggable — the spec supports any append-only public log as an anchor type; the current default is OpenTimestamps.

Verification is a single CLI command:

$ determs verify --record ./record.json

{
  "verified": true,
  "profile": "ai.agent.action",
  "record_digest": "44f2b549...",
  "checks": {
    "subject_digest": true,
    "record_digest": true,
    "input_digest": true,
    "output_digest": true
  }
}

The verifier does not need an account with us, a running service, or trust in our key infrastructure. The spec is open (CC-BY-4.0), the reference implementation is open-source (Apache-2.0), and the anchor resolves against public infrastructure.

If you have AI decisions in production that need to be auditable — for a regulator, a counterparty, or your own incident response — the distinction between tamper-evident and operator-independent is not academic. It is the difference between a record that stands up in a dispute and one that only holds until someone has a reason to question it.

Verify a record yourself, read the spec, or see the implementation guide for a step-by-step walkthrough with working code.