Could an AI agent prove each action keeps its contract before it acts?
A new formal framework puts a proof-checking 'Airlock' in front of every tool call. Its guarantees are mechanized in Lean 4, but practical proof search, specification quality and real-world deployment remain untested.
The short version
- What happened
- Proof-Carrying Contracts require an agent to supply a machine-checkable proof that each requested tool call preserves the agreed constraints under the stated model.
- Who it affects
- A reliable proof gate could give people stronger control over delegated payments, bookings or data access, but a badly specified contract could enforce the wrong outcome with mathematical precision.
- What remains unproven
- This is an unreviewed formal-methods preprint without a real-world agent deployment, measured proof-search cost, task-completion benchmark or evidence that non-experts can specify adequate contracts.
Keep in mind
This is an unreviewed formal-methods preprint without a real-world agent deployment, measured proof-search cost, task-completion benchmark or evidence that non-experts can specify adequate contracts.
Source analysis · 1 linked source. Primary analysed source date: 20 October 2026.
Read the full report · 3 min The evidence, methods, implications and limitations
The proof gate sits between the agent and every protected tool
The proposal, called Proof-Carrying Contracts or PC2, lets parties specify conditions that must remain true—such as a spending ceiling or access boundary. Before an agent's requested operation can run, it must supply a formal proof that the call preserves those conditions for every outcome allowed by the tool model. An execution layer called the Airlock checks the proof, runs only an accepted call and keeps protected state outside the agent's direct control.
The 70-page paper proves two properties under explicit assumptions: accepted operations preserve the contract, and a contract can settle when a stated goal is proved. The authors provide definitions and machine-checked proofs in Lean 4, plus worked payment-ledger and booking examples. The guarantee is therefore about a formal model and checker, not a claim that today's general-purpose agents can already use the system efficiently.[1]
A correct proof can still protect the wrong agreement
PC2 cannot rescue an incomplete specification. A travel contract might require both a flight and hotel yet fail to require matching dates or destinations. Every call could then be formally compliant while producing a useless trip. Safety also depends on complete mediation, faithful models of tool effects, protected credentials and services that behave as specified. Data sent to an outside inference provider remain visible to that provider unless the deployment adds separate confidentiality controls.
The authors say practical evaluation is still needed: whether people can express the intended task, whether proofs can be found and checked before calls expire, how often safe actions are rejected and whether useful work finishes at an acceptable cost. For security teams, this is a promising architecture to test—not a deployed guarantee. Adversarial trials, end-to-end prototypes and comparisons with policy engines would change the assessment.[1]
The distinction that matters
How a proof-gated tool call would work
The architecture moves enforcement from a request's wording to a checked condition on the requested operation.
Contract
Define protected state and goals
Creates the condition each call must preserve
Agent
Requests a tool call with a proof
Keeps freedom over strategy
Airlock
Checks proof before execution
Runs the call or rejects it