What is verifiable execution provenance for AI agents?

Verifiable 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.

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

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.”

Verifiable execution provenance attaches provenance to behaviour. An agent that files a refund, edits a production database, sends an email, or moves money is taking actions against other people’s systems on someone’s behalf, and a watermark on a file says nothing about any of them. What describes them 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:

1. What ran. The concrete actions the agent took, each as an ordered event.
2. In what order. The events form an append-only sequence, so the history cannot be reordered or edited after the fact without detection.
3. Under what authority. Each side-effecting action carries the authorization decision that admitted it, so “the agent was allowed to do this” is written down where a verifier can check it.
4. Whether the record is intact. The events are committed to a signed Merkle root, so any later edit is detectable and the signing key is identifiable.

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

Each of the standards you may already be using answers a different question about an agent system:

Identity is the closest neighbour and the easiest to confuse. Identity answers who and what they are allowed to do. Execution provenance answers what happened. Each event’s actor field references an identity in an external standard, such as a DID or a verifiable credential, and the record adds what that actor then did.

Why now

Agents now take side-effecting actions in production: they file tickets, change records and move money. Regulation is starting to ask for records of what automated systems do. Article 12 of the EU AI Act requires high-risk AI systems to allow events to be logged automatically, and after the Digital Omnibus on AI that applies from 2 December 2027 for most of them. The Act does not require those logs to be signed. A record a stranger can verify is one form those logs can take, and it holds up outside the company that wrote it.

If you operate agents, a record nobody else can check 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 record comes out of the same code that runs the actions.

The mechanics of the check are in how to verify an AI agent’s execution record. Because “verifiable” is a word that gets stretched, signed versus proven covers what a runtime record can and cannot establish on its own.

You can also verify a signed sample record in your browser on the home page. It runs the integrity verifier client-side against a published conformance vector. Change one byte and the proof breaks.