AI agents can request transactions, but an autonomous request should not silently become unlimited wallet authority. ERC-6900 provides a modular account model, while ERC-4337 supplies an account-abstraction transaction flow. This article develops a permission and revocation checklist for AI agent commerce without claiming that either standard alone solves consent.

Modularity changes the security boundary

The ERC-6900 specification describes modular smart contract accounts with validation, execution and hook logic that can be composed outside a single wallet implementation. Its motivation includes session keys, subscriptions, spending limits and role-based access control, all relevant to AI agent workflows. But a modular wallet is not automatically a safe autonomous operator. If an agent can install or reconfigure an execution module, its authority may expand beyond the original user-facing action. Define a strict trust boundary: a human owner authorizes module installation, a policy service limits what the agent can call, and an independent ledger records which version executed. Any design should distinguish permission to generate a recommendation from permission to spend tokens or transfer an asset. The distinction must survive upgrades and module removal.

Translate permissions into observable capabilities

An AI service might need to renew a subscription, pay a storage invoice or mint a licensed creator item. Those tasks should not share an unlimited wallet key. Represent each capability as an explicit tuple containing target contract, function selector, token or asset, maximum value, frequency, expiry and optional human approval. In a modular account, hook and validation responsibilities should be reviewed separately rather than assuming one replaces the other. Show a user the concrete consequences of installing a module: which resources it can access today, how long those permissions last and which action would trigger an approval prompt. A policy based on vague labels such as ‘creator payments’ cannot adequately constrain a generic contract call. Unexpected delegatecalls, broad allowances and arbitrary targets deserve explicit denial rules.

Test installation, upgrades and removal

The risky lifecycle is wider than a single operation. First test initial installation against a malicious account owner signature and a spoofed plugin address. Then test upgrades, dependency changes, revocation while an operation is pending, and removal when previously granted allowances remain active. Module uninstallation is not synonymous with withdrawing ERC-20 approvals or cancelling off-chain service credentials. Record a before-and-after capability inventory and enforce a cleanup checklist. Create a failure fixture where an agent submits an action immediately before its module is removed; define whether the execution is rejected, finalized or reviewed. Include event-order tests across chain reorganizations and indexer delays. A user interface must not claim that a revoked module is harmless until the relevant on-chain state and off-chain credentials have been checked.

Use ERC-4337 receipts without exaggeration

ERC-4337 introduces UserOperations and bundlers for smart contract account execution without consensus-layer changes. Its transaction-oriented mechanisms are useful for structured approval and receipt workflows, but a successful receipt is evidence of an on-chain operation, not proof that the AI made a wise decision or that a digital-media license is legally valid. Link UserOperation identifiers to the policy snapshot, human approval if required, contract addresses and resulting logs. Separate simulated gas estimates from actual paid fees, and distinguish accepted operations from reverted ones. Keep the agent’s natural-language explanation outside the authority path: a persuasive model message must not itself authorize spending. Signed typed data and deterministic policy checks can narrow the authorization surface, but code and financial security reviews remain necessary.

A worked risk scenario for creator commerce

Consider a creator allowing an AI agent to buy licensed image processing credits. The intended policy permits one designated payment contract, a small per-day maximum and a seven-day authorization window. Suppose an updated module silently introduces a generic transfer selector. A safe design catches the new selector during an installation diff, refuses new operations until reapproval, and tells the owner exactly what changed. A weak design considers the module ‘trusted’ because its publisher was previously accepted. In another scenario, the agent generates a refund but the paymaster sponsors a retry after the user has revoked permissions. The wallet must test the current authorization state again rather than assuming a cached approval remains valid. Treat these scenarios as test cases, not evidence of real attacks.

Measure authorization, not just transaction success

Security acceptance should track unauthorized-action blocks, stale policy attempts, revocation latency, approval comprehension and the ratio of operations carrying a verifiable receipt. Measure module installation and removal with both simulated malicious inputs and normal users. False positives matter too: a policy that blocks legitimate low-value operations without explanation can drive people to disable safeguards. Establish release criteria for selector coverage, dependency changes, account recovery and rollback. Preserve contract addresses, tested specification version and expected behavior as documentation, since modular wallet ecosystems evolve. The article is a design analysis of the ERC-6900 and ERC-4337 proposals, not a claim that all deployed smart accounts conform to identical implementations or that a standard guarantees an agent’s commercial judgment.

Sources

• ERC-6900: Modular Smart Contract Accounts, proposal created 18 April 2023
• ERC-4337: Account Abstraction Using Alt Mempool, proposal created 29 September 2021