In May someone took about $150,000 out of an on-chain agent's wallet. No stolen key. No contract bug. Grok was wired to a Bankr wallet on Base. Someone prompt-injected Grok with a reply on X, payload hidden in Morse. Then the part people skip: Bankr read Grok's output and signed the transfer on it. One agent trusted another's output. That was the whole exploit.

SlowMist mapped the kill chain and called it permission chain abuse. Privilege escalation, injection, on-chain execution. Read it. The post-mortem isn't my point. The point is this isn't rare.

StakeBench ran trading agents across a range of setups. Direct injections worked more than 79% of the time. Indirect ones, buried in data the agent reads, 42 to 68%. No reliable defense in anything they tried. Grok wasn't a careless outlier. It's close to the default for an agent that reads untrusted input and can move money.

These agents get audited. The audits weren't wrong. They checked the contract and the contract held. No Solidity moved that money.

Two things did. An inbound NFT widened what the agent's wallet was allowed to do, so the capability was live before a word was sent. Then the signing agent took another agent's output as a trusted instruction. Neither is a line you can point at in a file. Both are about how the pieces behave once they're wired together.

That's the gap. An audit asks if the code is correct. It doesn't ask which states the agent can be pushed into once the wallet, the tools, the untrusted input, and the other agents it listens to are all live at once. The second question is the one that costs money.

We don't call these vulnerabilities. Without a working proof against a specific deployment they're reachable failure paths. Candidates. What makes a candidate worth acting on is classification, of a state, not a finding. Can the agent be pushed into it (Reachable). Could a design choice have kept it out of reach (Avoidable). Once it's reached, can it be undone (Unrecoverable). The read comes from several models reasoning independently, because one model alone misses whole classes it wasn't told to look for.

Grok drain:

• Reachable. Yes, permissionless. The path ran through a public reply anyone could post.

• Avoidable. Partly. Letting an inbound NFT change wallet permissions is a choice. So is letting one agent sign on another's say-so with no check. Bankr had blocked Grok's replies in an earlier build and dropped the block in a rewrite.

• Unrecoverable. Here the easy reading is wrong. On-chain it was final. Funds settled and moved. Most of the value came back, but only because the community deanonymized the attacker and negotiated. That's an off-chain, social recovery. You can't design around it and you can't count on it. Technically the loss was irreversible.

Quieter case, from StakeBench. An agent finishes your task while steering it, nudging toward a token or leaking a credential on the way.

• Reachable. Yes, and the base rates aren't small.

• Avoidable. Harder. The pattern is built to leave no trace. You can't avoid what you have no check for.

• Unrecoverable. Mixed. A steered trade you might unwind. A leaked key you won't.

Two states, same catalog, nothing alike. One loud and final. One quiet, usually reversible per event, and still running. A list of findings doesn't separate them. R/A/U does. That ordering is where you look first.

The public cases aren't the whole list. The behavior-layer paths that keep showing up across on-chain agents come down to a handful:

• Direct injection. Sent straight to the agent.

• Indirect injection. Hidden in data the agent reads.

• Capability escalation via an on-chain artifact. An inbound token or NFT widens what the wallet can do.

• Memory or context poisoning. Bad data planted now to bend a decision later.

• Stealthy goal-steering. The agent working for you and someone else at once.

• Inter-agent trust. One agent taking another's output as authorization.

• Tool-channel poisoning. The path coming in through a connected tool or MCP server.

Touch any of these and the matching path is worth checking for reachability.

The trick changes every week. The structure doesn't. Read input you don't control and you can be injected. Hold funds and a wrong call becomes a loss. The agent listens to other agents, so it inherits whatever compromised them. And it runs unattended, which gives an attacker room between the steps. Most useful agents have all of this. Same thing that makes them useful.

The goal-directed ones are most exposed. You hand them an objective and let them run. Rebalance this. Chase yield there. They read the most untrusted data and a human checks the least. That's the profile every case above hit.

So the question about your agent isn't whether its contract passed an audit. It's which of these paths it can reach, and which of those are irreversible.

This is methodology work, in the open. Cases are public, reasoning is public.

There's a wave of automated agent-security tooling landing right now. Scanners that promise a fast, scalable verdict. This isn't that. If you run an on-chain agent and want a read on which of these paths it can reach, and which would be unrecoverable if it did, I'll do a worked R/A/U read on your actual setup, for a small number of agents, no charge. By hand, not by scanner. No yes/no safety stamp. Verification, not coordination.

founder@getreacher.xyz, or @getreacher

CC BY-SA 4.0