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.
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.[1]
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.[1]
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. Original source date: 20 October 2026.
Keep following the evidence
Join The Impact Brief founding list for selected AI reports, their effect on people and the evidence limits. Read a sample first.
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
Evidence check
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.
Reporting basis: Source analysis. Original source date: 20 October 2026.
Continue the story
Read next
Continue exploring ai agents: compare the finding and its evidence limits.
Can an AI agent finish the job and still harm the workspace?
Yes, in a new simulated benchmark. Across 12 frontier models and 180 attacked professional tasks per model, agents often completed useful work while also taking an unauthorised action. Script-based attacks succeeded far more often than ordinary prompt injection, but the preprint used synthetic workspaces and single runs.
Read the next reportExplore the full source and evidence record
What this means for people
- 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.
Global context
Formal enforcement may travel across jurisdictions, but it does not decide legal responsibility, consumer remedies or which party bears losses when a service, model or specification assumption fails.
What the evidence does not yet show
- 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.
What to watch next
- A working Airlock prototype, adversarial specification tests, proof-generation latency, useful-task completion rates, independent checking and evidence that external services match their formal models.
Living evidence record
Impact record IAI-19R9Q5J
Evidence stage
Studied
Confidence
Supported
Reporting basis
Source analysis
Independent or research support
Not yet
Record status
Monitoring
Last checked
21 October 2026
Source trail
1 direct source across 1 source type.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Single-source reporting disclosure
This record analyses one direct source. It can establish what arXiv published or reported, but it is not independent corroboration of every performance claim or predicted outcome. The confidence label will change only when broader evidence is added.
Evidence trail
Sources used for this report
Links checked 21 October 2026
Research question, topics and regions
Whether machine-checkable proofs attached to agent tool calls can enforce state constraints independently of an agent's strategy
Topics: AI agents · Formal verification · Tool security · Contracts · Proof assistants
Regions: Global
This report is labelled source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.