What a verifiable record of an AI agent's actions requires — and what it can't fix

When an autonomous agent breaks something, the first question is not what it did but whether anyone can prove what it did.

In the OpenAI and Anthropic cybersecurity-evaluation incidents of July 2026, every public account of what the agents did traces back to the company that ran them. Hugging Face holds one half — the actions its own systems recorded. Only the lab holds the other — the agent's reasoning and tool calls. Hugging Face's CEO asked OpenAI to release the full execution traces; OpenAI has not. The argument over those traces is the clearest statement yet of a gap the field has been circling for a year.

Two problems are being run together, and separating them is the first useful thing anyone can do.

Disclosure is whether a record of what the agent did exists and is released at all. This is a matter of incentive, policy, and law. As of August 2026, no incident-disclosure framework in force — not CVE, NIST's AI RMF, OWASP, MITRE ATLAS, the voluntary incident registries, the EU AI Act's Article 73, nor the Cloud Security Alliance's proposal — requires an agent's execution trace to be produced or released. A party that would rather not record what its agent did, or not release it, is under no obligation to. No cryptography changes that. If the trace is never written or never shared, there is nothing to verify.

Trust is the separate question of whether a record, once released, can be believed by someone who was not in the room. This is the part cryptography addresses, and the part that is largely solved. It is worth being precise about what "verifiable" has to mean before the word is worth anything.

A record of an agent's action is verifiable when a third party can establish, without trusting whoever produced it:

• that the record is bound to the action — the identifier is a hash over the actual bytes of what happened, not a label attached beside them;
• that the record has not been altered since it was written — it sits in an append-only history where changing or removing an earlier entry is detectable;
• that the same record was shown to everyone — the producer cannot present one version to an auditor and another to a regulator;
• that the history was not quietly rewritten — independent parties, unrelated to the producer, attest to each published state, so the producer's own say-so is not the only evidence;
• that "when" is not the producer's word — the history is timestamped into a medium neither party controls, so the ordering and the clock are external;
• that nothing was withheld, to the extent the record makes omission detectable — the hardest of these, and the one most systems skip.

A record with these properties can be handed to an adversary and checked offline, from published artifacts, with no account and no trust in the party that produced it. That is the whole point of the word. A record that lacks them is a claim, however sincere — and "trust the company that ran it" is exactly the position the current incidents leave everyone in.

None of this is new machinery. It is the transparency-log design that has underpinned Certificate Transparency and software supply-chain provenance for a decade — append-only Merkle logs, inclusion proofs, cosignatures from independent witnesses, timestamping into Bitcoin — applied to the record of what an agent did. What is new is only the subject.

What it does not do

Stated plainly, because overclaiming is how this category loses its credibility:

• It does not produce the trace. Verification presupposes a record. It cannot compel a lab to instrument its agents, retain what they did, or release it. The fight over the OpenAI traces is a disclosure fight; a verification layer has nothing to say about it until a record exists.
• It does not make the content true. A verifiable record establishes that these exact bytes existed, in this order, unaltered, attested by parties with no reason to collude. It does not establish that the bytes describe what really happened. A faithfully anchored false record is still false. Verification moves trust from the producer to the record; it does not remove the need to judge the record.
• It does not assign authority or liability. Whether an agent was permitted to act, on whose authority, and whether that authority had been revoked, is a separate layer that sits on top of the evidence. A verifiable record is the substrate a liability question can be argued over; it is not the answer to it.
• It cannot force a standard into being. Whether anyone is required to keep such a record is the disclosure question again, decided by regulators and standards bodies, not by a log.

The contribution here is narrow and load-bearing: the industry is arguing about traces as if trust and disclosure were one problem. They are two. Disclosure is unsolved and political. Trust in a disclosed record is solvable, and for the most part solved — the design has existed for years and runs in production today. An agent's action hash can be anchored into a witnessed, append-only log and verified by anyone offline; a working example — an ERC-8004 mandate envelope anchored and then independently re-verified leg by leg — is on GitHub. That does not end the incident. It ends the excuse that "trust us" is the only option once a record is on the table.

The traces will be argued over on other grounds — research value against the fact that a full intrusion trace is also an attack playbook. That argument is real, and not one a log can settle. But when it settles, and a record is finally put on the table, whether to believe it should already have an answer that does not depend on the word of whoever ran the agent.

Markovian Protocol runs a public, append-only transparency log — witnessed by seven independent operators and timestamped into Bitcoin. See how it works, or verify the current head in your browser.