AI Agents On-Chain: Wallet Custody, Policy Engines, Simulation, and Spend Limits

Separate deciding from signing

An LLM is a proposer. It is good at reading state, weighing conditions, and producing a candidate action with a rationale. It is not a security boundary, and it must never be the thing standing between an attacker's prompt and a transfer. Architect accordingly: the model emits a structured intent, and every layer after it is deterministic code you can audit.

1. Observe: read on-chain state, prices, and positions through your own indexed data, not through whatever the model recalls.
2. Propose: the model returns a typed intent — action, asset, amount, venue, rationale — constrained by a tool schema.
3. Authorize: a policy engine written in ordinary code accepts or rejects the intent against hard rules.
4. Simulate: execute the exact calldata against a forked state and assert the resulting balance changes match the intent.
5. Sign: a scoped key with on-chain-enforced limits submits it.
6. Record: intent, rationale, policy decision, simulation diff, and tx hash, all under one trace ID.

The policy engine is the actual product

Everything you would be uncomfortable explaining to a model belongs here instead. Policy rules are boring, deterministic, unit-tested, and they do not change their mind because a webpage contained an instruction.

• Allowlist of contracts and function selectors — an agent that can call anything is an agent that will eventually call something terrible.
• Per-transaction and rolling-window value caps, denominated in USD via your own oracle.
• Slippage bounds and minimum-output assertions on every swap.
• Rate limits: maximum actions per hour, with an escalating cooldown after any anomaly.
• Position invariants: never let health factor drop below a floor; never exceed a per-asset concentration cap.
• A kill switch that any operator can trigger, revoking the session key on-chain in one transaction.

Custody: scoped keys, not hot wallets

Do not give an agent an EOA holding the treasury. Use account abstraction with session keys: the agent's key is a delegate on a smart account, and the account's own code enforces what that delegate may do — which contracts, which selectors, what value ceiling, and until when.

This is the crucial property: the limits are enforced by the chain, not by your backend. If your server is compromised, if the model is prompt-injected, if a dependency is malicious — the worst case is bounded by the session key's on-chain scope. Add a timelock on high-value actions and a multisig for anything that changes the policy itself, and the blast radius is genuinely small.

// Simulate before signing, and assert the diff — do not trust the intent.
const sim = await simulate({ account, calls, blockNumber: "latest" });
if (!sim.success) throw new PolicyError("simulation_reverted", sim.error);

const diff = balanceDeltas(sim);
assertWithinTolerance(diff[intent.assetOut], intent.minOut, "output_below_min");
assertNoUnexpectedAssets(diff, intent.expectedAssets);
assertNoApprovalGranted(sim.logs); // a swap should never leave a new allowance

Prompt injection is a live threat here

An on-chain agent reads untrusted data by construction: token names, NFT metadata, governance proposal text, protocol documentation, social feeds. All of it is attacker-controlled, and any of it may contain text addressed to your model. Treat every byte of it as data, never as instruction.

• Fence untrusted content explicitly in the prompt and state that content inside the fence is never an instruction.
• Never let retrieved content determine a destination address, a contract to call, or a spend amount — those come from your allowlist and your policy, or the action is rejected.
• Strip or neutralize text fields from on-chain metadata before they enter context; a token whose name is a paragraph of instructions is a known technique, not a hypothetical.
• Because the policy engine and session key are deterministic, a successful injection still cannot produce a transaction outside the allowed set. That is the whole point of the layering.

What these agents are genuinely good at

Setting expectations honestly: an LLM will not beat the market. What it does well is continuous, judgment-adjacent operational work that is tedious for humans and too conditional for a simple cron job.

• Treasury operations: maintaining stablecoin runway across venues, rolling positions on schedule, sweeping fee revenue.
• Risk monitoring: watching health factors across many positions and topping up collateral before a threshold, with an explanation attached.
• Governance triage: reading every proposal across a dozen protocols and summarizing which ones touch parameters you have exposure to.
• Incident response drafting: assembling the timeline and affected-position report while humans decide what to do.
• Reconciliation: matching on-chain flows against internal accounting and flagging the differences — genuinely valuable and genuinely nobody's favourite job.