For most production agent stacks today, the answer is no. An April 2026 preprint, arXiv:2607.05397, proposes Proof of Execution (PoE): a runtime mechanism that emits a checkable attestation for every action a governed agent takes, so an auditor can confirm the sanctioned tool call actually ran rather than a substituted or tampered one. The agent’s result is currently treated as proof it behaved; PoE makes that an assumption you can replay and test.
Why an Agent’s Output Is Not Evidence It Ran the Authorized Action
An agent that returns a successful result gives you no cryptographic assurance that it executed the specific, authorized tool call rather than a substituted or tampered one. Enterprise guidance, where it exists, stops short of demanding one. Microsoft’s Cloud Adoption Framework for AI agents emphasizes centralized governance, agent registries, and observability, but does not specify cryptographic attestation of tool execution. The gap is structural: traces and logs record what happened, but they do not prove, in a replayable and tamper-evident form, that the action matched the authorization that sanctioned it.
MandateProof names this the “accountability gap,” arguing that AI cannot hold authority or liability because nothing ties an autonomous action to a verifiable authorization. Whether or not you accept the legal framing, the technical complaint is precise. An observability system answers “what did the agent do?” An attestation system answers “can you prove the agent did the thing it was authorized to do, and only that?” Those are different questions, and most agent stacks answer only the first.
How Proof of Execution Works: The C-T-R Triple and Five Invariants
PoE formalizes runtime verification as a triple: a contract, an execution causal event stream, and a replay context, over which a validity predicate runs. Per the paper, the three components are the contract C, the sanctioned specification of what the agent may do; the Execution Causal Event Stream (abbreviated T or ECES), the ordered causal record of what actually happened; and the replay context R, everything an auditor needs to re-derive the execution independently.
On top of the triple, PoE defines five validator-checkable invariants that together form its validity predicate, each carrying a semantic guarantee: authorization (the action was permitted), path compliance (the execution stayed on a sanctioned path), null effect on deny (a denied action produced no side effects), history integrity (the causal stream was not tampered with), and replayability (a third party can re-derive the verdict). The first three concern what the agent was allowed to do and whether it stayed within bounds; the last two concern whether the record is trustworthy enough to check.
Of these, null effect on deny and history integrity do the heaviest lifting for trust. Null effect on deny is the guarantee that when an action is blocked, it actually leaves nothing behind: no partial write, no queued side effect. History integrity is the guarantee that the stream you replay has not been edited between execution and audit.
The structural backbone is the Prime Execution Model (PEM), which separates planning, enforcement, effect, and recordkeeping into distinct authority planes. An Execution Attestation Certificate is issued only when the validity predicate evaluates to one, that is, when PoE equals 1. The functional point of separating these planes is to keep the proof from collapsing into self-attestation: the component that records an execution is distinct from the component that produces its effects, so the recorder cannot silently rewrite history on the actor’s behalf.
What Does Runtime Attestation Cost? Roughly 2.7ms Minimal, 4.4% on Batches
According to the paper, the PoE prototype, written in TypeScript, adds approximately 2.7 milliseconds of overhead on minimal flows and about 4.4% on concurrent batch workloads, with a standard eight-event trace compressing to roughly 1.1KB. Read against the latency profile of a real agent tool call, which typically runs in the hundreds of milliseconds to seconds, the minimal-flow cost is noise. The 4.4% batch figure is the number that matters for throughput-bound pipelines running many tool calls in parallel, where overhead compounds. For an interactive single-user agent making a handful of calls per session, 2.7ms per call is unmeasurable. For a batch system dispatching thousands of tool calls concurrently, a 4.4% throughput tax is a real budget line that has to be justified against the audit benefit.
The 1.1KB compressed trace is the per-action storage cost of the auditability argument. At roughly one kilobyte per action, an agent emitting thousands of tool calls per hour produces megabytes, not gigabytes, of attestation data per day. That is cheap to store and, by design, cheap to replay. The economic question is not whether the receipts are affordable; it is whether your framework can produce them at all.
What Does PoE Demand of Agent Frameworks?
Producing a proof requires the framework to instrument and sign every tool invocation, which means frameworks that treat tool calls as opaque side effects cannot emit these attestations without an instrumentation rewrite. The consequence follows directly from the C-T-R design: because the proof is constructed from the execution causal event stream, the stream has to exist, and the framework has to surface it in a form an external validator can read.
Tool calling is already a first-class primitive in mainstream frameworks. LangChain’s tool-calling documentation, for example, treats tools as a defined interface the model can invoke. But exposing the call interface is not the same as producing a signed, replayable, causally ordered trace of what the call did. The sources surveyed show no evidence that LangChain or Microsoft has adopted PoE natively, and that absence is worth stating plainly rather than inferring adoption that has not been announced.
The practical upshot for a builder evaluating an agent framework today: ask whether tool invocations are exposed as signed, replayable events or merely recorded as logs. If the answer is the latter, supporting PoE is a rewrite, not a configuration change.
Per-Action Receipts vs. Post-Hoc Log Review
The compliance shift PoE drives is from reviewing logs after the fact to holding a per-action cryptographic receipt that can be replayed against the original contract. Post-hoc log review, the approach embedded in Microsoft’s governance guidance, tells you what was recorded. A PoE receipt tells you whether what was recorded is provably consistent with what was authorized. Those produce different audit outcomes: a clean log can coexist with an action that drifted from its authorization, because the log does not encode the binding between authorization and effect. Operationally, that turns an audit from a search problem into a verification problem: a reviewer re-runs the validity predicate against the receipt and gets a pass or fail, rather than reconstructing events from scattered logs.
The receipts are also the part that survives the specific threats PoE is designed against. According to the paper, PoE produces tamper-evident histories that withstand gateway-bypass and trace-mutation attacks, the two routes by which a faulty or hostile component might make an unauthorized action look authorized or erase the evidence of one. A receipt that survives trace mutation is what makes the “I can prove it” claim load-bearing rather than decorative.
This is where the cost moves. Compliance teams gain a replayable, per-action artifact. The framework layer pays for it in instrumentation and signing. The trade is attestation overhead against auditability, and it is not free on either side.
What Proof of Execution Does Not Do
PoE does not prevent a malicious action; it proves, after the fact, that an action occurred under or outside its authorization. The distinction matters and is easy to lose. A proof that the authorized action ran is not a proof that the authorization was correct, that the action was safe, or that its consequences were benign. PoE raises the floor on accountability; it does not raise the ceiling on judgment.
The paper is explicit about its non-goals. According to arXiv:2607.05397, PoE does not replace consensus, trusted execution environments (TEEs), or zero-knowledge VMs (zkVMs); it binds authorization, effect, history, and replay into a single runtime-checkable object for governed execution attestation. It is a complement to those mechanisms, not a substitute. If your threat model requires confidential computation, PoE does not provide it; if it requires distributed agreement, PoE does not provide that either. What it provides is a verifiable receipt that the thing you authorized is the thing that ran.
Who Is Building This? MandateProof and Framework-Native Governance
Among named implementations, MandateProof is the commercial one, marketing a cryptographic-attestation offering for autonomous AI actions under the banner of “Provable Accountability.” The vendor’s page sells enforceable, provable delegated authority and cryptographically verifiable evidence linking authority, action, and outcome, but it does not reference the preprint or the PoE terminology. The company’s product claims are, like any vendor page, self-sourced rather than independently verified.
On the framework-vendor side, the picture is thin. Microsoft’s governance guidance stays at the level of registries and observability, and LangChain offers tool calling and tracing rather than cryptographic attestation of execution. The sources surveyed contain no evidence of native PoE adoption in either. That is an absence worth tracking, not a verdict: a mechanism this cheap to run (2.7ms minimal, 4.4% batch, per the prototype) is a plausible framework feature, but plausibility is not adoption, and adoption is what would move PoE from preprint to default.
Frequently Asked Questions
Does Proof of Execution apply only to AI agents, or could it verify any automated action?
The paper frames PoE around governed AI agents, but the C-T-R triple is general: any execution with a contract, a causal event stream, and a replay context can produce a checkable receipt. The practical difference is that most non-agent systems already have audit trails and identities, whereas agents need this precisely because their actions are delegated and opaque.
How is PoE different from running the agent inside a trusted execution environment?
A TEE protects the confidentiality and integrity of computation while it runs, often hiding details from the host. PoE does not hide execution; it produces a public, replayable object that a third-party validator can check later without trusting the agent’s host. They solve different problems, and the paper explicitly positions PoE as complementary rather than a replacement.
What is the cheapest first step toward PoE for an existing framework?
Instrument the tool-call boundary first: emit a signed event for every invocation and capture the replay context the validator would need. That gives partial receipts before a full PEM rewrite, though it sacrifices the separation-of-authority guarantees that keep the recorder from sharing interests with the actor.
Can a valid PoE receipt still accompany a harmful action?
Yes. PoE=1 proves the authorized action ran, not that the authorization was wise or safe. If the contract permits a destructive operation, the receipt will attest to a perfectly executed destructive operation. The “null effect on deny” invariant also collapses if the enforcement plane itself is compromised.
When would the 4.4% batch overhead become a blocker?
In margin-thin or latency-sensitive batch pipelines, a 4.4% throughput tax can push operators toward sampled attestation rather than per-action receipts. The prototype figures are not a benchmark for every stack, and the validator infrastructure, storage, and key-management costs sit on top of the runtime overhead.
