Topic · DiggingBeagle record
Policy-attested execution
Architecture that moves authorization out of the LLM and cryptographically binds an approved intent/policy decision to exact execution bytes.
Definition & limits
An agent can propose a valid-looking transaction without having authority to execute it. Policy-attested execution addresses that gap by placing a deterministic verifier between an agent's proposal and an effectful tool or smart account. The verifier must approve the operation's exact semantics, not merely the model's description of what it intends to do. This distinction matters when low-trust text can change a recipient, amount, chain or tool argument after a model has generated an apparently acceptable plan.
What an authorization record must bind
The PACE architecture uses typed transaction intents, policy verification and signed Policy Decision Records. An account checks relevant signature, policy and replay conditions at execution. AIS, a related Authority-Inference Separation design, represents an action through a registered agent, accountable owner, permitted mandate, exact economic parameters, current policy state, approval, expiry and one-use nonce. These architectures are research demonstrations, not interchangeable product specifications.
The protected property is a correspondence: the bytes or canonical transaction semantics authorized by a verifier must match what the executor actually submits. A signed approval for one beneficiary cannot silently become permission to transfer to another. This still depends on correctly written policy, trustworthy signing keys and an uncompromised verifier. Binding a transaction faithfully to a bad mandate cannot make that mandate legitimate.
Results from different experiments
| Study and setup | Reported result | Interpretation |
|---|---|---|
| PACE deterministic benchmark | 0 unsafe executions in 2,800 trials | A benchmark result under the authors' logic and task fixtures, not audited production safety. |
| AIS August preprint, fixed scenarios | Unauthorized effects accepted: direct agent 36/36, prompt-only 20/36, independent verifier 0/36 | A control comparison using author-designed fixtures; not a live theft rate. |
| AIS replay and substitution fixtures | 4/4 replay attempts and 8/8 recipient or rail substitutions rejected; completion withheld for 4/4 delivery failures | Narrow tests of replay, byte-level binding and service-delivery gates. |
| AIS October model-in-the-loop report | 8/8 injected counterparty substitutions influenced proposed transactions; 0 unauthorized executions under AIS, but only 6/16 legitimate requests authorized | A limited safety result with an important legitimate-task completion limitation. |
The AIS fixed-fixture experiment comprised 48 scripted cases across four domains, whereas the October model tests assessed model-originated choices. The PACE benchmark, AIS fixtures and model trials have different methods and denominators. Their numbers are neither additive nor directly comparable efficacy rankings. See the canonical AIS study for evidence and limitations.
Why a settlement receipt is not enough
The AIS authors also examined 1,700 Base transaction rows related to public x402 facilitator addresses, of which 1,193 matched their candidate Base USDC authorization-call filter. Ledger fields may demonstrate that a transaction occurred, with certain accounts, amounts or nonces. They cannot, on their own, prove human consent, a valid policy mandate or off-chain service delivery. The Mastercard nine-payment pilot illustrates a distinct workflow with signed payment vouchers and later settlement, without publishing a comparable adversarial verifier test.
The reusable control principle is that the actor proposing an action must not be the only actor approving it, and the executor should be able to verify exactly what was approved. Deployment still requires independent policy ownership, revocation, key security and positive tests that legitimate transactions are not unnecessarily rejected.