On 10 September, Ant International, Visa and Mastercard announced they would work together on a "Know Your Agent" framework: a shared way to link an AI agent to a real entity, check whether it's authorised, and monitor what it does, so an agent verified with one payment provider doesn't have to start over with the next.
That's a good idea, and it's overdue. But look at how agent wallets actually lost money this year, and a gap shows up. Almost all of the work so far is about who an agent is. The attacks are about what it does.
The agent was exactly who it said it was
In May 2026, according to Ledger, attackers drained roughly $175,000 from a Grok-linked Bankrbot wallet. There was no smart-contract bug, no stolen private key and no compromised bridge. There was a hidden instruction inside ordinary content. The agent read it, treated it as a legitimate order, and the transfer settled in seconds. Ledger reports that the Bankr team recovered the funds; on-chain, 79% of the stolen tokens moved to a single address seventeen minutes after the theft, in line with other reports that about 80% came back. Either way, nothing about the agent’s identity would have stopped the transfer.
In July, Zscaler described two campaigns built on the same idea. One hid payment instructions inside a fake API documentation site, targeting agents that search for software packages. The other impersonated DeBank to win an agent's trust. Zscaler then tested 26 language models with a browsing, paying agent of its own. Four of them followed the hidden instructions all the way to a payment.
In both cases, identity was never the problem. Nobody forged an agent or stole a wallet. The agent's registration would have checked out, its wallet was its own, its operator was real. What went wrong was behaviour: the agent paid someone it had no reason to pay. In the Bankrbot case, it sent two and a half times its previous largest transfer of that token, to an address it had never dealt with.
Identity answers "who is this agent?" The question that catches a drain is "has this agent ever done this before?" You can only answer the second one if someone has been keeping a history.
What a drain looks like on-chain
We already follow every payment from every wallet bound to a registered agent on Base, so we can describe the shape precisely. On 24 September we switched on a detector for it. It flags a payment that is:
- at least five times the agent's previous largest payment,
- at least $250,
- sent to an address the agent has never paid before,
- after at least three earlier payments, so there's a history to compare against.
In its first 30-day window it found exactly one case: an agent that had made 48 payments of five cents or less, then sent $250 to a new address.
We don't know whether that was a theft. A legitimate one-off purchase leaves exactly the same shape, and that's the point. The detector reports a shape, with the evidence, for a human to read. It never declares a verdict, and it never names the agent publicly. A monitoring system that cries theft every time someone buys something would be switched off within a week. The detection log →
Update, 27 September: we replayed the Bankrbot drain against our own detector
A rule is only worth publishing if we know what it misses, so we took the one real theft we cite and ran it through our own pipeline, transaction by transaction. It would have missed it: not because the rule is wrong, but because of what it reads.
- We were not watching the wallet. Grok's Bankr wallet on Base (0xb105…e4f9) is not bound to any ERC-8004 identity, and we only follow wallets that are.
- It was a token, not a stablecoin. The theft (tx 0x6fc7…739a, 4 May 2026, 06:49 UTC) moved 3 billion DRB, 3% of the token's supply. Our payment ledger reads USDC, USDT, EURC and DAI only; a DRB transfer never enters it.
- In tokens the size test would not have tripped; in dollars it would. The wallet had sent 1.18 billion DRB once before, so 3 billion was 2.5 times that transfer in tokens. But DRB's price had risen about sixfold in between (Dune's daily prices: $0.0000105 on 7 March 2025, $0.0000640 on 4 May 2026), so in dollars the theft was about $192,000 against about $12,400: fifteen times. Our rule works in dollars, and the address was new, so a token-aware version valued in dollars would have flagged it. Corrected 27 September: an earlier version of this paragraph compared token counts only.
Speed would not have saved it either. The attacker's address forwarded all 3 billion tokens two minutes later; within seventeen minutes they had been split, and 79% sat at a single address. Our sweep runs every three hours and the detector hourly. A ledger explains a drain after it happens; stopping one is the job of the wallet's own policy (spending limits, allow-lists, a second signature above a threshold), set before the agent reads anything. What we change: this page now says so, the limits of the rule are written next to it, and a token-aware version for watched wallets, valued in dollars with a contract allow-list, is on the list, not yet live. The full replay is in Research Note 02.
Ten ways agent money goes wrong
The drain is one pattern. Writing down everything we can see from our position, we count ten, and we already watch for several of them:
| # | What goes wrong | Status |
|---|---|---|
| 1 | Prompt-injected drains: hidden instructions make the agent pay an attacker | Detected (drain pattern) |
| 2 | Retry storms: a broken loop pays the same counterparty over and over, burning fees | Detected |
| 3 | Identity hijack: the registration changes owner, so the bound wallet now belongs to someone else's agent | Detected |
| 4 | Delegated control: a wallet hands control to unknown code under EIP-7702 | Built; waiting on a curated allowlist, because unknown doesn't mean malicious |
| 5 | Registration spam: thousands of identities minted in bursts | Detected: 280 bursts, 27,363 registrations |
| 6 | Reputation farming: ten raters wrote 51.7% of all on-chain agent reputation | Measured; detector to build |
| 7 | Look-alike sellers: an agent pays a service imitating a real one | To build |
| 8 | Allowance drains: an agent approves a token spender it shouldn't | To build |
| 9 | Dead or hijacked endpoints: a service stops answering, or answers for someone else | Partly detected |
| 10 | Metric poisoning: wash payments and self-dealing to fake traction, aimed at every leaderboard including ours | Why only 9.0% of agent-wallet outflow counts as spending |
We keep two words apart on purpose. A detection is a shape with evidence that someone should read. An incident is a detection that is also a harm, and recent. On 24 September there were 303 detections logged and zero live incidents. Zero is the normal answer.
The layers fit together
None of this replaces anything else. The sensible setup for anyone running an agent with money looks like three layers:
- Prevention at the key: spending limits and signing policies, the approach hardware wallet makers such as Ledger are building for agents. Valet keys vs trunk keys →
- Identity at the network: Know Your Agent, as Visa, Mastercard and Ant are designing it.
- Detection from behaviour: a history of what each agent normally does, and an alert when it does something else.
The third layer is the one nobody publishes in the open. Payment networks will monitor their own rails, and exchanges will watch their own custody. But an agent that pays over x402 on Base, keeps funds with one custodian and is rated in another registry needs a view across all of them. No single platform has a reason to build that view, or to publish its own bad numbers.
What we're building
This is where Agentic Finance Graph is going next. The Desk lets anyone bind the agents they run and get told, in real time, when one of them acts out of character. Allow-lists stop legitimate purchases from looking like drains. Every alert comes with what we saw and what to check, and we never act on the wallet ourselves. We watch; we never sign. Open the Desk →
Further out, two things follow naturally. One is a public incident registry: confirmed agent-money incidents with stable IDs, the on-chain evidence and a plain write-up, something like CVEs for agent finance. The other is an agent behaviour file: a history that Know Your Agent providers and marketplaces can read before they let an agent move money. Identity from the networks, behaviour from the record.
Update, 9 October 2026: all three are live now. The Desk opened on 26 September: sign in with a wallet, watch your agents on the free plan, and the watch-list stays in your browser, so nothing about the agents you watch is sent to us. The incident registry is the incident ledger, each incident with a stable ID and its on-chain evidence. The behaviour file is the agent statement: every paying agent gets one every three hours, hash-chained to the previous one and provable against a root we sign. The token-aware drain rule is still not live; it is the subject of our next research note.
A note on our own responsibility
Watching agents means holding something sensitive. Once people bind their agents to an account, we hold a map of who runs what, which is exactly the kind of data an attacker would want. So the rules are simple and non-negotiable. We never hold keys, move funds or sit in the payment path, today or later. When the Desk opens, watch-lists will be encrypted per user and never appear in any public document, and any figure built from Desk data will only be published when enough users stand behind it that no one can be singled out. Everything we publish is already signed, so a tampered copy can be spotted.
Know Your Agent is a good start. But an agent's identity only tells you who to blame after the money is gone. Its history can tell you before.
Sources: Ledger Academy, "Best practices when using AI agents in crypto" (15 Jul 2026); SecurityWeek reporting Zscaler research (6 Jul 2026); crypto.news and Forkast on the Know-Your-Agent framework (Sep 2026). Our figures: Agentic Finance Graph, Base mainnet, 24 Sep 2026, /api/detections.