The attack broke no cryptography. It used two gaps a general-purpose chain leaves open: nothing established who was accountable for the agent, and nothing capped what it could move.
In May 2026, someone on X gifted an AI agent a membership NFT, sent it a message in Morse code, and caused a crypto wallet associated with that agent to transfer tokens then valued at roughly $150,000 to $200,000. No smart contract was exploited, no private key was stolen, and no cryptographic guarantee failed. Most of the tokens were later returned after the token's community traced the attacker, who kept an estimated twenty percent. The money mattered less than the mechanism: the agents did exactly what they were built to do.
How the Theft Worked
The target was Grok, the assistant xAI runs on X, connected to Bankrbot, an agent that executes on-chain actions in the Bankr ecosystem on Base and acts on instructions from trusted parties like Grok. The attacker chained two moves.
First, the attacker gifted a Bankr Club Membership NFT to a Bankr-provisioned wallet associated with Grok. Counterintuitively, arming the target was the point: the software treated possession of that membership as authorization, switching on the transaction capabilities the attacker would later hijack. Security firm SlowMist described it as a permission chain attack.
Second, they sent Grok a string of Morse code and asked it to translate. The encoding appears to have slipped past controls that would have recognized the same instruction in plain English. Once Grok decoded it, it emitted the transfer instruction, and Bankrbot, treating output from Grok as an authenticated command, executed it. Roughly three billion DRB tokens left the wallet.
The Two Gaps the Exploit Actually Used
It is tempting to file this under prompt injection and move on, but the injection was only the trigger. Every cryptographic system in the stack worked: the signatures were valid and the wallet did what a wallet does. The transfer went through two gaps those systems do not cover.
The first gap is accountability. Nothing established who was answerable for the agent's authority. Permission was inferred from a token sitting in a wallet, not bound to a verified principal responsible for how it got used.
The second gap is containment. Nothing capped what the agent could move once it was treated as authorized, so three billion tokens could leave on the strength of a single decoded string.
Neither gap is unique to this incident. Menlo Security has documented indirect prompt injection against payment agents, where an invoice carrying instructions hidden in white-on-white text tells an agent to redirect funds while a human reviewer sees an ordinary document. The lesson of that research is that you cannot assume the input channel is clean. Filters and content checks help and will always be needed, but they are the wrong place to put the last line of defense. If an injection will sometimes get through, the guarantees that matter have to sit somewhere the injected agent cannot reach: in who the agent is, and in how much it is allowed to move.
Identity Answers the First Gap
On Concordium, an agent exists because a verified, accountable human principal stands behind it. Identity is not a credential the agent presents and a counterparty may or may not consult. It is a condition of being registered in Concordium's Agent Registry at all. There is no anonymous agent to hand a membership NFT to and then talk into acting, because an agent without a verified principal never becomes a registered agent in the first place.
That does not stop someone from injecting a registered agent. It changes what happens next. Every action carries a verified principal, so a successful manipulation is attributable to a named, accountable owner rather than dissolving into an anonymous wallet. Attribution is not prevention, but it is the difference between an incident you can investigate and one you cannot.
Limits Answer the Second Gap
Identity establishes who is accountable. It does not decide how much damage a verified but compromised agent could do, and that is the second half of the problem.
Concordium's Protocol Level Locks (PLL) are designed to bind what an agent can move at the protocol level. The constraints are defined when the lock is set up, and the protocol enforces them before any transaction executes rather than leaving an application to evaluate them at run time. A verified agent that is manipulated still cannot move value beyond the limits set on the lock, because the constraint lives below the application, in the protocol that settles the transaction. Applied to the Bankr case, the point is not that a cleverer filter would have caught the Morse code. It is that an agent should not have been able to move three billion tokens on the strength of a decoded string, whatever the filter missed.
What This Actually Changes for You
None of this makes an agent unhackable, and no one should claim it does. Applications will still need prompt-injection defenses, monitoring, and approval steps. The argument is narrower and sturdier: the guarantees that decide whether a compromise is survivable should not depend on the very agent or application that got compromised. Put identity and spending limits in the protocol, and a successful injection becomes something you can attribute to an accountable owner and something whose financial damage is capped in advance.
This is not a fringe-of-crypto concern. More than half of banks are already piloting AI agents, and the technology is moving into trading, treasury, and wealth operations. As agents take on real financial authority, the question to ask of any stack is plain: when an agent moves money, what proves an accountable principal authorized it, and what stops it from moving more than it should? If both answers live only in the application, they hold exactly as well as the application does on its worst day. See how Concordium's Agent Registry and Protocol Level Locks answer it.
Join the Concordium community and follow us on X.