AI Agent Wallets: Combining ERC-4337 with Autonomous Execution
--
Building AI agents in DeFi, such as those monitoring positions, rebalancing allocations, harvesting yield, and reacting to market conditions, is becoming standard practice. Getting the strategy logic right takes work, but that is rarely the hardest part.
The hard part is execution.
Every time an agent needs to do something meaningful on-chain, it typically hits a wall of human intervention. Approve this. Sign that. Confirm the transfer. In practice, the “autonomous” agent remains autonomous only until the moment it needs to move money, which is the exact moment autonomy actually matters.
This is the execution bottleneck that ERC-4337 solves better than any traditional EOA-based workflow.
The Real Problem with EOAs
A private key is a terrible permission model for a machine.
Humans sign with judgment. They hesitate, notice context, and can refuse a bad request. An AI agent has none of that. It will sign whatever its logic tells it to sign, and if an upstream prompt, tool, or dependency manipulates that logic, the key does not care. It just authorizes the action.
The usual workarounds fall short:
- Hardware wallets? Still require a human in the loop
- Multisigs? Too slow for a system that needs to react in near real-time
- Approval-gated transactions? At that point, the “agent” is just a very expensive UI
None of those solve the actual issue: a machine needs scoped, revocable, time-bound authority over funds. Not full control. Not zero control. Something in between.
That is not what a private key provides. A smart account can.
ERC-4337, in Plain English
Account abstraction has been discussed for years, but ERC-4337 is the version that made it real without requiring protocol changes.
The mental model is simple:
- Instead of an EOA directly sending transactions, the agent submits a UserOperation
- Bundlers collect those operations and simulate them before including them on-chain
- An EntryPoint contract routes the operation to the smart account
- The smart account decides whether the operation is valid
- A Paymaster can sponsor gas, so the account does not need to hold ETH just to execute
This changes the permission model completely. The authorization logic moves from “who owns this private key?” to “what does this smart account allow?”
This isn’t experimental anymore. Over 100 million UserOperations were executed in 2024.
That distinction matters immensely for agents. If the wallet is a contract, the contract can enforce policy. It can dictate that a signer is only valid for 12 hours, that a key may only call one specific function, or that an agent may only interact with one approved destination.
That is what machine-safe financial agency looks like.
The Architectural Shift to Smart Accounts
Transitioning an agent from an EOA to a smart account unlocks three major architectural improvements.
The first improvement is session keys.
Instead of exposing a master key to the execution environment, short-lived session keys can be generated with tightly scoped permissions. The smart account only accepts operations signed by that session key if they satisfy the encoded policy.
For a production DeFi agent, a robust policy looks like this:
- Valid for 12 hours
- Limited to a single router
- Restricted to one exact function selector
- Capped at 500 USDC per operation
If the key expires, the session ends. If the agent tries to do anything outside the policy, the smart account rejects it at the contract level. That is the difference between “automated” and “dangerous.”
The second improvement is on-chain spending limits.
A backend rule is just a reminder. A contract rule is a boundary. The agent cannot route around it, forget it, or silently ignore it.
The third improvement is gas abstraction.
Paymasters make the operational story much cleaner. Agents can pay for gas in the asset they actually use (like USDC), instead of requiring constant ETH top-ups just to function. That removes a surprisingly annoying layer of infrastructure maintenance.
Where Early Implementations Go Wrong
Wiring this up is rarely smooth. There are a few common pitfalls that catch teams off guard.
Validation is not a free-for-all
During validateUserOp, an account cannot rely on arbitrary external reads the way normal application code can. That restriction exists for a reason: bundlers have to simulate operations safely, and validation logic that depends on unconstrained state creates DoS vectors.
A common early mistake is attempting to check an oracle price during validation. In practice, this triggers an AA23 reverted error, or immediate bundler rejection, because validation depends on disallowed state access patterns during simulation. That logic must be moved into the execution phase, which requires structuring the account correctly from day one.
Scope needs to be precise
A naive approach to session keys is allowing them to call “any function” on a router contract.
A router is not a permission boundary. A function selector is.
There is a massive difference between “this key can use Uniswap” and “this key can call exactly this swap function with these parameters.” The first is vague and highly exploitable. The second is enforceable.
Prompt injection is a signing problem, not just an LLM problem
Smart contract security does not protect against an agent being manipulated into building a perfectly valid transaction for the wrong target.
The signature can be valid. The calldata can be valid. The outcome can still be a drained wallet.
The fix is treating signing as a separate trust boundary. Before anything gets signed, a policy layer must inspect the constructed calldata against explicit rules:
- allowed targets
- allowed selectors
- maximum value per call
- cumulative exposure
In practice, leveraging a policy-as-code layer like Permissionless.js adds about 50ms to the execution path. That is a negligible latency cost to pay for a firewall that prevents the agent from signing garbage.
Where the Stack Is Now
Two developments shifted the landscape in 2025.
First, EIP-7702 landed with Ethereum’s Pectra upgrade. It allows an existing EOA to temporarily behave more like a smart account, lowering onboarding friction and improving compatibility with account-abstraction workflows. While highly useful, it is primarily an onboarding improvement.
Second, ERC-7579 gave modular smart accounts a cleaner architecture.
ERC-7579 standardizes how modules attach to smart accounts, allowing developers to compose interoperable building blocks rather than hard-coding monolithic wallets. Session keys, spending policies, and custom executors live as independent modules.
This matters because the real risk in wallet infrastructure is vendor lock-in. Opting for an ERC-7579 compliant, modular stack (like ZeroDev’s Kernel or similar frameworks) ensures the permission model remains portable across different infrastructure providers.
Core Design Principles for Agent Wallets
- Never use a persistent key for an agent task. A fresh session key per task is cleaner, safer, and easier to reason about
- Function selectors matter more than vague contract allowlists. Permissions must be exact, not aspirational
- Policy validation belongs between the model and the signer. Not in the UI. Not in a comment. In an actual execution firewall
- Wire up the Paymaster early. Gas friction is operational noise. Remove it before it becomes a production problem
- Do not write custom account contracts. Unless it is an explicit research goal, use an audited, modular factory and compose from there
The Honest Take
ERC-4337 is not magic.
Validation constraints are real. Bundler behavior is still a factor in the trust model. Paymasters require abuse protection, and not every piece of the modular ecosystem is equally battle-tested at scale.
But the direction is right.
For the first time, the infrastructure is robust enough to grant machines scoped financial agency without handing over the keys to the vault. It is the difference between an AI demo and a system fit for production.
The “autonomous agent” story in Web3 has spent a long time sounding better than it worked. The stack is finally catching up with the idea.
For developers and teams working through agent wallet architecture, session key design, or securing the boundary between AI decision layers and signing authority, this is the infrastructure worth building on.
