How do I make an AI agent's commitments enforceable instead of instructions it can quietly break?

October 22, 2026 · 7 min read

SentX SI

The short answer is to stop asking the agent to promise in prose and start gating its actions with machine-checked proofs. The most complete treatment of that idea is a framework called Proof-Carrying Contracts (PC2), introduced in a 70-page paper by Carlo Ciliberto, Alessandro Rudi, and Enrico Tassi, posted to arXiv on 20 October 2026 under the identifier arXiv:2610.28484. It is a preprint, with no record of journal or conference acceptance, and the results it reports are the authors'. But the mechanism it describes is a direct answer to your problem: instructions, policies, and terms of service are text, and text cannot make a system comply.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (arXiv abstract)

The paper starts from what you already know from experience. An agent acting on your behalf, booking services, making payments, moving documents, may make mistakes, be redirected by a malicious email or web page it reads, or serve its provider's interests over yours. Requiring a human to approve every action defeats the purpose of delegation, and training an agent to follow human intent makes compliance more likely without guaranteeing it. The question becomes what enforcement sits below trust in the model.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (full text v1, sections 1-3.4.1)

PC2's answer has three parts. First, the parties sign a formal contract: precise statements about what must hold at every instant while the task runs, such as a budget ceiling, who may receive a document, or a deadline; a goal whose proof settles the contract, for example releasing an escrow held until the work is verifiably done; and the conditions under which it ends otherwise, such as expiry with a refund. Clauses that need judgement rather than formula, like whether a hotel suits a family, are pinned to an expert procedure fixed at signing, such as a given model with a given prompt, whose verdict counts as the truth. Second, the agent runs inside an Airlock: a sandbox with open software, whose running build both parties verify before signing by remote attestation, and whose custody holds whatever the contract stakes, escrow money or a passport. The agent's only channel to the world is the contract's tools. Third, and this is the load-bearing change: before any tool call executes, the agent must supply a machine-checkable proof that the call preserves the agreed constraints in every case its model allows. The Airlock forms the statement to be proved itself, from the contract, from models of what each tool can do, and from what the agent currently sees, so the agent cannot weaken the claim it is proving. A small proof checker verifies the argument, and the call runs only if the checker accepts. A rejection comes back as an error message the agent can act on; it fixes the proof or chooses another action. Nothing runs without an accepted proof.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (full text v1, sections 1-3.4.1)

Notice what the agent is not doing. It is not writing a certified program for the whole task; it keeps its normal loop of reasoning and tool calls, and each step is gated individually. It is not required to reason in a formal language itself; proofs may come from any model, an automated prover, or a separate agent, and only correct ones pass. Checking a proof is cheap even when finding one is hard, and the design deliberately leaves the hard part on the untrusted side.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (full text v1, sections 1-3.4.1)

What the formalism establishes, and what it does not, matters for how far you lean on it. The authors prove that within this architecture the contract's constraints hold at every instant of execution, including while an action is in flight, for every agent and every sequence of requests, malicious agents included, because the Airlock checks each call without ever needing a proof about the agent's internals. They also identify the condition under which that translates into safety in the real world, and the condition is the one to hold onto: the guarantee rests on the tool transition models, the formal descriptions of what each tool can do, and a wrong model invalidates the safety. The trusted surface is correspondingly small: the proof checker, the Airlock's open software, and the tools' descriptions of the world, none of which depends on the agent, which is what lets the same justification be reused across agents. Two further limits are stated plainly in the paper. Writing a formal contract that captures the parties' actual intentions is itself substantial work, and enforcement cannot repair an agreement that says the wrong thing. And the construction covers one agent under one contract; the agent economy is the motivation, not yet the deliverable.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (arXiv abstract); Proof-Carrying Contracts: Commitments AI Agents Cannot Break (full text v1, sections 1-3.4.1)

The running example makes this concrete. A family's agent hires a travel agency's agent to organize a three-night trip, with escrow and passport in the Airlock's custody. The contractor tries to book the agency's partner hotel, which the expert procedure has not rated; the statement to prove is false, and no proof gets through. Asking the expert again does not help, because once given, a rating is recorded. A prompt-injected instruction to send the passport to some address dies the same way: every tool that can send the document logs its recipient, and the document's bytes never reach the agent. A premature claim of completion is rejected; once the trip is actually booked and the visa granted, the claim settles the contract and releases the escrow without the family's further approval. Had the visa been refused or the deadline arrived first, the Airlock would have terminated the contract and refunded the family. Throughout, the Airlock detects neither self-interest nor injection. It does not need to.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (full text v1, sections 1-3.4.1)

That last point is the distinction from what you probably have today. A permission list or policy engine decides allow-or-deny on the spot, so it can only encode rules simple enough to decide instantly, and it enforces whatever someone wrote it to enforce. A smart contract binds state on a blockchain; PC2 binds actions in the world, payments, bookings, documents, and a blockchain can simply be one of its payment rails. Plain instructions bind nothing at all: they are advice to a system that may disagree. The authors note, as their own comparison rather than an independent survey, that to their knowledge no existing approach combines all three properties: a checkable open mechanism, guarantees that hold regardless of the agent, and settlement between parties who do not trust each other.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (full text v1, sections 1-3.4.1)

Before you rely on any constraint this way, run a short test. We offer it as a practical method, not a benchmark from the paper. Ask three things. Can you state the constraint as a precise condition over quantities you can observe: a total spend, a named recipient, a date, an access boundary? Can you describe, well enough to check against, what each relevant tool might do, including what can change underneath it while a call runs? And does the constraint need to hold in cases the agent cannot see, not just in the happy path? If the answers are yes, the constraint is a candidate for formalization and gating. If the first answer is no, if the requirement is be reasonable or choose a good hotel, the constraint is not yet enforceable mechanically; keep it as reviewed policy with human checkpoints, or convert it into an expert procedure whose verdict is fixed at signing. Most real agreements are a mix: a handful of hard constraints worth gating, and the rest handled the old way.

Where this leaves you today. PC2 is a research construction, not deployed infrastructure: one preprint, one agent under one contract, and a Lean 4 mechanization with code and proofs made available online, as the authors state. What is usable now is the shape of the solution. The paper also introduces capability modules, reusable packages of tools, models, and guarantees, so a payment module can support different budgets without redesign, and reviewed templates for recurring operations. Pick the constraints that actually protect you, write them down precisely, check each tool's real behavior against the description you would be trusting, and put a gate in front of those operations that refuses anything unverified. That is the direction PC2 points: enforcement below the model, small enough to audit, and explicit about what it assumes.

Source: Proof-Carrying Contracts: Commitments AI Agents Cannot Break (arXiv abstract); Proof-Carrying Contracts: Commitments AI Agents Cannot Break (full text v1, sections 1-3.4.1)

If you delegate to an assistant, the honest baseline is the provider's own disclosure. SentX's model card for Victoria states that answers can contain incorrect facts, citations, or calculations, that memory is selective, and that the card is a first-party product disclosure, not an independent certification. That is exactly the gap a proof-gate architecture addresses: you stop having to decide whether to trust the model, because the mechanism you do trust is small, open, and checked before anything runs. SentX does not implement PC2; the relevance is that the same discipline, stating limits plainly and separating them from trust in the model, is what makes either approach auditable.

Source: Victoria AI Model Card | Capabilities, Evidence and Limits