admin
An AI agent using a smart wallet may need permission to pay for computation while being barred from transferring the owner’s entire token balance. A common engineering response is to add modular permission logic rather than deploy a different wallet for every workflow. ERC-6900 specifies interfaces for modular smart contract accounts and modules, including validation functions, execution functions and hooks. It does not guarantee the safety of every module. This article combines the published ERC-6900 draft specification with ERC-4337 account abstraction to develop an implementation checklist. The analysis is an original risk framework, not an assertion that every wallet already supports the specification.
Decide which authority belongs in which module
Begin with an action inventory: reading on-chain information, submitting quotes, buying usage credits, creating token allowances and transferring escrow funds require different trust levels. ERC-6900 identifies validation functions, execution functions and hooks, allowing an account to compose logic around authorizing and processing operations. Map each business action to an explicit validation path and prohibit undeclared methods by default. A module that authorizes one approved payment target should not inadvertently allow an arbitrary destination by passing calldata through unchanged. For every permission, document the caller, allowed contract, method selector, spending limit, expiration and emergency revocation path. This is an application-level authorization model; do not mistake a wallet’s ability to install plugins for proof that its installed plugins are safe.
Audit the boundary between validation and execution
Validation answers whether an operation may proceed; execution performs its effect. Security failures arise when validation inspects a simplified description while execution receives different parameters or follow-up calls. Review how an account binds execution payloads to the authorization decision, including nested calls and batched operations. Test an authorized small payment followed by an unauthorized secondary transfer inside a batch. The module should either inspect the complete requested call set or reject the batch as outside its mandate. Hooks can add checks before and after execution, but a post-execution hook cannot undo a finalized external transfer. Favor fail-closed behavior when parsing unknown targets or selectors. Use unit tests against contract-level inputs, not model-generated summaries of what a transaction supposedly means.
Treat plugin upgrades as permission migrations
A modular account changes over time: its owner installs, replaces or disables modules. An upgrade can alter who may act, what limits are enforced or which external services are trusted. Require a review artifact comparing old and new module interfaces, storage mappings, signer policies and behavior under reentrancy or callback conditions. Test the ability to disable the module when a creator withdraws AI-agent access. Publish a list of transactions affected by the upgrade and keep a path for restoring known-safe permissions. ERC-6900 provides composable interfaces; it does not replace operational governance. A commercial service should separate who proposes an upgrade from who authorizes execution, particularly when an AI planner can recommend its own additional privileges. Record upgrade approvals in a clear audit trail.
Constrain the payment loop at transaction time
An agent may be told to buy ten dollars of usage credits, then repeatedly call a vendor when the network is slow. If every retry creates a new on-chain transaction, the owner can be charged several times. Apply a workflow-level idempotency reference and reconcile confirmed chain transactions before retrying. Pair that with a daily or per-job spending cap and an allowlist of vendor contracts. A successful signature is not equivalent to a settled invoice: finality, event logs and off-chain delivery receipts need independent reconciliation. ERC-4337’s UserOperation process can coordinate account abstraction, but it does not supply a universal refund guarantee for a failed vendor service. Make the agent stop and request a human decision when duplicate uncertainty cannot be resolved automatically.
Validate revocation under hostile and delayed conditions
Build a red-team test with a module whose owner permission is revoked while several UserOperations remain pending. Determine whether validation occurs against the current on-chain authorization state and whether previously signed requests can still execute after the revocation. Test clock expiry, key rotation, partial allowance revocation and a compromised external module dependency. No design should promise that already finalized payments can be retroactively canceled. A stronger property is that future unauthorised operations fail when reevaluated. Keep a public incident procedure for pausing the agent, notifying stakeholders and reconciling spending. Review the same cases whenever execution logic or supported wallet platforms change. Revocation is a measurable state transition rather than a decorative toggle.
Deploy with evidence, not a generic security badge
Before a creator or enterprise customer delegates funds, assemble module source and compiler versions, audit status, supported wallet account implementations, test vectors, known configuration limits and a rollback runbook. Include the distinction between ERC specification maturity and actual contract deployment maturity. Run a staging environment with intentionally malformed signatures, forbidden contracts, exhausted budgets and nested calls. Measure rejected unsafe operations, authorized task completion and unexplained differences between expected and actual balances. Require separate review for each new vendor or payment method; a safe module today can become unsafe after its allowed target adds new features. ERC-6900 enables composability, but trust comes from explicit permissions and ongoing verification.
This is a technical decision framework, not a guarantee that credentials or modular wallets prevent every failure. The safest implementation records uncertainty and refuses authority it cannot verify.
