Anatomy of a Permission-Chain Attack: How Morse Code Drained $200,000
No key was stolen. No rule was broken. Every system did its job as designed. That is the problem.
What Happened
In May 2026, an attacker on X drained roughly $200,000 in tokens from an AI agent's wallet with a single reply. The agent was Grok, connected to a trading bot called Bankrbot, which held a funded wallet on the Base network. The attacker never touched the wallet key. The attacker never broke a rule. Security firm SlowMist later classified the incident as permission-chain abuse. About 80% of the funds came back, but only because the token community identified the attacker personally. Recovery by manhunt is not a control.
What Is a Permission-Chain Attack?
A permission-chain attack manipulates a chain of automated systems so that one system's output becomes another system's authorization. No single system fails. Each one does its job as designed. The failure lives in the handoffs, where no system checks whether the instruction it received still reflects what a human wanted. The wallet trusted the bot. The bot trusted the model. The model trusted the message. Nobody checked the message.
Stage 1: The Silent Permission Upgrade
Before the theft, the attacker sent an NFT to Grok's wallet. Nobody approved the transfer. Nobody had to. Receiving the NFT upgraded the wallet's transfer permissions, the way a membership card upgrades an account. The agent's authority changed and no alarm existed to notice. This is the stage most write-ups skip and the one that should scare you most: an outside party changed what the agent was allowed to do, silently, for the cost of a token airdrop.
Stage 2: The Injection
The attacker then replied to Grok on X and asked it to translate a Morse code message. Translation is what a language model is for, so Grok decoded it faithfully. The decoded text was a payment instruction. Bankrbot received Grok's output, treated it as an authenticated command, and transferred 3 billion DRB tokens to the attacker's address.
Why Every Control Passed
Walk the checklist a rules engine would run. Valid wallet? Yes. Sufficient permissions? Yes, upgraded in stage 1. Well-formed instruction? Yes. Authenticated source? Yes, the command came from Grok, a trusted system. Every mechanical check passed because the attacker built the instruction to pass them. The only thing wrong was intent, and intent does not appear in any field a rules engine can read.
The Lesson: Authorization Drift
The gap between what an agent is permitted to do and what its owner asked it to do is authorization drift. Prompt injection is how attackers create it. Drift is invisible to field-level rules, because a drifted transaction can be valid in every field. It is visible only to a check that reads the owner's original mission and asks whether this action still serves it. That check needs 3 things the Grok pipeline lacked.
- Authority changes must be events, not silence. In stage 1, the agent's permissions changed and nothing fired. Under FLINT, authority lives in the passport's mandate, and mandate changes trip an alert to the owner before the new authority spends. A silent upgrade is itself the signal.
- Actions must be compared to the mission, not just the rules. In stage 2, the instruction passed every rule. A semantic check compares the proposed action against the owner's stated mission and recent actions, and escalates when they diverge. The model that runs this check can only make the decision stricter. It can never approve, so a manipulated checker cannot create an authorization.
- A blocked identity must stay blocked. After a BLOCK, the passport is quarantined for good, and every integrated counterparty sees the freeze. The attacker who burned an identity starts over at zero.
The Honest Boundary
No vendor stops every prompt injection, and you should distrust any who claims to. Injections will keep landing, because reading hostile text is inseparable from reading text. The defensible line sits later in the chain: a manipulated agent must not be able to turn hostile instructions into an authorized transaction. That line holds only for actions routed through an authorization layer. An agent wired directly to a funded wallet, with no check between its output and the money, is the exact architecture that failed in May.
What Builders Should Do Now
Give each agent a passport bound to you, not to itself, so a takeover cannot revoke your control. Set the mandate in plain language: what it may buy, from whom, up to how much, until when. Route spending through a verification call and treat STEP-UP and BLOCK as features, not friction. Turn on takeover alerts so an authority change wakes you up. All of this exists today and issuing a passport is free.
Common Questions
Was this a Grok flaw?
No. Grok translated text, which is its job. The flaw was architectural: downstream systems treated a model's output as a human's authorization.
Would tighter spending limits have stopped it?
Tighter limits shrink the blast radius and are worth setting. They do not close the gap, because the attacker steers the agent inside whatever limits exist, as this attack showed by using permissions the wallet legitimately held.
Is this rare?
The technique generalizes. The same hostile instruction can hide in a webpage, an email, a PDF, or a malicious tool description. The NSA and CISA published joint guidance in June 2026 on exactly this class of agent tool-chain attack.
The attack worked because no layer asked whether the instruction still served the human. FLINT exists to ask, before the money moves.
Get in touch
If you are building on agentic payment rails and want to talk through how FLINT fits your stack, reach out directly.
contact@flint.network