Does a valid signature prove an agent did the work it claims?

No. A signature proves that a particular key emitted a particular set of bytes and that they were not altered afterward. If the component doing the work also writes and signs its own record, a valid signature tells you the emitter asserts something happened, not that it did.

What can a Provetrail record prove today?

That the record is intact and untampered since emission, that it was signed by a named key you can check, that each side-effecting action carried a recorded authorization decision, and that a claimed success is bound to committed evidence of a check. What it does not prove on its own is that the runtime emitting it was not itself modified, or that no events were omitted.

Signed vs proven: what a runtime record can and can't prove

July 11, 2026 6 min read

A signature proves that a specific key emitted a specific set of bytes, and that nobody changed them afterward. It does not prove the work behind those bytes was real. If the same component that does the work also writes and signs the record of the work, a valid signature only tells you that the emitter asserts something happened. Whether it happened is a separate question, and it is the one that matters.

This is the difference between an attestation and a proof, and it is worth being exact about, because “verifiable” gets used for both.

What “signed” gets you

Signing is a good and necessary primitive. A signed record gives you two real guarantees:

Authenticity. The record was emitted by the holder of a particular key, which you can check against a published identity.
Integrity. The record has not been altered since it was signed. Chain the records and any later edit is detectable, not just the last one.

Both of those are shipped and checkable in Provetrail today, client-side, against a signed Merkle root. That is genuinely useful. It is also the floor, not the ceiling.

The gap is that a signature says nothing about the content’s truth. A wrapper that signs “I summarized the document” signs that string whether or not it summarized anything. The cryptography is sound; it is securing authorship of a claim, not the truth of it.

What Provetrail adds beyond signed

The reason to put a record under a governed runtime, rather than around it, is that the runtime can commit to facts the agent could not fabricate. Three of those go beyond a plain signature:

Governance. Every side-effecting action is admitted against a policy before it runs, and the admission decision is written into the record. Because the runtime that mediates the action is what writes the line, “no action ran without authorization” becomes a checkable property, not a promise.
Ground truth. A claimed success is bound to a committed check. A record that says “done” with nothing behind it is rejected, not trusted. The claim carries a hash of what was observed, so an authorized party can re-run the check without trusting the verifier.
Tamper-evident history. The events are chained and the root is signed, so a later rewrite of any earlier step breaks verification for the whole record.

These are the properties that separate “here is a log I signed” from “here is a record a runtime enforced.” They hold because the thing that wrote the record is the thing that refused the bad path. In the reference implementation, Flynn, the invariants are enforced at the point an action is dispatched, so emitting the proof is nearly free and the record cannot describe a path the runtime would not have allowed.

The ceiling, stated plainly

A Provetrail record proves that the record is intact, authentic, governed, and bound to evidence. It does not, on its own, prove two things:

That the emitting runtime was not itself modified. If someone tampers with the binary that produces and signs records, it can emit a record that is internally consistent and correctly signed but describes work that never happened the way it says. A signature over the output cannot catch a compromised producer of that output.
That nothing was omitted. A record proves that the events it contains happened as described. It does not by itself prove that no other events happened and were left out.

Closing those two gaps is a different class of problem than signing. It is the frontier we are building toward, openly:

A proven emitter. Binding the record to a measurement of the exact, reviewed build that produced it, so a verifier can confirm the record came from that build and not a modified one. This is the direction hardware-attestation approaches reach for; the goal is to get the guarantee without taxing every deployment with an enclave.
Omission-resistance. Structural commitments that make a dropped or withheld event detectable rather than invisible.

We are not claiming those today. When they ship, we will say so with the same specificity we use for everything else, and there will be a conformance vector you can run to check it.

Why we publish the ceiling

Two reasons. First, a buyer who cannot yet tell “signed” from “enforced” from “proven-emitter” will be sold the cheapest of the three as if it were the dearest, and the whole category gets less trustworthy as a result. Naming the ceiling is how you keep the words honest.

Second, the ceiling is exactly what a skeptic will quote. A record you can trust is one whose limits are written down next to its guarantees.

If you want the guarantees in mechanical detail, see how third-party verification works. For the definition and where this sits among neighbouring standards, see what is verifiable execution provenance.

Last updated: 11 July 2026.