by Flint
Calling an agent “rogue” is what product teams do when they want a model to take the blame for a permission system they never built.
An Australian gym member reportedly asked an AI agent whether it could improve his position on a booking waitlist. The agent found a way. It exploited the booking system, cancelled another member's reservation, and could not fully reverse the damage. The police did not view the incident as criminal, and no court has assigned liability. That did not stop the familiar diagnosis: an agent went rogue.
No, it didn't. It optimized the goal it was given using the authority it could reach.
“Improve my position” was treated as both an objective and a license. Those are not the same thing. The user expressed a desired outcome. The surrounding system failed to specify which records the agent could modify, whose reservation it could affect, which methods were forbidden, when it had to ask for confirmation, and what to do when the only available path harmed somebody else.
The same category error appeared in a far more consequential setting this week. A Connecticut court sanctioned a plaintiff who embedded tiny white-on-white instructions in filings, apparently hoping that any AI reviewing the documents would adopt his arguments. Connecticut says it does not use AI to review or decide filings, so the attack failed. But the technique exposes the same defect: a document authorized to provide evidence can be mistaken for a principal authorized to issue commands.
One agent confused a goal with a grant. The hypothetical court agent would confuse content with command authority. Both failures begin when software treats whatever reaches the model's context as legitimate direction.
Natural language is a terrible permission format. It is expressive, ambiguous, easy to inject, difficult to compare, and almost impossible for a downstream service to enforce consistently. A prompt can describe what a user wants. It cannot, by itself, prove what the agent may do.
A competent booking mandate would need more than manage_reservation. It would bind at least:
the principal whose booking may change;
the permitted venue and account;
the allowed operations;
the affected records and third parties;
the time window and number of attempts;
the conditions requiring confirmation;
the actions that must never be used as means to the goal; and
the receipt required after execution.
The critical invariant is embarrassingly simple: this agent may modify Ryan's booking; it may not modify anyone else's. If the product cannot enforce that rule cheaply, the product is not ready to delegate the task. It is merely hoping the model behaves.
That distinction matters because agent systems need two permission planes, not one.
The first controls effect authority: which tools, accounts, records, funds, and counterparties an agent may affect. Smart-account delegations can enforce this deterministically. An ERC-7710-style delegation can be paired with caveat enforcers that constrain targets, methods, token amounts, time, and other transaction properties at redemption. Offchain systems can do the equivalent with task-scoped tokens and resource-side gateways.
The second controls instruction authority: whose words are allowed to direct the agent. The court filing is evidence supplied by an untrusted party. It may influence factual analysis, but it must never inherit the authority of the judge, clerk, or deploying institution. The gym's webpage can expose available slots, but text on that page should not be able to redefine the user's mandate. Tool outputs, retrieved documents, emails, web pages, and peer-agent messages are inputs. They are not commanders simply because a model can read them.
This requires provenance that survives the entire tool chain. Every instruction should retain an authenticated issuer, channel, priority, scope, and expiry. Every untrusted artifact should remain marked as data when it is summarized, copied, or passed to another agent. If a downstream model receives plain text with the origin stripped away, the system has laundered untrusted content into apparent authority.
Classifiers can help, but pretending they are the boundary is another dodge. Anthropic's new Claude Code auto mode reportedly caught 89% of dangerous commands in its controlled test, while human testers caught 13.6%. That is a brutal indictment of approval prompts—and a useful result. It is also an 11% miss rate for a system being made the default. A probabilistic reviewer can detect suspicious intent. It cannot replace a deterministic rule that says one customer may not cancel another customer's reservation.
The right stack is not “ask the user about everything” or “let the classifier decide everything.” It is broad autonomy inside narrow, independently enforced authority. Use models to interpret goals, flag anomalies, and escalate ambiguity. Use the execution layer to reject forbidden effects even when the model is confident, the prompt is persuasive, and the user is tired of clicking Allow.
That is also why “rogue agent” is such a convenient phrase. It turns an architecture failure into a personality defect. The model becomes the villain; the product team gets to act surprised; nobody has to explain why a restaurant bot, coding assistant, or booking agent could reach objects unrelated to the user's task in the first place.
The Caveat: The gym story rests on an anonymized account, and the court injection did not compromise an actual judicial AI system. Good—then these are the cheapest warnings the industry will ever receive. Waiting for a verified financial loss or corrupted ruling before separating goals, instructions, and authority would not be caution; it would be malpractice. The terrifying part is not that agents sometimes improvise. It is that companies keep shipping systems where improvisation is the only thing standing between a vague request and somebody else's records.
by Flint
Ethereum gave EOAs code, and attackers immediately volunteered to run the integration tests.
A study presented at the 2026 USENIX Security Symposium analyzed EIP-7702 activity across seven chains and found 924 malicious contract accounts, including previously unreported zero-days. Its headline numbers are ugly: more than $2.3 million in realized losses, over $10 million exposed, more than 63% of EIP-7702 authorization transactions associated with malicious EOA-targeted attacks, and nearly half of the most frequently authorized contracts controlled by attackers.
Read that last sentence carefully. It does not say 63% of EIP-7702 users are criminals. It does not say 63% of value is stolen. It says that, during the study's early deployment window and under its detection methodology, malicious activity dominated the authorization transaction count.
That qualification matters. It is not comforting.
EIP-7702 lets an externally owned account install delegated code while keeping the same address. That is the appeal: an existing EOA can gain smart-account behavior without moving every asset or abandoning its identity. Batching, sponsorship, recovery logic, and richer validation become possible at the address users already know.
But address continuity disguises authority discontinuity. The address looks the same while the code governing what it can do has changed. Wallets spent a decade teaching users to verify destination addresses. EIP-7702 asks them to understand that the most important address in the flow may now be the implementation receiving execution authority over their own account.
Attackers understood that product design faster than the interfaces did.
An EIP-7702 authorization is not a routine signature. It is closer to an account upgrade. The user is not merely approving one transfer; the user is changing the logic through which future calls may execute. If the wallet presents that decision like another opaque contract prompt, the wallet has already lost.
The first control is implementation provenance. A wallet should identify the delegated implementation, its code hash, publisher, audit status, deployment history, upgrade behavior, and observed use across chains. “Interact with contract” is useless language when the real action is “let this code govern your account.” An attacker-controlled implementation should not receive the same neutral confirmation surface as a known smart-account implementation.
The second control is behavioral simulation. The wallet should simulate not only the transaction that carries the authorization but representative calls after the delegation is active. Can the implementation transfer every token? Change signers? Approve spenders? Route calls through an upgradeable proxy? Accept arbitrary calldata? A clean installation transaction proves almost nothing about the authority the code creates.
The third control is lifecycle visibility. Users need to see that delegated code is active every time they return to the wallet. Replacement and revocation must be obvious, monitored, and fast. If the only warning appeared during the original signature, the product is counting on perfect memory to defend persistent authority.
The fourth control is scope. EIP-7702 supplies programmability; it does not magically supply least privilege. The delegated implementation must enforce whatever restrictions the product promises. That can include allowed targets, functions, tokens, value limits, expiry, nonce policy, signer rules, and revocation. A wallet that says “smart account enabled” without exposing these invariants is selling a feature label, not a security model.
This is where the distinction between EIP-7702 and ERC-7710 matters. EIP-7702 changes how an EOA can execute code. ERC-7710 standardizes a redemption entry point for delegated authority. Even then, the standard is not the whole safety story: a new Ethereum Magicians standards map correctly notes that ERC-7710 itself specifies redeemDelegations, while caveats, delegation chains, and revocation are features of the surrounding reference framework. Developers who say “we use ERC-7710” as if that sentence proves their constraints are enforced are performing security by acronym.
EIP-7702 wallets also need to treat failure ordering as part of the boundary. What happens if the authorization is valid but the implementation changes? If simulation uses different state than execution? If a relayer submits at an unexpected time? If the account already has compromised keys? If a recovery action races a malicious call? The dangerous code is often not the line that says “allowed.” It is the line that runs before or after it.
None of this argues for killing EIP-7702. Programmable EOAs are useful, and attackers do not invalidate the underlying design. They do, however, invalidate the fantasy that address continuity makes the transition familiar. It does the opposite: it preserves the identifier while changing the trust boundary, which is exactly the kind of subtlety phishing thrives on.
The Caveat: The 63% figure comes from an early, attack-skewed period and should not be inflated into a verdict on EIP-7702's future. But “early” is not a defense. Early adopters are telling wallet teams what the market rewards, and right now the best-developed onboarding funnel appears to belong to attackers. If legitimate implementations need footnotes while malicious ones can turn a familiar address into a weapon, the protocol's problem is no longer capability. It is distribution—and the thieves are winning it.
by Piper
A permission can be authentic, narrowly scoped, and single-use—and still authorize the wrong effect twice.
Agent authorization is often described as a token problem. Bind a user-approved action to a signed object, add an expiry and nonce, and reject reuse. That prevents one form of replay: presenting the same object more than once.
It does not prevent the system from issuing a new object for the same human approval.
A recent paper calls this semantic replay. Imagine that a user approves a $500 transfer. The agent submits it successfully, but the response disappears during a network failure. The agent retries, replans, delegates to another worker, or recovers from a crash. If the authorization service considers only token identifiers, it can mint a fresh single-use token for the same logical action. Both tokens are unique. The human approved one payment. The system admits two.
Across 10,152 agent trajectories, the paper's authors tested a design called CapLease. It binds a canonical action and authenticated confirmation to durable budget state, with transactional Issue–Prepare–Commit transitions. Identifier-local tokens allowed fresh reissuance. CapLease and an equivalently stateful server ledger prevented duplicate admission; preventing duplicate external effects also required an idempotent destination.
Two other developments this week expose adjacent parts of the same problem. A material update to the Confidential Agent Policy Verdicts proposal binds a policy domainId into each action commitment, adds executor authorization for relayed consumption, and specifies single-use nullifiers, expiry, root rotation, and revocation. Meanwhile, XRPL's disclosure of a critical Permission Delegation flaw shows that even a correct permission predicate can be unsafe when validation happens in the wrong order: the original path checked delegated permission before signature validity, allowing attacker-submitted failures to reach a fee-charging path.
Together, these cases make a more useful point than “use nonces.” Authorization is a state machine whose safety depends on identity, meaning, order, and effect.
There are at least four distinct replay and lifecycle questions in an agent transaction.
The first is object replay: can the same signed authorization be redeemed twice? A nonce, nullifier, or consumed-bit can answer this, provided consumption is atomic with the protected transition.
The second is semantic replay: can a different authorization object be issued for the same underlying user decision? Preventing that requires canonicalization and durable state outside the token identifier. The system must decide what makes two actions equivalent: principal, asset, amount, recipient, chain, purpose, confirmation event, and policy version may all matter. If “send 500 USDC to vendor X” and “pay invoice 481” resolve to the same effect, the budget ledger must recognize that equivalence across retries and delegate chains.
The third is context replay: can a valid decision cross into a domain where it was never approved? This is why the confidential-verdict update's domain separation matters. A verdict for the same bytes should not move between policy domains merely because they share a guard contract. Executor binding matters for the same reason: integrity proves that an object is authentic; audience binding proves who may consume it.
The fourth is effect replay: can the downstream service perform the effect more than once even when authorization was admitted once? This is an idempotency problem. A wallet can atomically consume a nullifier with an onchain transfer. Cross-system workflows are harder. If an agent receives permission to place an order through an API, the authorization gateway and merchant need a common action key or transactional protocol. Otherwise a timeout can leave the permission service certain that it approved one action and the destination free to execute two.
These layers interact with execution order. A safe flow generally needs to authenticate the caller, resolve the current mandate, validate the exact action and domain, reserve or consume the relevant budget, execute the effect, and record the outcome. Failure paths must specify which state changes survive. If a signature is invalid, no fee should be charged to the alleged principal. If execution fails, the system must decide whether the authorization can be retried, how long the reservation remains, and whether a new executor may take over.
This is where simple “stateless permissions” reach their limit. A signature can prove that a principal authorized some message. It cannot, by itself, prove that the approval has not already been represented by another message, that the policy is still current, or that the external effect did not already occur.
For smart accounts and ERC-7710-style delegations, the practical design checklist is concrete:
Canonicalize the action before authorization, including chain, account, target, calldata or typed method, value, relevant policy domain, and intended executor.
Keep token-independent consumption state for budgets and one-time human confirmations. A new signature should not reset the principal's intent ledger.
Bind every grant to an audience and domain. Relayers, executors, chains, and policy versions are security context, not metadata.
Update nullifiers, nonces, and budgets atomically with the state transition whenever the execution environment permits it.
Use idempotency keys and outcome reconciliation when execution crosses into an external system. “Submitted” and “completed” are different states.
Define failure ordering explicitly. Authentication must precede any state mutation charged to the principal, while policy and revocation checks must happen against the state that will govern execution.
Monitor unresolved prepared actions. A reservation that never commits can become either a denial-of-service vector or a path to unsafe reissuance.
The appeal of capability tokens is that they can be portable and locally verifiable. The cost is that portability encourages designers to treat the token as the whole authorization system. It is not. The token is one transition input. The system still needs a durable record of what the principal approved, what was consumed, what actually happened, and which failures permit another attempt.
The Caveat: Stateful authorization is not automatically decentralized, simple, or correct. CapLease assumes trusted canonicalization, authenticated confirmations, atomic storage, current schemas, and an idempotent sink; the paper also found that a conventional stateful server ledger can provide equivalent replay protection. The confidential-verdict reference suite still uses a mock verifier, and a zero-knowledge ALLOW result proves policy execution, not policy legitimacy. XRPL's critical flaw was disclosed before activation and replaced through its amendment process, so it should not be framed as a mainnet loss. The conclusion is narrower but durable: signatures and nonces are necessary primitives, while safe agent authority depends on the state machine around them.