Imagine asking an AI agent to move some of your digital money into a yield-bearing account. It plans the steps, checks what the transaction should do, and gets approval. But between that check and the moment the transaction runs, the instructions sent to the blockchain change. The check may have been sound; it simply checked a different trade.
That gap is the problem behind PACE, a system researchers designed to put a firm checkpoint between an AI agent’s plan and an irreversible financial action. Instead of trying to make the agent impossible to fool, PACE treats its proposals as untrusted—and asks whether a separate, rule-following system can make sure the approved action is the one that actually executes.
The risk is not just a confused model. An agent may read information from tools, such as token details or external feeds. Malicious text in that information can steer it toward an attacker’s transaction. In traditional software, a person might catch the mistake before clicking “confirm.” A blockchain transaction, once accepted, can settle before anyone has a chance to intervene.
PACE’s first move is to translate the agent’s proposal into a structured transaction intent: who is sending funds, where they are going, how much is involved, what function is being called, and what token approvals or slippage limits apply. That gives the safety system concrete fields to inspect instead of asking it to judge a vague natural-language request.
Next, a deterministic verifier compares those fields with rules set by the user. The rules can limit which addresses or tokens are allowed, cap spending, reject unlimited token approvals, set slippage limits, or require a recent simulation of the transaction. The verifier does not ask the AI whether its own plan is safe. It checks the proposal against the rules.
If the proposal passes, PACE creates a signed Policy Decision Record, or PDR. Think of it as a cryptographic receipt: it records the approved intent and policy, includes information from the simulation, and binds approval to the transaction’s exact execution data. A smart account checks that receipt again on the blockchain, including whether the transaction data matches, whether the approval is still valid, and whether its one-time number has already been used. If a check fails, the account rejects the transaction.
That last step tackles a subtle weakness in simulation. A preview can show what a proposed transaction is expected to do, but a preview alone does not prove that the same instructions will later be submitted. In one benchmark attack, the original transaction passed its checks, then its data was changed. A system that simulated the action but did not bind approval to the submitted data let the altered transaction through. PACE’s hash comparison caught the mismatch.
The researchers tested the approach in a purpose-built, in-memory finance simulator. Their 40 tasks covered benign actions and four kinds of attack, including prompt injection, unsafe contracts, financial exploits, and slippage attacks. They ran seven systems across 10 reproducible task variations, for 2,800 trials in total. In that benchmark, PACE had a 0.00 unsafe-execution rate and a 0.00 false-positive rate. The unguarded baseline had a 0.80 unsafe-execution rate.
Those numbers describe a designed test suite, not a universal safety guarantee. They do, however, help show why the components matter. The strongest comparison system also checked policies and simulations, but lacked PACE’s cryptographic binding between the simulated transaction and the data submitted for execution. It missed the transaction-mutation attack. PACE’s additional on-chain verification cost 29,826–31,822 gas per transaction in the researchers’ measurements.
The team also ran a separate evaluation using outputs from three language models, passed through the same verifier. Across 595 trials, PACE-guarded attacks had a 0.000 success rate in that test. But the guarded systems sometimes rejected benign tasks too: false-positive rates ranged from 5.0% to 12.8%. That matters because a safety system that blocks too much may be frustrating—or may encourage users to weaken its rules.
And the rules themselves are a central vulnerability. In an ablation test, using a deliberately permissive policy raised the unsafe-execution rate by 57.5 percentage points. In another test, PACE blocked eight out of eight attempts that violated the policy, but admitted eight out of eight harmful transactions that stayed within it. For example, a transaction can be damaging while remaining under a spending cap. PACE checks whether actions follow the declared rules; it does not decide whether those rules are wise or whether a sequence of individually permitted actions adds up to harm.
The system’s demonstration also has important boundaries: the main benchmark used an in-memory simulator, and the authors caution against extrapolating its results to adaptive attacks on live blockchains. A cryptographic receipt can help ensure that an AI’s checked action is the one it carries out. It cannot, on its own, guarantee that the action is economically safe—or that the policy is well designed. PACE’s new approach is to move one critical question out of the model’s hands: not “Can we trust the agent?” but “Can the system enforce exactly what it was allowed to do?”
