Under Ethereum’s ERC-20 token standard, an approval can authorise another address to spend cryptocurrency from a wallet without transferring the tokens at that moment. For an AI agent paying for online services or interacting with blockchain applications, that creates two security decisions: whether the agent may act, and what authority its action gives to someone else. A wallet needs to examine both, even when the request carries a valid signature.
Smart contract wallets can apply programmable rules to those requests. Halborn’s February 2026 analysis of account abstraction describes customizable authentication and spending controls, while noting that legitimate signatures authorising malicious approvals remain a threat. Protecting the signing credential and checking what it authorises are separate parts of the security model.
Systems combining account abstraction and autonomous AI agents can give software a restricted signing role while keeping broader account control with its owner. The account’s rules determine which transaction requests that role can authorise. Approval requests need explicit treatment within those rules because they create spending rights for another address. A policy that limits payments must also account for the permissions the agent can grant.
Two permissions, enforced in different places
An agent’s delegated authority belongs to the wallet’s access-control system. A session key, when implemented, lets software authorise a defined set of operations without receiving the owner’s unrestricted signing key. Its permitted actions depend on the wallet’s validation logic.
An ERC-20 allowance is recorded by the token contract. Through the standard approve function, the account holding the tokens designates a spender and an amount that the spender may withdraw. A finite allowance limits the spender’s cumulative withdrawals to the approved amount. The spender can then use transferFrom to move tokens within that allowance. Creating the allowance and using it are distinct operations.
An allowance differs from a reservation of funds. It sets a limit on what a spender may take through that permission, without moving tokens into a separate account. It can exceed the wallet’s current balance, so the balance alone does not describe the authority being granted. Funds received later may be spendable under the remaining allowance, subject to the token contract’s rules. Actual withdrawals remain limited by the tokens available in the account.
A limit on native ETH sent by an account does not necessarily constrain the ERC-20 allowance it creates. The policy needs to recognise the token, spender, and approved amount.
An approved token contract address is, therefore, only part of the decision. Within a call to that contract, the spender parameter identifies who receives spending authority. Permission to interact with the token cannot safely be interpreted as permission to approve any spender.
Approval requests can arrive as signatures
The familiar approval transaction is only one route. Where the token and wallet support the permit mechanism, an owner can authorise an allowance through a signed message. Someone can submit that signature to the contract, which checks it and records the permission. Signing and recording the allowance need not happen together.
This is why message-signing access deserves scrutiny alongside transaction execution. In its August 2025 analysis of wallet allowlist gaps, Blockaid describes how blanket permission for typed messages can admit malicious permit requests granting extensive rights to spend tokens. The signature can be cryptographically valid while granting authority that the owner never intended to provide.
EIP-712, the structured signing format involved in many such requests, is not itself an approval mechanism. Typed messages serve different purposes. Their security implications depend on the message contents and the contract that will accept them. The format organises the data being signed; assessing the permission still requires interpreting that data.
For messages that authorise approvals, the relevant questions concern the permission encoded in the data: which asset is involved, which spender gains access, how much it may spend, and which contract accepts the authorisation. A readable label does not replace those checks.
Compatibility also varies. Support for a permit mechanism and support for a smart account’s signature validation are implementation details. A wallet designed for agents cannot assume that every token accepts the same authorisation format, or that restricting transaction calls automatically restricts every supported route for signing messages.
Making approval policy part of the wallet
Account abstraction provides room to enforce these distinctions through account logic and permission modules. A narrow agent role can be defined around the operations it needs, with approval-related restrictions included wherever that role can create or validate spending authority.
For direct approval calls, that means examining the requested spender and allowance rather than allowing the function to operate indiscriminately. For supported signature-based approvals, the signing or validation path needs equivalent attention to the authorisation’s contents. A rule covering one route does not establish that the other is covered.
These checks are only as reliable as their implementation. Wallet code, installed modules, and the authority to change those modules all affect the boundary. Programmability allows more precise controls, but it also introduces code that must enforce them correctly.
Once an approval is recorded, a spender can use the token contract’s allowance rules without asking the agent to sign each withdrawal. The wallet has granted the spender authority that extends beyond the approval request itself. Its policy must evaluate that access before granting it, alongside the authority of the agent making the request.
Community Discussion
Join the conversation. Ask questions, share solutions, and help others.
Be the first to start the discussion!
