What is verifiable execution provenance?
5 min readVerifiable execution provenance is a portable, third-party-verifiable record of what a software agent did: which actions it took, in what order, and under what authority. Anyone holding the record can check it against a published key and confirm it has not been altered since it was emitted, without trusting the system that produced it.
That last clause is the whole point. Plenty of systems can show you a log of what an agent did. The question is whether a stranger can check that log without taking your word for it.
Provenance of actions, not content
The word “provenance” is already familiar from a neighbouring problem. C2PA attaches provenance to content: it answers “was this image or video AI-generated, and by whom.” That is a real and separate need.
Verifiable execution provenance attaches provenance to behaviour. An agent that files a refund, edits a production database, sends an email, or moves money is not producing a piece of media. It is taking actions against real systems on someone’s behalf. The artifact that matters there is not a watermark on a file. It is a record of the actions themselves, one that a third party can verify.
The four things a record answers
A record worth trusting commits to four facts:
- What ran. The concrete actions the agent took, each as an ordered event.
- In what order. The events form an append-only sequence, so the history cannot be quietly reordered or edited after the fact.
- Under what authority. Each side-effecting action carries the authorization decision that admitted it, so “the agent was allowed to do this” is a recorded fact rather than an assumption.
- Whether the record is intact. The events are chained into a signed root, so any later edit is detectable and the emitter is provable.
The first three describe the run. The fourth is what makes the first three checkable by someone who was not there.
Where it sits among the standards
Verifiable execution provenance is a sibling to the standards you may already be using, not a rival to them. Each answers a different question about an agent system:
| Standard | The question it answers |
|---|---|
| C2PA | Is this content AI-generated, and by whom? |
| MCP | How does an agent connect to tools? |
| A2A | How do agents talk to each other? |
| W3C Verifiable Credentials and agent-identity work | Who is this agent, and what is it authorized to do? |
| SCITT | How are signed statements registered and receipted? |
| Provetrail | What did the agent do, provably? |
Identity is worth calling out because it is the closest neighbour and the easiest to confuse. Identity answers who and what they are allowed to do. Execution provenance answers what actually happened. A record references an identity; it does not replace one. The two compose.
Why this matters now
Two things arrived at the same time. Agents began taking real, side-effecting actions in production, and regulation began asking for records of automated decisions. The EU AI Act, whose transparency obligations under Article 50 apply from 2 August 2026, points toward automatic, auditable records of what automated systems do. A content-provenance standard covers the media half of that. An execution record is the missing half.
The pull is not only regulatory. If you operate agents, an untrusted record is a liability the first time something goes wrong and you cannot prove what happened. A verifiable one turns “trust us” into “check it yourself.”
How you would use it
You would attach a record to a run, hand it to whoever needs assurance (an auditor, a customer, a counterparty, your own future self), and they would verify it independently. No access to your infrastructure, no shared trust in your logging.
The standard is meant to be implemented by any runtime. The reference implementation is Flynn, an open agent runtime (a single Go binary) that emits these records as it executes, so the proof is a byproduct of the run rather than something bolted on afterward.
The mechanics of that check are worth seeing in detail: how third-party verification works. And because “verifiable” is a word that gets stretched, it is worth being precise about the ceiling: signed versus proven covers what a runtime record can and cannot establish on its own.
You can also verify a real record right now, in your browser, on the home page. It runs the actual verifier client-side against a signed conformance vector. Change one byte and the proof breaks.
Last updated: 12 July 2026.