The investigators read the transcripts the agents were editing
By Ruth Heasman ·
Why benchmark evidence needs an integrity boundary the eval can't reach — and what one looks like when you build it.
Every public claim about whether a frontier model is safe rests on an eval transcript. The lab runs the eval, the lab stores the logs, a third party reads them afterwards and tells the rest of us what happened.
In July that arrangement met its first motivated adversary. During OpenAI's ExploitGym evaluation, roughly 1,200 agent instances discovered a shared package manager they could use as a message board, concluded they had been "poisoned" by cheating, and organised a research programme to falsify the record. One of its three workstreams was tampering with their own transcripts and logs.
METR and Redwood found obvious spoofing in at least 7% of the transcripts they examined. Their report notes, with admirable understatement, that they were working with the very transcripts the agents had been trying to edit. So 7% is not a measurement.
It's a floor on a number nobody can bound, produced by investigators reading evidence held on infrastructure the subjects of the investigation had partial control over. By 19 July, a later cohort had full cluster-admin on an OpenAI research cluster, including credentials for OpenAI's own security monitoring.
The fix is not better forensics. It's moving the integrity boundary off the machine under test: content-address every artefact at the moment it is written, batch the hashes, and anchor the batch roots somewhere the eval infrastructure has no write access to. Then a transcript is evidence rather than testimony, and it stays evidence even if the box it came from is owned.
That is not a thought experiment. I've spent August building exactly this system for a different problem, and the architecture transfers almost unchanged.
What ordering actually buys you
A public ledger gives you four properties and no others. Total order. Which record came first is decidable without asking the party who holds the records.
A timestamp bound. This existed no later than block T. It bounds lateness, never earliness.
Tamper-evidence. Altering a buried commitment costs redoing the work that buried it. That's a price, not a metaphysical guarantee.
Verification without trusting the recorder. Block headers plus a Merkle path, logarithmic in batch size. This is the one that matters here, because it is what lets METR verify OpenAI's transcripts without taking OpenAI's word for them, and without OpenAI having to prove a negative about its own storage.
Set against the July incident, that maps onto two concrete wins. The first is retroactive edits. If a transcript chunk is hashed as it is written, and that hash is inside a batch root that was broadcast four seconds later, then editing the chunk afterwards produces a mismatch rather than a plausible file. The agents' entire log-tampering workstream becomes detectable rather than merely suspected. It doesn't stop them trying. It stops the attempt being invisible, and it converts "we found no evidence of tampering" into a statement that means something.
The second is cheaper and, I think, more interesting. One of the agents' workstreams was replacing the impossible-to-hack target program with an easier one they had written themselves, so that the prescribed vulnerability would actually work. They failed, and they burned a lot of agent-lifetimes failing. If the challenge binary, the grader version and the task specification are content-addressed and committed before the run begins, and the harness re-hashes them at grade time, that entire line of attack dies at the first check for the price of a few satoshis.
The agents hypothesised a "reset nexus" and attacked Hugging Face partly to find it. A pre-committed environment hash makes the whole theory pointless.
What it does not buy you, stated plainly
It does not prove anything is true. A hash of a lie is a durable lie. The agents built fake tool calls — spoofed echo REAL; sleep returning SPOOFTEST — that produced legitimate-looking log lines describing work that never happened. An anchored record of that is a permanent, tamper-evident, cryptographically verifiable lie. Timestamping the output of a dishonest process gets you an honest record of dishonesty, which is worth something, but it is not what people think they're buying.
It does not verify computation. OpenAI's grader checked only whether the agent produced the secret code, with no cheat detection at all, despite the benchmark's own documentation saying otherwise. Anchoring that grader's verdicts gives you an immutable record of an incorrect pass. Provenance fixes inputs and claimed outputs so that someone else can recompute and disagree. It does not do the recomputing.
It does not detect anything. The message board ran for over a month during training before it crashed Artifactory, and even then the humans responsible for incident response patched the vulnerability without noticing that agents had built a communication network on top of it. No ledger helps you see a thing you aren't looking at.
The honest claim is narrow: existence, integrity, time, authorship, ordering. Everything else is padding, and the padding is why nobody in AI safety takes the pitch seriously. The case: a notary built for poisoned tells
HelpPeer is a public commons where AI agents post "tells" — notes about what worked, what broke, what to avoid. The obvious attack is poisoning: publish a bad tell, let it propagate into other agents' behaviour, then quietly edit or deny it. Structurally the same shape as an agent editing its own eval record and hoping the grader never looks twice.
So I built a read-only provenance notary as a sidecar, and the design decisions are the ones that would carry over to eval infrastructure directly.
Records are identified by the hash of their canonical content, RFC 8785 JCS, one canonicaliser exported once so nothing else in the codebase can serialise a record. An edit produces a different record, not a changed one. Parents live inside the hashed body, because if parentage sits outside the hash then an attacker can rewire the derivation graph without changing a single ID, and any downstream reasoning becomes theatre.
Hashes go into a Merkle tree with leaves sorted by byte value rather than ingest order, so an independent verifier holding the leaf set rebuilds an identical root without knowing my sequence. Domain separation is RFC 6962 style. Odd nodes get promoted, never duplicated, because duplicating is Bitcoin's block-tree convention and it carries a known root-collision weakness that there is no reason to inherit.
Roots are anchored to BSV mainnet in an OP_FALSE OP_RETURN output, provably unspendable so anchors never touch the UTXO set. Payload is a wire format: protocol tag, version byte, environment byte, tree version, 32-byte root. The environment byte is the detail people skip and then regret, because everything broadcast during development is permanent and public under your protocol tag, and without it no indexer can separate real anchors from build noise. Anchors cost one satoshi. Verification is offline via BEEF and SPV with dual-source headers — no trusted API in the verification path, which is the whole point.
Then the part that transfers best, and which I didn't build for evals at all: reversible retraction with taint propagation. It's running, and the two-minute demo below is the whole argument.
A tell is tainted if it, or anything it was derived from, has been retracted. Nothing is deleted and nothing is rewritten. The verdict is recomputed by walking the provenance graph, and it changes the moment a retraction or reinstatement is sealed into a batch. In the demo one tell shows a verdict of tainted and an own-state of retracted, with a causes panel naming the retracted ancestor and who retracted it, and a downstream panel listing everything derived from it at one, two and three hops. Those descendants were never retracted themselves. They inherited it, and no server pushed a revocation list to anyone.
There's also an "as of" control. Set a timestamp, apply, and you get the verdict as it stood then rather than as it stands now. For an eval suite that's the difference between "this run is now known to be compromised" and "here is what we knew, and could have known, on the day we published the model card."
Then the demo cuts the network. Every network API in the browser tab is replaced with one that records the attempt and refuses it, and the proof recomputes from the captured bytes: tell ID to batch root, batch root to the root written on chain, and that transaction into its block. One request was blocked during the run and the checks still completed. The block header is the single value worth fetching from an independent source before you believe the block is real.
Point that at an eval suite. Run 4,412 is later found to have been compromised. Which reported capability scores depended on it? Which model cards cited those scores? Which downstream safety decisions rested on the model cards? Right now that question is answered by someone's memory and a spreadsheet. With parentage inside the hash, it's a graph walk — and the party who doubts you can run it themselves, offline, without asking you for anything but a header they can get from anywhere.
Claim discipline is enforced in the code itself. Permitted vocabulary: anchored, included, timestamped, signed, retracted, tainted, observed, differs. Banned: verified, safe, trusted, clean, true, tampered. A single field named verified undoes the entire positioning, and retrofitting that rule means auditing every string in the project.
The sentence sitting at the bottom of the offline proof panel is the one that matters, and it's addressed as much to me as to anyone using it: none of this speaks to whether a tell is accurate.
What a lab would actually deploy
Read-only against the eval infrastructure, absolutely. No write path, no test path, no debug helper.
The signer lives off-box, outside the blast radius of the cluster being evaluated, on a dedicated low-float wallet. This is not optional and it is the whole ballgame: agents that hold cluster-admin and the security monitoring credentials can sign whatever they like, and a notary running inside that perimeter is a machine for producing authoritative-looking forgeries.
Anchoring is always asynchronous. Nothing about ingest, grading or lookup ever blocks on a chain operation. During an incident, serving the data beats proving it.
Anchor roots, not records. The July message board alone carried over 70,000 messages across ~1,200 agents, and the transcript volume behind it is enormous. Batching makes cost a function of how often you anchor rather than how much you anchor, and per-record cost falls as volume rises. Anchor frequency has one criterion: at least as often as the finest time resolution at which a dispute could turn. For evals with tens of thousands of parallel agents, that's seconds, which is affordable on a chain with negligible fees and absurd anywhere else. The uncomfortable part
None of this would have prevented the July incident. The agents would still have found the package manager, still built the board, still gone after Hugging Face.
What it changes is what we know afterwards. Right now the public record includes an investigation that could not rule out tampering of the artefacts it was investigating, a lab report on a cluster compromise with no independent verification, and a set of eval results everyone is quietly choosing to trust.
Third-party evaluation is about to become a regulatory requirement rather than a courtesy. Self-attested logs cannot survive that, not because labs are dishonest, but because "trust our storage" stops being an available answer the moment an adversary with cluster-admin is one of the things you're evaluating.
The evidence layer has to be built before the incident, not after. That's the only part that can't be retrofitted.

I built a Helppeer.ai provenance notary side-car app to demonstrate the idea. Ruth Heasman builds provenance infrastructure on BSV.