An agent can write a convincing explanation for almost any action after the fact. The harder control is to stop the action before it runs unless the agent can supply evidence in a form that a separate machine can check. Proof-Carrying Agent Actions, or PCAA, treats that evidence as a licence attached to the exact tool call.[1]
The proposal borrows the logic of proof-carrying code. A planner may suggest an action, but a planner-independent checker decides whether the action certificate satisfies the obligations defined by an authoritative tool contract. The executor runs only after the certificate passes.[1]
A payment example makes the gate visible
What happens before an irreversible tool call
| Stage | Question | System component |
|---|---|---|
| Contract | What conditions must be true before this tool may run? | The trusted tool contract defines obligations and marks the action reversible or irreversibleSource 1 |
| Binding | Which exact command is being authorised? | A canonical SHA-256 commitment binds the certificate to the invocation and argumentsSource 1 |
| Support | What kind of evidence satisfies each obligation? | The certificate carries typed support such as proof, belief, hypothesis, contingency, conflict or no-progressSource 1 |
| Decision | May execution proceed? | A separate checker re-derives the context and validates the inference rulesSource 1 |
Suppose an agent wants to transfer £50,000. The tool contract might require proof that the recipient is approved, the amount is within authority and a second signatory has confirmed the transaction. A natural-language plan saying “this appears urgent” cannot substitute for those obligations. Because the transfer is irreversible, the PCAA design requires Proof for every declared licensing condition.[1]
The certificate is tied to the exact invocation. Changing the recipient, amount or risk flag after approval changes the commitment and causes the check to fail. That prevents a valid certificate for one action from being replayed as authority for a different action.[1]
The support types express uncertainty instead of flattening it
Six support types in the proposal
| Measure | Value | Context |
|---|---|---|
| Proof | Highest support | Required for every obligation on irreversible actionsSource 1 |
| Belief | Supported but not proved | May be suitable only where the contract permits uncertaintySource 1 |
| Hypothesis | A claim awaiting confirmation | Cannot license a proof-required obligationSource 1 |
| Contingency | An action conditioned on another event | Makes the dependency explicitSource 1 |
| Conflict | Evidence points in incompatible directions | Signals that execution should not silently proceedSource 1 |
| No-progress | The planner cannot satisfy the obligation | Creates an auditable stop rather than an improvised bypassSource 1 |
The reported test is small but exact
The checker accepted two valid certificates and rejected all 15 unsafe certificates in the study’s semantic battery. Four additional structural cases tested argument substitution, omitted preconditions and downgraded risk flags. Across those 17 semantic examples, 88.2% were designed to be unsafe; the result shows correct behaviour on that battery, not a real-world failure rate.[1]
For a three-obligation payment certificate, construction, checking, serialization and buffered local persistence took 53.7 microseconds at the median and 65.7 microseconds at the 95th percentile. That suggests the certificate gate need not be the slow part of many tool workflows, although network calls and external systems were not the benchmark’s focus.[1]
The guarantee stops at the contract boundary
PCAA can prove that an action followed the stated contract. It cannot prove that the contract captures every real-world hazard, that an external database is truthful or that a supposedly reversible action is actually reversible. A badly specified tool contract can be followed perfectly and still produce a bad outcome.[1]
The strongest contribution is therefore not a claim that formal certificates solve agent safety. It is the creation of a replayable decision artefact: an auditor can see the obligations, evidence type, exact invocation and checker result rather than reconstructing intent from a chat transcript after the action has happened.[1]
Sources & further reading
- Proof carrying agent actions enable verifiable licensing of language model tool use Scientific Reports · 13 Oct 2026 · Accessed 16 Oct 2026