Agents that sign: securing autonomous on-chain execution

An agent that can sign turns everything it reads into a possible transaction. Trading bots, treasury automations and LLM-driven assistants share that property; LLM agents add a planner whose output can be steered by the data it consumes.

Assuming that the planner will at some point propose a harmful transaction, this analysis asks where the damage stops, using current Ethereum standards and a model agent. No product is evaluated.

The threat model

An agent that transacts has five parts: a model or planner; a tool layer of APIs, web pages and an RPC endpoint; a policy engine that approves or rejects actions; a signer; and the chain, where an account contract may enforce its own rules. Each hand-off is a trust boundary.

The weakest lies between the model and what it reads. OWASP distinguishes direct prompt injection from indirect injection through external content such as websites or files, and states that it is unclear whether fool-proof prevention exists. Research on a Web3 agent framework showed that instructions injected into prompts or stored history can trigger unauthorised transfers, and that prompt-injection defences gave limited protection once stored context was corrupted. Rule-based bots escape injection, not the other rows.

The model’s output is therefore untrusted input to the signer, and no system prompt changes that.

Where the controls sit

Controls can live in two places. A policy engine in the agent host, deterministic code kept apart from the model, can decode calldata, simulate and consult history. An account contract enforces only what it can check cheaply on-chain: targets, selectors, argument bounds, amounts and time. The difference is what survives a compromise. An attacker running code on the host simply asks the signer, and a key in a KMS or HSM, though it cannot be copied, signs what the host submits.

Maximum loss is therefore set by the on-chain rules and the account’s balance; the off-chain layer reduces how often a harmful but permitted transaction is sent.

Delegated authority models compared

Statuses are as listed on eips.ethereum.org on 31 October 2026; Draft standards may change.

ERC-4337 accounts validate each UserOperation in validateUserOp, which returns the signature result packed with a validUntil/validAfter range; the EntryPoint executes only after validation passes. ERC-7579 standardises modules such as validators (type 1) and optional hooks (type 4), whose preCheck and postCheck wrap every execution; a session key can be built as a validator for a second key plus a hook that keeps totals.

ERC-7715 defines wallet_requestExecutionPermissions; the wallet returns a context redeemed through an ERC-7710 delegation manager. It specifies the request “but not how the wallet enforces permissions”, so a grant is only as narrow as the wallet’s implementation. EIP-7702 sets an EOA’s code to 0xef0100 plus a delegate address through a type 0x04 transaction. The delegate “has unrestricted access to the account” and the original key keeps working, so a 7702 design is bounded only if that key stays out of the agent’s reach.

Scoping a session

A session permission is a set of predicates over each call. For the model payments agent defined in the next section:

ERC-4337 bundlers constrain the opcodes and storage that validation may use, so time bounds belong in validUntil and validAfter, and checks on shared state, such as a payee registry or running totals, usually sit in an execution hook. ERC-7579 warns that delegatecall execution needs care and that extra authorisation on configuration functions can be bypassed through calls from the account to itself, so sessions get single calls only and never target their own account.

The common error is to scope the target alone:

1// Simplified, illustrative. Not production code.2// Vulnerable: scopes the target, not the function, the arguments or the total.3function checkSessionCall(address target, uint256 value, bytes calldata data) external view {4    require(target == address(stablecoin), "target");5}

That permits approve(attacker, type(uint256).max), and the allowance survives the session that created it. A scoped check names the function and decodes its arguments:

1// Simplified, illustrative. Not production code.2// Execution hook for calls made with the agent's session key.3contract AgentSessionPolicy {4    address public immutable account;5    address public immutable guardian;6    IERC20 public immutable stablecoin;            // 6 decimals7    IPayeeRegistry public immutable payees;8 9    uint256 public constant PER_CALL_CAP = 5_000e6;10    uint256 public constant PER_DAY_CAP = 40_000e6;11    uint256 public constant PAYEE_DELAY = 24 hours;12    bool public paused;13 14    function checkSessionCall(address target, uint256 value, bytes calldata data) external {15        require(msg.sender == account, "only account");16        require(!paused, "paused");17        require(target == address(stablecoin) && value == 0, "target or value");18        require(data.length == 68 && bytes4(data[:4]) == IERC20.transfer.selector, "function");19        (address to, uint256 amount) = abi.decode(data[4:], (address, uint256));20        uint256 added = payees.addedAt(to);21        require(added != 0 && block.timestamp >= added + PAYEE_DELAY, "payee not yet payable");22        require(amount <= PER_CALL_CAP, "per-call cap");23        _recordSpend(amount, PER_DAY_CAP);   // reverts if the rolling 24 h total would exceed the cap24    }25 26    function pause() external {27        require(msg.sender == guardian, "only guardian");28        paused = true;29    }30}

Sizing spending limits

Consider a model agent that pays supplier invoices from a smart account with a float B of 200,000 units of a dollar stablecoin. Its assumed workload, over 22 business days a month:

• 20 ordinary days: 40 payments (30 of 400, 8 of 1,250, 2 of 5,000), 32,000 a day;
• 2 peak days: 100 payments (75 of 400, 20 of 1,250, 5 of 5,000), 80,000 a day;
• 1,000 payments worth 800,000 a month, spread evenly over a 10-hour day, so at most 10 an hour;
• detection-to-revoke time T: 1 hour when staffed, 12 hours overnight.

With the allowance unused, the worst-case loss before revocation is

L(T) = min(B, c × R × T, C × W(T))

where c is the per-call cap, R the hourly rate limit (with none, a transfer splits into as many calls as the chain includes, and the term drops), C the period cap, and W(T) the number of periods an interval T can touch: ⌈T / 24 h⌉ for a rolling window, one more for a fixed reset.

With 2,500 per call and 20 calls an hour, one hour allows 2,500 × 20 × 1 = 50,000; twelve hours allow 600,000, capped at the 200,000 float. The cap stops all 20 × 2 + 2 × 5 = 50 payments of 5,000, worth 250,000, or 31.25% of 800,000. A 40,000 period cap passes ordinary days and halts each peak day at 40,000: 2 × (80,000 − 40,000) = 80,000, or 10% of value, which with an even mix is half of each peak day’s 100 payments. A rolling window gives the same figures, because the window closing at the end of a peak day holds nothing from the day before; a fixed reset doubles the loss, because an attack that straddles it gets two allowances.

A per-call cap alone bounds nothing, and a rate limit makes it a bound that grows with detection time. A period cap bounds loss for a full period whatever the detection time, so it is the primary control: set it from the loss the operator can absorb, then check how often it interrupts peaks. A float near one peak day’s volume is a second, independent bound.

Validating before signing

The policy engine’s first rule is that the model never writes calldata:

1// Simplified, illustrative. Not production code.2// Vulnerable: whatever the model writes is what gets signed.3const sendTransaction = tool({4  input: { to: "address", data: "bytes", value: "uint256" },5  run: ({ to, data, value }) => wallet.sendTransaction({ to, data, value }),6})

1// Simplified, illustrative. Not production code.2// The model supplies a typed intent; the policy engine builds and checks the call.3type PaymentIntent = { invoiceId: string; payee: Address; amount: bigint }4 5export async function payInvoice(intent: PaymentIntent) {6  const prior = await ledger.get(intent.invoiceId)7  if (prior) return reconcile(prior)                  // resend the same signed op, or report its result8 9  const payee = await payees.lookup(intent.payee)     // exact 20-byte match10  if (!payee || now() - payee.addedAt < PAYEE_DELAY) throw new PolicyError("payee not yet payable")11  if (intent.amount > PER_CALL_CAP) throw new PolicyError("above per-call cap")12  if (spentLast24h() + intent.amount > PER_DAY_CAP) throw new PolicyError("above daily cap")13 14  const callData = encodeExecute(STABLECOIN, 0n, encodeTransfer(intent.payee, intent.amount))15  const effect = await simulate(ACCOUNT, callData, PINNED_BLOCK)16  if (!sameEffect(effect, [{ token: STABLECOIN, to: intent.payee, amount: intent.amount }]))17    throw new PolicyError("simulated effect differs from intent")18 19  // ERC-4337 nonce = 192-bit key || 64-bit sequence: one key per intent, sequence always 0.20  const nonce = (BigInt(keccak256(toBytes(intent.invoiceId))) >> 64n) << 64n21  const op = await signer.sign(buildUserOp({ callData, nonce }))22  await ledger.put(intent.invoiceId, { op, nonce })   // persist before sending23  return bundler.send(op)24}

• Decoded intent. Decode the final calldata independently and compare each field with the intent. Decode third-party calldata, such as a quoted route, against a known ABI; reject unknown selectors.
• Simulation. Simulate at a pinned block and compare asset changes with the intent. A simulation is only as honest as its node, as our RPC analysis explains.
• Allowlists. Compare full 20-byte addresses. An agent that copies payees from history can be fed a lookalike planted by a dust transfer; address analysis of first-time recipients is a useful second signal.
• Approvals. Approve exact amounts. Permit2 allowances carry a uint48 expiration after which transfers revert with AllowanceExpired; set it in minutes. Treat typed-data requests from tools as approvals, as in our analysis of approval phishing, and sign only allowlisted schemas.
• Chain ID and nonces. Take the chain ID from configuration, not the RPC endpoint. userOpHash binds an ERC-4337 operation to one chain and EntryPoint; EIP-7702 authorisations with chain_id 0 are valid on every chain, so an agent should never sign one. Owner-signed session grants need the bindings in signature replay across EVM chains.
• Ordering. Swaps need a minimum output from an independent price and a short deadline; MEV and protocol risk shows how slippage tolerance becomes extractable value.

Revocation and recovery

Pause independently of the module. ERC-7579 notes that a module can revert in onUninstall to block its own removal, and Safe’s documentation warns that modules “can execute arbitrary transactions”. A guardian pause checked on every session call, ideally in validation so that blocked operations pay no gas, stops the agent without the module’s cooperation.

Pending operations. An ERC-4337 operation is validated at inclusion, so once the pause lands, pending session operations fail; anything included first still executes, so the revocation needs fees that win. A hot key or remote signer cannot recall what it has signed: consume each outstanding nonce with a replacement.

Stuck, failed and retried transactions

Frameworks retry tool calls on timeouts, and models repeat them; without idempotency, each retry is a second payment.

EOA nonces are sequential, so one dropped transaction stalls every later nonce. A stuck transaction is replaced at the same nonce with higher fees, or cancelled with a zero-value transfer to self; until one is included either may execute, so outcomes are tracked by nonce, not hash. ERC-4337 bundlers accept a replacement with the same sender and nonce, a higher maxPriorityFeePerGas and an equally increased maxFeePerGas.

The ERC-4337 nonce, a 192-bit key and a 64-bit sequence in which a new key starts at 0, also gives on-chain idempotency. Derive the key from the intent ID and always use sequence 0, as the code above does, and two operations for one invoice share a nonce, so the EntryPoint accepts only one. That holds only if retries never fetch a fresh sequence with getNonce. Timed-out calls are reconciled, never rebuilt.

Review checklist

• Value-moving tools take typed intents, never raw calldata, targets or amounts.
• The host holds only a session key, in a KMS or HSM.
• The scope names target, selector and argument bounds, excludes the account, approve and delegatecall, and expires.
• The period cap and the float are sized to the loss from a full period without detection.
• New payees and targets wait longer than the detection-to-revoke time.
• Each operation is simulated at a pinned block and compared with its intent.
• Approvals are exact and expire; typed-data signing is limited to allowlisted schemas.
• Chain IDs come from configuration; no EIP-7702 authorisation uses chain ID 0.
• Each intent has a stable ID and a nonce fixed when it is first built.
• The pause works without the module; revocation and allowance clean-up are rehearsed.
• Monitoring alerts on first-time recipients, cap utilisation and reverted operations.

Most of these are off-chain code paths: penetration testing of the host, tools and signer complements a review of the account modules.

Conclusions

An agent that signs should be built on the assumption that its planner will one day propose the wrong transaction. Host-side checks decide how often that happens; on-chain rules and the float decide what it costs.

Of the models compared, smart-account session keys keep the agent’s limits on-chain under an owner that can be a multisig and can be replaced. EIP-7702 delegates can enforce similar rules but keep a root key that can never be rotated, and ERC-7715 leaves enforcement to the wallet. In every model, a period cap sized against detection time, idempotent intents and rehearsed revocation matter most.

Recommendations