PACE: Policy-Attested Contract Execution Framework for LLM-Driven DeFi Agents (Defensive Research)

Technical Analysis

The paper addresses the underlying threat class where an LLM-based DeFi agent can be manipulated via prompt injection to plan or submit a transaction different from what a human or policy verifier approved, since no cryptographic binding exists between 'approved intent' and 'executed bytes' in typical agent-to-chain pipelines. PACE closes this gap with typed transaction intents, a deterministic policy verifier, signed Policy Decision Records (PDRs) binding intent+policy+simulation to exact execution bytes, replay/expiration protection, and on-chain enforcement via a Solidity smart account. The described attack surface it defends against is the planner/tool boundary between LLM output and blockchain execution, where an attacker (via prompt injection or compromised planning) could otherwise redirect funds, alter allowlisted contracts, or replay stale approvals. No exploit, malicious package, or active campaign is described; this is a proposed benchmark and defense evaluated against synthetic attack categories in a sandbox.

Detection Signatures

• N/A - no attack indicators; this is a defensive research artifact. If monitoring agent-driven DeFi pipelines, watch for: transaction bytes submitted on-chain diverging from the last human/policy-approved intent, missing or expired signed approval records, disabled or overly permissive policy/allowlist settings, and repeated replay of prior approved payloads.

Remediation Steps

1. 1

   Adopt intent-binding for agentic transaction execution

   For any LLM-driven DeFi or financial agent, require cryptographic binding between the approved decision (intent, policy, simulation) and the exact bytes submitted for execution, similar to PACE's Policy Decision Records.

2. 2

   Enforce deterministic policy verification pre-execution

   Insert a non-LLM, deterministic verifier/allowlist layer between agent planning output and on-chain submission to catch prompt-injection-induced plan deviations.

3. 3

   Add replay and expiration protections

   Ensure signed approvals cannot be reused or replayed for different or delayed transactions.

4. 4

   Track permissive policy configurations

   As the ablation shows, permissive policy settings and lack of touched-contract allowlists were the dominant sources of unsafe execution; audit and harden default policy configs before deployment.

5. 5

   Treat as research, not production-ready

   The authors explicitly frame results as logic-level safety in a benchmark, not deployment-ready security; any real integration requires independent security review and mainnet-fork testing before production use.