Proof-Carrying Transactions An interface for the agentic internet

01

The shift

Picture an axis with intent at one end and execution at the other. Intent is what a person wants to happen. Execution is the specific action a machine carries out.

Until now, the meeting point between person and machine sat near the execution end. People traveled most of the distance. They learned command lines, forms, menus, and APIs, and did the translation from what they wanted into what the machine required.

An agent is software that chooses and executes actions on someone's behalf. Agents move the meeting point toward the intent end. The person states what they want, and the agent produces the execution.

02

The new gap

When your own hand or deterministic software acts out your intentions, you never worry about the gap between intent and conduct. This is because you are in charge of the entire operation and can see what is occurring. However, when probabilistic super intelligence acts on your behalf, there is now a gap between intent and conduct. You are technically still in charge of what is happening, and you will bear the consequences of the action, but you can no longer see how each step is carried out.

The internet's authorization primitives assume the old arrangement, that you are in charge and you can see. An API key or an OAuth token authorizes a class of actions for a period of time. That was safe when the credential holder was a person or fixed program logic. However, an agent searches the permitted class for the action that best serves its goal and then takes action.

This has created a new gap — a place where an agent can make a decision without you seeing what's happening. In order to fill it, authorization for agents has to be per action, and each action has to carry evidence.

We need to constantly bind execution to intent, for every action.

This is necessary because the possible failure points — the deviations — are no longer concentrated around “actors,” by which I mean humans or software that execute. Reputation, pre-deployment analysis, identity, and software audits are old technologies of producing trust by conquering each “actor.” With AI agents, the failure points are almost i.i.d. (independent and identically distributed); past good behavior doesn't prevent future rogueness. The new trust primitive must be bound to the granularity of each action.

We also need to evidence this binding in an instantly verifiable way, one that goes beyond observability. Agents act at such a granularity that agent logs in enterprise systems will expose IP and draw a perfect map of attack surfaces. Shipping that log out of the organization in order to prove compliance is a security risk. (I was told this by the former Head of Responsible AI at the DoD.) And, in practical terms, no human will actually read AI audit logs to catch rogue behavior. They are far too dense, numerous, and technical. At best, LLMs will be used to validate these logs.

So what we need are proofs. Proofs that accompany every action and show, in aggregate, that each action is bound to the original intent. And we need this when the intent is issued by one party, consumer or corporate, and the execution is carried out by agents and subagents in parallel, in environments the intent issuer doesn't have full control of or visibility into.

03

The proof-carrying transaction

A consequential action on the agentic internet has three parts: a mandate, a proposal, and a proof.

Mandate

Intent is informal and admits several readings. The mandate fixes one. A person can write it, or an agent can draft it. Either way, the principal reviews it with concrete examples of what it allows and what it refuses, and then signs. Before signing, the principal is bound to nothing. After signing, the agent is accountable for staying inside it.

Proposal

The proposal is the exact execution the agent wants to carry out: the payment, the trade, the message, the deletion.

Proof

The proof shows that the proposal satisfies the mandate. It is a zero-knowledge proof, a short cryptographic object that establishes one statement is true and reveals nothing else. The executor is the party that holds the authority to act. It checks the proof and executes in one step. A proposal without a valid proof is refused. A proposal outside the mandate goes back to the principal to decide.

Agency law, the body of law that governs a principal and someone who acts for them, has names for these moments.

Manifestation of authority

Signing the mandate.

Ratification

Approving an out-of-mandate action after the fact.

Trusted agent

Standing instructions given once, execution without further confirmation, and exceptions raised as they occur.

04

What the proof does

To make the mandate checkable, it is compiled into a policy: the mandate in a form a machine evaluates before each action. The policy is published as a verifying key, the public value that checks proofs against it. For each proposal, the agent generates a proof that the proposal satisfies the policy.

The proof binds to the exact bytes of the proposal, the policy version, the state the policy was evaluated against, and any signed external inputs the policy read. The executor runs a constant-time check. It never evaluates the policy or sees its inputs.

The proof is portable. An auditor, a counterparty, or a regulator can verify it later with the verifying key alone, so the proof doubles as the receipt. Because the proof is zero-knowledge, the mandate and the agent's private inputs stay private from the executor.

When both parties to a transaction are agents, each can attach a proof that its proposal is within its principal's mandate. Each can verify the other's before committing.

05

Where it applies

A transaction here means any action that changes state others rely on. Proof-carrying transactions belong at every boundary where such actions happen:

• Payments & banking
• Trading & treasury
• Contracts & signatures
• Publishing & messaging
• Data access & deletion
• Infrastructure changes
• Procurement

Reading and drafting need no proof.

06

What remains with the principal

The proof settles whether an execution matched the signed mandate. Two responsibilities stay with the principal.

1. Every path runs through the executor. Every path to the asset or capability has to pass through the executor. Otherwise the agent can act through a channel the mandate never sees.
2. The mandate is written over verifiable quantities. A term with several defensible meanings lets the agent choose the one that passes.

The mandate becomes the single object to audit.

07

Lineage

• 1997 · Necula

  Proof-carrying code. A program arrives with a proof of its own safety, checked by a small trusted verifier.

• 1999 · Appel & Felten

  Proof-carrying authentication. The same structure, applied to access control.

• Public blockchains

  Intent-centric protocols. A user signs a desired outcome, and third parties produce an execution that is checked against it.

• Agent payments

  Mandate-based payment protocols. Signed records of what a user approved.

• Now

  Proof-carrying transactions. An arbitrary compiled mandate, with a proof the executor checks without re-evaluating anything.

Each earlier approach fixes the constraint to a narrow form. A signed record shows what was approved. It does not show that a specific execution stayed inside it. Proof-carrying transactions take an arbitrary compiled mandate and attach a proof the executor checks without re-evaluating anything.

08

Starting point

A proxy between an agent and a bank account is the first instance. The owner signs a mandate once. The agent proposes each payment with a proof, and the proxy verifies it and executes through the bank's own API.

Replace the bank with a trading venue, a signing service, a publishing platform, or an internal system, and the same proxy becomes the general interface.