Why On-Chain Policy Enforcement Beats a Standing Allowance

Give an AI agent a private key and you've made a binary decision: it either has full signing authority over everything that key controls, or it has none. There's no middle setting. There's no "spend up to $100 a day on infrastructure" built into how a key works. That gap, between "no access" and "total access," is where almost every agent-handles-money horror story starts.

The oldest fix is the weakest one

The first tool most people reach for is the ERC-20 approve pattern: grant a contract or agent a standing allowance up to some amount, revocable by calling approve again with zero. It works, technically. It's also the mechanism behind a long history of approval-drain exploits, because the allowance sits there indefinitely, waiting for anything with access to the calling address to use it: the agent, a compromised dependency, a malicious upgrade to a contract the agent talks to.

A standing allowance answers "how much can this address ever spend," which is the wrong question for an autonomous agent. The right question is closer to: "for this specific action, right now, does it fall inside rules a human actually defined?"

Session keys narrow the blast radius, but not the underlying model

Account abstraction standards like ERC-4337 and ERC-7579 introduced session keys and policy modules: a scoped key that can only call specific functions, on specific contracts, sometimes with a value cap, often with an expiry. This is a real improvement: the agent no longer holds the master key to everything.

But the enforcement point matters more than people usually credit. In most account-abstraction implementations today, a policy violation is caught at validation time: a bundler simulates the operation, the policy check fails, and the operation is simply dropped before it ever reaches the chain. That's efficient, but it also means there's no on-chain artifact of the attempt at all. There's nothing you can point to afterward as evidence of what an agent tried and was stopped from doing.

Solana's spending-limit pattern shows the shape of a better answer

Solana multisig implementations have shipped on-chain spending-limit accounts publicly since late 2023: a program-owned account tracks a per-vault cap, a reset period, an allowlist of destinations and a running total, checked by the program at the moment funds actually move. That's a materially different design than an off-chain allowance: the check happens in the same place the money moves, not in a separate approval step that something else could bypass.

What that pattern still leaves open, and what we think is the more interesting engineering problem: what happens to the record of a rejected attempt. On most chains, if a transaction reverts or fails validation, any state changes (including a would-be record of "this was attempted and blocked") are rolled back along with everything else. You get an ephemeral log at best, not a durable, queryable, on-chain fact.

Three properties worth designing for, regardless of chain

• Check at the point money actually moves, not at a separate approval layer something else can route around.
• Make revocation instant and total — a human should be able to zero out an agent's authority in one action, without touching every downstream system that trusted it.
• Treat a blocked attempt as a fact worth keeping, not just an error to swallow. Knowing an agent tried to exceed its mandate and was stopped is often more valuable than knowing it succeeded within bounds.

That third property is the one most systems skip, and it's the one we think matters most as agents get more autonomy. A system that only tells you what happened, and never tells you what almost happened, is missing the exact signal you'd want the moment something starts probing at the edges of what it's allowed to do.

This piece describes general, publicly documented design patterns in the account-abstraction and multisig space. It intentionally does not describe the specific mechanism we've implemented, since related patent applications are in progress and have not yet been filed.