New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
An opinion article preserved in Coin Revolution argues that wallet infrastructure needs to accommodate automated agents. That historical argument raises a practical systems question without settling it: what exactly would an agent be allowed to do? The word autonomous does not specify a permission model. A program might produce recommendations, prepare unsigned requests, invoke a restricted signer or hold unrestricted signing material. Those arrangements have different consequences even if their screens look similar. This new essay develops a fictional review exercise for an automated controller. It is not a description of a deployed product, a recommendation to delegate assets or a claim that a named platform implements the controls discussed below.
Separate advice from the ability to act
Imagine a fictional organisation that asks an assistant to monitor a test portfolio. In one design the assistant produces a report. In another it prepares an unsigned transaction for review. In a third it can cause a signer to authorise an operation without an additional human decision. The same natural-language request could appear at the top of all three workflows, but the authority granted is not equivalent. The review should identify the exact boundary at which a suggestion becomes a request and the boundary at which that request can affect controlled resources.
Draw that chain using component names rather than product labels: observation source, planning model, request builder, policy checker, signing component and network submission. For each connection, ask what input the next component accepts and which checks it performs independently. If a model's explanation is the only evidence that a request follows policy, the explanation is part of the decision path rather than an independent control. A policy boundary becomes meaningful when a component with enforcement authority can reject an otherwise plausible request because its concrete parameters fall outside the permitted scope.
Write permissions as constraints, not adjectives
Limited, trusted and low risk are descriptions, not complete permission rules. In a fictional test arrangement, a permission might name one network, one test asset, two allowed destination contracts, a maximum amount and an expiry condition. The exact enforcement would depend on the account and signing design. A review should not assume that mentioning those conditions in a prompt makes them binding. Each condition needs an identified checker, an input representation and a defined result when the checker cannot establish that the condition is satisfied.
ERC-4337 is a useful primary reference for the distinction between validating a proposed account operation and executing it. It describes an account-abstraction mechanism, not a universal agent safety policy. Reading the standard does not establish that a particular wallet restricts every action an agent can initiate. For the fictional controller, document the actual account implementation and the component responsible for each restriction. A supported transaction format can carry an operation through infrastructure while leaving application-specific limits entirely to another part of the system.
A per-action limit is not a total budget
Suppose a test controller may request no more than ten units in one operation. A sequence of twelve permitted operations could still request 120 units unless another rule limits the aggregate. This is elementary arithmetic, but it exposes a common ambiguity in statements that an agent can only spend a small amount. Small relative to which interval, asset and total? The review should identify whether the policy measures individual requests, successful state changes, pending requests or some combination. Different definitions handle retries and concurrent actions differently.
Use a fictional daily budget of 30 units to make the review concrete. Two pending requests for 20 units each cannot both be treated as harmless simply because neither has completed yet. A controller needs a coherent reservation or ordering rule if concurrent actions share a budget. A failed request also needs a clear accounting treatment so that the system neither permanently consumes a budget unnecessarily nor releases a reservation while an action can still settle. These are properties to verify in the implementation, not guarantees supplied by an agent's stated intentions.
Revocation needs a location and a clock
An interface button labelled stop can mean several things: stop planning new requests, stop forwarding prepared requests, revoke a permission or disable a signing component. Those effects should not be conflated. A previously signed request may remain usable under its own rules even after the planning process stops. In the fictional review, list what has already crossed each boundary at the moment of revocation. Then identify which outstanding capabilities remain valid and what condition, if any, makes them expire or become unusable.
Time limits also require a defined clock. A browser's displayed countdown, a server's wall clock and a network-validated time condition need not be the same authority. Record which component evaluates expiry and what happens around the boundary. A clear statement might say that no new requests are signed after a local cutoff while acknowledging that already authorised requests follow separate validity rules. That is more informative than promising instant cancellation without specifying whether the promise applies to planning, signing, submission or execution.
Treat observations as inputs, not instructions
An automated controller may read market commentary, protocol documentation, transaction descriptions or messages from other systems. Those observations can contain text that looks like an instruction. A review should distinguish the channel that defines the operator's policy from the channels that supply data. A quoted sentence on a web page should not expand an allowlist, change the destination of a prepared request or authorise a new network merely because a model can interpret it as a reasonable next step. Source relevance does not itself grant authority.
For the fictional exercise, give the controller an ordinary document that recommends changing a destination. The expected result depends on the authorised task, but the test should establish that external prose cannot silently rewrite enforced permissions. Also test missing data, inconsistent balances, unavailable policy services and ambiguous asset identifiers. A design that only demonstrates success under cooperative inputs has not shown what its authority boundary does under uncertainty. The valuable evidence is the concrete rejection or escalation behaviour, with enough recorded context to explain why the action did not proceed.
Review evidence of control, not confidence in the model
A useful review record connects the request that was proposed, the policy version evaluated, the decision made and the action that actually occurred. These are different records. A planning transcript can explain why an agent wanted something, but it is not proof that a policy checker approved the same parameters or that the network executed them. Conversely, a network transaction does not prove that the operator intended the request. The reviewer needs an evidence trail across the boundaries, including failed and rejected attempts rather than only successful demonstrations.
The final question is therefore not whether the assistant sounds cautious or whether its prediction was correct. It is whether its ability to affect resources is constrained by an understood mechanism, whether that mechanism handles cumulative activity and outstanding requests, and whether a reviewer can observe its decisions. Better reasoning can improve suggestions, but it does not substitute for a defined authority boundary. The historical opinion is a starting point for this investigation. The fictional exercise shows how to turn a broad automation claim into specific, testable questions about control.
Technical references
- ERC-4337: validation and execution of account operations ↗
- Ethereum documentation: accounts and contract-controlled behaviour ↗
From the recovered archive
- AI agents are coming for DeFi — Wallets are the weakest link · captured 16 September 2025