Tamper-evident is a stronger word than teams realise

I have watched this exchange happen in a dozen rooms. Someone reads the phrase “tamper-evident” out of a requirement, an engineering lead says the logs are in object storage with versioning and restricted write access, and everyone moves on to the next line item.

The answer is not wrong about the technology. It is answering a different question from the one asked, and the substitution is invisible until somebody outside the organisation asks who could have changed the record and how you would know.

My position: tamper-evident is a claim about detection by a party who does not trust you, and most delivery pipelines cannot support it, not because they lack a feature but because the same small group of people controls both the process and the evidence of the process. I am not a lawyer and this is not legal advice. It is an argument about how to build.

The word forces four questions

Tamper-resistant means altering the record is hard. Tamper-proof means it is impossible, which is a marketing word. Tamper-evident means something narrower and more demanding: alteration may well succeed, and it will be apparent afterwards that it happened.

That word choice is not decoration. It shifts the burden from prevention, which nobody can guarantee, to detection, which you can actually design for. And detection only means anything once you answer four questions.

Evident to whom

The team that owns the pipeline, or a party who assumes the team might be the problem? Only the second answer is worth anything in an investigation.

Evident how

By a check somebody runs, or by an inconsistency that surfaces without anyone looking for it? Detection that depends on suspicion arrives too late.

Evident against whom

An outside attacker, a careless engineer, or an insider with production credentials and a reason? The last one is the case the word exists for.

Evident how long after

Within the hour, or during an investigation two years later when the people involved have left? The gap between those is where most designs quietly fail.

Access control is prevention, not evidence

Restricted write access, immutability windows and versioned buckets are all good and you should have them. They are prevention controls, and prevention controls share a structural weakness: the person who holds the key is outside the control’s scope.

Ask the practical version. In your organisation, who can alter or delete a delivery record? Usually the answer is a platform team, a handful of administrators, and any process holding their credentials. Now ask whether any of those parties would be caught. The honest answer in most places is that they would be caught if someone already suspected them and went looking, which inverts the point. Evidence is supposed to be what creates suspicion, not what confirms it.

This is why the strongest control in this area is not cryptographic at all. It is separation: the record of what happened is written to somewhere the people who performed the action cannot modify. Everything else is refinement on top of that.

Where agent pipelines specifically fail

Three failures show up repeatedly, and none of them look like tampering when they happen.

History is rewritten as routine practice. Squash merges, rebases and force pushes are normal engineering hygiene and they destroy the sequence of what actually occurred. A squashed commit authored by a service account tells you a change landed. It does not tell you what the agent produced first, what a human changed, or in what order. Nobody tampered with anything. The record simply never existed in a form that could be tampered with.

The actor is a shared identity. When the committer is a service account used by every agent run in the organisation, the record attributes the action to a role rather than a party. Under the EU AI Act’s transparency expectations, systems are meant to disclose themselves and generated content is meant to be marked. A shared bot identity discloses that something automated acted, which is the easy half, and loses which run, under which configuration, on whose authority.

The evidence lives in the system it describes. If the pipeline that performs the change is also the pipeline that writes and stores the record of the change, then compromising or misconfiguring one compromises both. This is the most common design and the least defensible one.

What most teams have

• Records written by the pipeline that acted
• Administrators who can edit silently
• History rewritten by normal merge practice
• One service identity for all agent runs
• Detection only if someone goes looking

What the word actually requires

• Records written where the actor cannot reach
• Any alteration leaves an inconsistency
• Sequence preserved independently of git history
• Run, configuration and authorising human distinguishable
• Detection by a party who assumes bad faith

The cheapest thing that gets you there

You do not need a distributed ledger and you should be sceptical of anyone selling you one for this.

Write the record at the moment of the event, not reconstructed later from git. Include what acted, what it acted on, what authorised it and what checks passed. Send it to a store owned by a different team with append-only semantics and no delete path for the writer. Chain each entry to the previous one so a removed entry leaves a gap that shows up without anyone hunting for it. Have someone outside the delivery team verify the chain on a schedule, and record that they did.

That is a week of work for most platform teams. The reason it is rare is not cost. It is that it requires one team to accept that another team owns the evidence about their work, and that conversation is harder than the engineering.

Where this breaks down

Separation of duties is genuinely expensive at small scale. In a twenty person company, the platform team and the delivery team are four of the same people. You can still get partial value from a third party store with credentials nobody holds routinely, but pretending you have independent verification when you do not is worse than admitting the gap.

Chained records solve less than they appear to. They prove a sequence has not been altered after the fact. They prove nothing about whether the entries were true when written. An agent pipeline that logs a check as passed when it never ran produces a perfectly consistent, perfectly useless chain. Integrity of the record and truth of the record are separate problems and only one of them has a neat technical answer.

This can become theatre very quickly. Organisations that adopt evidence controls sometimes stop there, treating the existence of a chain as the outcome. Nobody verifies it, nobody has ever been asked to produce a specific record, and the first real test comes during an incident. A control nobody exercises is a control you do not have.

The requirement may not apply to you. The specific obligations in the AI Act attach to particular categories of system, and most delivery pipelines are not themselves the regulated system. My argument is that the design is worth adopting anyway because it answers the incident question, not because a regulator is coming for your CI. If you adopt it purely from fear, you will build the minimum and get the theatre.

The takeaway

Tamper-evident is not a storage setting. It is a claim that someone who had both the ability and the motive to alter your record could not have done so unnoticed, and it is verified by a party who starts from the assumption that they might have.

Test your own pipeline against the four questions: evident to whom, by what mechanism, against which insider, and how long afterwards. Most designs pass the first and fail the rest.

If you take one thing into next week: name every identity in your organisation that could delete a delivery record today without leaving a trace anyone would notice. If that list takes more than five minutes to produce, that is the finding.