Proof-Carrying Agent Actions (PCAA)

Updated 6 July 2026

Proof-Carrying Agent Actions (PCAA) is a mechanism that attaches machine-verifiable certificates to agent actions, ensuring each execution meets formal policy, safety, or correctness conditions.
It leverages diverse formal methods—from cryptographic proofs and SMT-checks to theorem-prover artifacts—to separate action proposal from execution authorization.
PCAA enables robust pre-execution verification across heterogeneous systems, delivering empirical guarantees via metrics like proof size, verification latency, and compliance accuracy.

Proof-Carrying Agent Actions (PCAA) denotes a class of mechanisms in which an agent-generated action, trace, or execution request is accompanied by a machine-checkable certificate witnessing that the proposed behavior satisfies a formal policy, safety condition, correctness obligation, or governance rule. Across recent work, the certificate may take the form of a succinct cryptographic proof, an SMT-checkable satisfiability witness, a deterministic verifier-checked structured artifact, a theorem-prover object, or a portable runtime-governance bundle. The common operational principle is that execution or admission is conditioned on successful checking of the certificate rather than on trust in the agent, re-execution of its internal computation, or post-hoc auditing alone (Gabbay, 22 Jun 2026, Yanglet et al., 23 May 2026, Wang, 2 Jun 2026).

1. Conceptual scope and antecedents

PCAA inherits part of its intellectual structure from proof-carrying code and from proof-oriented planning formalisms. In "Proof-Carrying Plans: a Resource Logic for AI Planning" (Hill et al., 2020), the core judgement is a plan-specification sequent

$\Gamma \vdash \{P\}\{Q\}\mid f,$

which states that, in planning context $\Gamma$ , a plan $f$ transforms any $P$ -world into a $Q$ -world. The same exposition describes how each primitive action can be packaged with a small proof object, yielding a proof-carrying action discipline whose full plans are obtained by composition.

Recent agentic formulations shift the focus from binaries or plans to runtime proposals. "No Certificate, No Execution" (Yanglet et al., 23 May 2026) formalizes trustworthy agency through a Proposal–Certification–Execution architecture in which a probabilistic generator $M_G$ proposes a trace, a Permissibility Machine $M_\Pi$ certifies or rejects it under a policy system $\Pi$ , and execution is restricted to the certified subset. A central premise is that generation is not permission: a trace may be computable yet impermissible, and individually permissible actions may compose into an impermissible trace.

The cryptographic formulation in "Cryptographic certificates of validity for trustworthy AI" (Gabbay, 22 Jun 2026) places PCAA between formal verification of source code and cryptographic authentication. Rather than requiring source inspection or re-execution, an action can carry an independently checkable proof that it satisfies an agreed formal policy. That paper explicitly relates the proposal to proof-carrying code, zkVMs, formal methods, and agent governance, and presents PCAA as a modular assurance mechanism rather than a replacement for those paradigms.

A further generalization appears in the runtime-governance literature, where the unit of certification is not only a logical condition on an action but a portable governance object that can survive runtime heterogeneity. "Proof-Carrying Agent Actions: Model-Agnostic Runtime Governance for Heterogeneous Agent Systems" (Wang, 2 Jun 2026) treats PCAA as a runtime-neutral certificate path that remains stable even when the same risky act is represented as a shell command, a tool invocation, a hosted-session transition, or an API request.

2. Formal models and semantics

One formalization treats PCAA as predicate certification over public and private variables. In the cryptographic account, $S$ is the environment state, $A$ the proposed action, $\Gamma$ 0 a tuple encoding public fields of $\Gamma$ 1 and $\Gamma$ 2, and $\Gamma$ 3 a private witness encoding internal agent state or trace. A correctness or policy condition is a closed formula

$\Gamma$ 4

in a suitable first-order logic, and the certification problem is reduced to checking whether there exists $\Gamma$ 5 such that the compiled constraint system $\Gamma$ 6 holds (Gabbay, 22 Jun 2026).

A second formalization uses transition systems and verification conditions. In the executable Proof-Constrained Action framework, the agent environment is modeled as

$\Gamma$ 7

where $\Gamma$ 8 is the verification state space, $\Gamma$ 9 the finite action space, $f$ 0 the deterministic transition function, $f$ 1 the initial state, and $f$ 2 a conjunction of immutable safety axioms. Each action $f$ 3 carries a proof obligation $f$ 4, and execution depends on the satisfiability of

$f$ 5

If $f$ 6, the action is blocked; otherwise the SMT engine returns a model witness and the action is allowed. The paper states an informal soundness theorem: under Structured Intent Fidelity and Immutable Axioms, every state reachable by repeatedly executing only SAT-approved actions satisfies $f$ 7 (Wu et al., 28 May 2026).

A third formalization elevates the object of certification from single actions to execution traces. In the PCE model, a policy system $f$ 8 induces a semantic permissible trace language $f$ 9, a generative machine $P$ 0 proposes traces in $P$ 1, and a Permissibility Machine $P$ 2 returns either a certificate $P$ 3, a rejection $P$ 4, or an escalation request. The executable language is

$P$ 5

Under Axiom 2 (sound certification) and Axiom 3 (execution allowed only on certified traces), Theorem 2.1 yields

$P$ 6

which is the formal version of the slogan “no certificate, no execution” (Yanglet et al., 23 May 2026).

A fourth formalization targets skill containment rather than action permissibility alone. In "Methods for Formal Verification of Agent Skills" (Metere, 9 May 2026), joint LLM-plus-script execution is modeled as configurations

$P$ 7

with nondeterministic LLM-side transitions and deterministic script-side transitions. If $P$ 8 is the declared capability set and $P$ 9 projects a trace onto invoked capabilities, the target safety property is

$Q$ 0

This formulation reframes PCAA as a capability-containment proof over sessions rather than as a per-step policy check alone.

3. Proof objects and checking mechanisms

The literature uses several distinct certificate types. The cryptographic variant compiles logic into algebraic constraints; the solver-based variant treats satisfiability itself as the authorization witness; recommender and governance systems use structured certificates validated by deterministic code; and theorem-prover variants rely on kernel-checked proof artifacts. These designs differ in proof language, trust base, and execution overhead, but all separate proposal from authorization.

Formulation	Certificate object	Checker
Cryptographic PCAA	Proof $Q$ 1 that $Q$ 2	SNARK/STARK verifier
ePCA	SAT model witness or UNSAT core for $Q$ 3	Z3-based SMT check
PCN-Rec	JSON certificate $Q$ 4 for slate claims	Deterministic verifier $Q$ 5
Hoare/PCP	Agda or Lean action/trajectory certificate	Kernel or proof checker
ACP	Signed proof object $Q$ 6	`verifyAction(a,\Pi)`

In the cryptographic line, the central transformation is an arithmetization of the logical predicate. The paper translates $Q$ 7 to a nonnegative polynomial $Q$ 8 such that

$Q$ 9

Atomic equalities $M_G$ 0 become $M_G$ 1, conjunctions become sums of nonnegatives, disjunctions become products, and quantified formulas use a top-level range-check construction. The resulting vector of constraints

$M_G$ 2

is then handled by a succinct proof system through algorithms

$M_G$ 3

The same exposition allows optional zero-knowledge by randomizing the witness while preserving satisfiability of the constraints (Gabbay, 22 Jun 2026).

In ePCA, the proof-generation and checking loop is solver-native rather than cryptographic. The runtime pipeline parses a typed action payload, synthesizes $M_G$ 4 by schema-based translation, assembles $M_G$ 5, and calls SMT_Check(VC). A SAT result returns (authorized = true, witness = model); an UNSAT result returns (authorized = false, proof_of_deadlock = UNSAT_core). The translation step is specified as pure syntax plus dictionary lookup with $M_G$ 6 time, while the SMT engine is DPLL(T)-based and instantiated with Z3 (Wu et al., 28 May 2026).

PCN-Rec instantiates PCAA in governance-constrained recommendation. A mediator LLM proposes a slate $M_G$ 7 and a JSON certificate $M_G$ 8 claiming head/tail exposure and diversity metrics; a deterministic verifier then parses the schema, checks that c.slate matches $M_G$ 9, recomputes the metrics from item metadata, and accepts only if all constraints pass. If verification fails and some compliant slate exists in the candidate window, a deterministic constrained-greedy repair constructs $M_\Pi$ 0, emits $M_\Pi$ 1, and re-runs verification. The result is an auditable propose/verify/repair trace rather than an unverifiable one-shot output (Dixit et al., 14 Jan 2026).

The theorem-prover line uses proof objects whose validity reduces to type checking. The Lean 4 trust-boundary architecture introduces an ActionCertificate containing an action, arguments, pre-state, post-state, precondition, postcondition, and proofs that the precondition holds, the deterministic execution relation holds, and the postcondition holds. A TrajectoryCertificate is a list of such steps together with a chain-consistency proof. Verification consists of kernel type checking plus an axiom audit against the trusted set $M_\Pi$ 2 (Koomullil, 13 May 2026). The earlier Agda-based planning work packages primitive actions as proof-carrying objects whose runtime safety follows from the general PCP soundness theorem (Hill et al., 2020).

4. Architectural patterns and representative systems

The cryptographic PCAA workflow is explicitly staged. A policy author writes $M_\Pi$ 3 and records a compiler version hash; Compiler(φ) produces $M_\Pi$ 4; Setup(1^\lambda,R_\phi) produces proving parameters and a verifying key; the agent serializes public input $M_\Pi$ 5 from state and action, chooses private witness $M_\Pi$ 6, computes $M_\Pi$ 7, and emits $M_\Pi$ 8; the verifier retrieves the verifying key for the policy and accepts the action iff Verify(vk,x,π)=1. This architecture makes policy identity, compilation, proving, and verification first-class runtime artifacts (Gabbay, 22 Jun 2026).

The Proposal–Certification–Execution architecture separates generation, certification, and realization. A pre-execution trace

$M_\Pi$ 9

may include actions, tool or API calls, retrieval records, credential or approval tokens, replayable computation steps, and declared execution conditions. The certifier may consult proof memory

$\Pi$ 0

to handle history-dependent obligations such as cumulative budgets, source lineage, or exposure limits, and it may replace ordinary certificates with zero-knowledge certificates when the trace itself contains sensitive data (Yanglet et al., 23 May 2026).

The ePCA system is organized around a neural-symbolic isolation architecture. Its data flow is: semantic stripping, where the LLM may emit only a tightly typed JSON payload; parsing inside the trusted computing base; translation into a first-order formula; SMT decision on $\Pi$ 1; and return of a binary authorize/reject decision, plus an UNSAT-core witness on rejection. The design claim is that the LLM has zero read/write access to the SMT engine or the axioms, which is intended to prevent hidden side effects from being smuggled through natural-language channels (Wu et al., 28 May 2026).

The runtime-neutral governance formulation makes the certificate itself the stable object across heterogeneous runtimes. For each raw action $\Pi$ 2, the certificate is

$\Pi$ 3

where $\Pi$ 4 is the portable action envelope, $\Pi$ 5 runtime-stage receipts, $\Pi$ 6 human approval receipts and accountability facts, $\Pi$ 7 the replay-ready proof bundle, and $\Pi$ 8 the integrity projection lane. Governance is organized into five checkpoints: pre-action admissibility, action open, assumption capture, approval, and outcome closure. The model extends the certificate with externality-aware boundary facts

$\Pi$ 9

and with explicit enforceability classes

$S$ 0

so that approval semantics are recorded rather than collapsed into a single reviewed/unreviewed bit (Wang, 2 Jun 2026).

Institutional governance systems implement a more cryptographically explicit admission check. ACP v1.13 defines a proof object

$S$ 1

and a decision procedure verifyAction: A × Π → {accept, escalate, reject}. Admission depends on signature verification, capability inclusion, delegation-chain validity, transitive revocation, and deterministic risk evaluation. Every decision is recorded in an append-only audit ledger as a signed, hash-chained event, and cross-institutional verifiability is obtained through public institutional keys and Mutual Recognition Agreements (Fernandez, 19 Mar 2026).

5. Guarantees, empirical studies, and application settings

The strongest guarantees in the literature are conditional. In the cryptographic formulation, the proof system is parameterized by a security parameter $S$ 2 with required soundness error $S$ 3. The paper gives asymptotic costs for setup, proving, and verification, and reports practical figures of prover time $S$ 4 field operations for an $S$ 5-gate circuit, “in practice seconds for $S$ 6,” proof size “ $S$ 7– $S$ 8 B for SNARK” and “ $S$ 9 kB for STARK,” and verification time “ $A$ 0– $A$ 1 ms (SNARK)” or “ $A$ 2 tens of ms (STARK)” (Gabbay, 22 Jun 2026).

In ePCA, the security theorem is stated under two explicit assumptions: Structured Intent Fidelity and Immutable Axioms. Under those assumptions, the paper claims a “zero-attack success rate” and “zero false positives.” Its empirical evaluation uses a two-dimensional dynamic adversarial benchmark with Scenario A: Multi-Step Financial Transfer and Scenario B: 12-round Cross-Domain Data Exfiltration Sandbox. For Scenario A, the reported ePCA accuracy is $A$ 3 across GPT-5.2, GPT-5.4, Qwen3-max, Gemini-3-flash, and Kimi-k2.5, while average SMT check time is “ $A$ 4 ms (P99 $A$ 5 ms)” versus “ $A$ 6 s per decision” for an LLM-as-Judge baseline (Wu et al., 28 May 2026).

Recommendation under governance constraints provides a deterministic, non-cryptographic PCAA case study. PCN-Rec separates negotiation from enforcement by combining a candidate generator, a User Advocate, a Policy Agent, a mediator LLM, a deterministic verifier, and a deterministic repair stage. On MovieLens-100K with governance constraints, the reported result is a “98.55% pass rate on feasible users ( $A$ 7)” versus a one-shot single-LLM baseline without verification or repair, with “only a $A$ 8 absolute drop in NDCG@10 ( $A$ 9 vs. $\Gamma$ 00); differences are statistically significant ( $\Gamma$ 01)” (Dixit et al., 14 Jan 2026).

The runtime-neutral governance work evaluates portability rather than theorem-level logical soundness. Its protected benchmark expands “from 24 executable seeds to 96 traces across four runtime families.” The reported ablation table gives, for Full PCAA, Exact Accuracy $\Gamma$ 02, Review Rate $\Gamma$ 03, Manifest Stability $\Gamma$ 04, and Proof Closure $\Gamma$ 05; removing externality context lowers Exact Accuracy to $\Gamma$ 06, removing enforceability handling changes Review Rate to $\Gamma$ 07, and removing the integrity lane drives Manifest Stability to $\Gamma$ 08 and Proof Closure to $\Gamma$ 09 (Wang, 2 Jun 2026).

Application settings are correspondingly broad. The literature explicitly discusses financial-transfer control, travel or budget policy enforcement, robotic safety constraints, data-exfiltration prevention, governance-constrained recommendation, filesystem sandboxing, B2B institutional admission control, and programmable lakehouse repair workflows (Wu et al., 28 May 2026, Dixit et al., 14 Jan 2026, Fernandez, 19 Mar 2026). A related lakehouse proof-of-concept argues that untrusted AI agents can repair production data pipelines safely by coupling branch-based execution with correctness checks inspired by proof-carrying code (Tagliabue et al., 10 Oct 2025).

6. Assumptions, limitations, and open questions

A recurring misconception is that visibility into model reasoning is equivalent to runtime assurance. The trace-certification literature states the opposite directly: monitorability is not certifiability, and reasoning is only one component of a broader execution trace that may also include evidence, credentials, approvals, replayable computations, and execution conditions (Yanglet et al., 23 May 2026).

The main technical fragility is specification. In the cryptographic formulation, policy correctness requires that $\Gamma$ 10 faithfully encode legal, ethical, safety, or functional requirements; compiler trust requires that the translation $\Gamma$ 11 be formally verified or extensively tested; and policy versioning requires management of $\Gamma$ 12 triples across updates and revocations. The same work explicitly notes trust in the proof-system setup for SNARKs and the correctness of the compiler as central assumptions (Gabbay, 22 Jun 2026).

The solver-based line makes the semantic-translation problem even more explicit. The ePCA paper identifies semantic translation as the “Achilles’ heel,” emphasizes that the framework relies on a finite, strongly typed action space and manually authored axioms, and notes that the chosen logic fragment is decidable rather than arbitrary higher-order logic. It further warns that schema-smuggling attacks may evade syntactic parsing or grammar enforcement in open-ended domains, while reintroducing neural components at the translation boundary risks restoring probabilistic vulnerabilities (Wu et al., 28 May 2026).

Runtime-governance formulations introduce a different class of limitation: not all runtimes expose enforcement hooks deep enough for true pre-execution gating. The heterogeneous-runtime paper states that some systems cannot enforce pre-execution control, that the public benchmark is disclosure-bounded, that stronger cryptographic proof lanes such as zero-knowledge receipts or blockchain settlement remain future work, that there is no formal proof of end-to-end tamper resistance under adaptive adversaries yet, and that automated policy synthesis, conformal risk control, multi-tenant workflows, and federated governance remain open (Wang, 2 Jun 2026).

Skill-containment approaches narrow one gap while leaving a residual. The three-layer capability-containment framework proves composition of abstract interpretation, refinement types, and SMT-bounded model checking “modulo a single residual,” namely the LLM’s freedom to refuse to act; the paper states that the runtime biconditional catches that residual at session boundary (Metere, 9 May 2026). This suggests that PCAA can make unauthorized action execution mechanically difficult or impossible within the modeled interface, but cannot by itself solve every alignment or intent-formation problem outside that interface.

Across the literature, the forward path is consistent: strengthen policy languages, formally verify compilers and re-checkers, integrate proof systems and runtime control planes, benchmark common policies, manage policy identifiers and keys, support batching and selective zero-knowledge disclosure, and subject the entire stack to cross-disciplinary audit (Gabbay, 22 Jun 2026). In that sense, PCAA is best understood not as a single algorithm but as an emerging design pattern for trustworthy agency: action is separated from permission, and permission is grounded in certificates that can be checked independently of the agent that produced them.