An agent was talked into sending $150,000 in Morse code
No exploit and no stolen key, just a message the model agreed to act on. Prompt injection is not a bug you patch, so what can a persuaded model express?
In short: You may have read how an AI agent was talked into sending $150,000 in May 2026 by an order hidden in Morse code, with no bug and no stolen key. Prompt injection, hidden text a model takes for a real order, is still an open problem. So the better question is what a fooled agent is able to do. Here the agent picks from a fixed set of actions and only fills in values such as the amount, asset and network. Money goes to your own account, never to an address the agent types, though we have found four attacks on our own guard.
In May 2026 somebody took $150,000 out of an AI-integrated wallet without finding a single bug.
They sent a membership NFT to the wallet, which silently moved it into a higher permission tier. Then they posted a reply on X with an instruction hidden inside Morse code. The agent (Grok, wired into a trading bot) decoded the Morse, read the instruction, decided it was a legitimate command, and authorised the transfer.
There was no exploit, no stolen key and no compromised server. The model was simply asked nicely, in a format nobody had thought to distrust.
Two failures, and only one of them gets discussed
Both have names. They are OWASP LLM01:2025 and LLM06:2025, the first and sixth entries in the standard list of ways language-model applications fail.
The model could not tell an instruction from its principal apart from an instruction in its input. Everyone is working on this. Nobody has solved it.
Once persuaded, the model was able to express “send everything to this address.”
This one comes from the surrounding system, not the model. It is a question of what the system permits to be written down.
The first failure is the one that gets the headlines. The second is the one that decided how much it cost.
If injection is going to happen, the design question is what a fooled model can actually do.
The industry’s answer, and why it stops short
Read a dozen vendor pages on agentic wallet security and you get the same list: least privilege, scoped session keys, per-transaction and daily caps, a recipient allowlist, human confirmation for anything irreversible, keys isolated from the reasoning process.
All of it is good, and some of it is not happening: 45.6% of teams still share one API key across their agents, which makes it close to impossible to trace or stop an agent that has turned. The reported dollar totals for agent breaches are worth treating carefully. The headline Q1 2026 figure is dominated by a single incident that primary reporting attributes to compromised executive laptops rather than to anything about agents. The failure mode that is well evidenced is narrower and more useful: attacks on agents’ memory and on the protocols connecting them to their tools.
The whole list also shares an assumption:
Permission scopes must be defined precisely, but defining them precisely is hard, because agents act on language-based intent and language is ambiguous.
That sentence, or one almost exactly like it, appears across the field. It is treated as a hard problem to be managed with ever-tighter scopes.
It is a hard problem, but it is only unavoidable if the model is composing calls.
We took the field out instead
The agent here does not write instructions. It picks an operation from a fixed set of actions and fills in only the values below.
- amount
- A quantity, in the asset's own scale
- asset
- A symbol from the network's list, never an address
- network
- One of the supported networks
- role
- Where the funds go, such as your own account, never a raw address
- market
- A curated market name, never an identifier
- basis points, deadline, price, tick
- Bounded numeric kinds
So run the Morse code attack against this. The model is persuaded; assume that completely. It now wants to send your funds to an attacker.
It cannot write that down. The destination is your own account, looked up at the moment the step runs. There is nowhere to put an attacker’s address, so nothing has to detect the attempt.
- An operation not on the list cannot be named
A plan naming anything outside the list of actions is refused when it is written, instead of being attempted and failing halfway.
- Anything produced goes to you
The destination is looked up from your account, never a value the plan supplies.
- Caps are set on your account
Per asset, per period. Nothing on our side can raise them.
- The agent is a contract, not a key
A key can be stolen and used by whoever holds it. A contract either has your permission or it does not, and granting it is one-way, so an account can never be re-pointed at a different agent.
Where this stops being comfortable
Everything above is real and none of it makes us safe in general. One thing you should weigh against it:
Those are reachable in two situations: a permissive mode we do not run in by default, and anywhere somebody holds the keeper key directly and therefore never goes through our signing service. In normal operation that service will not produce the shape of instruction that reaches them. That is a real protection, but the hole is still open.
What to actually take from the Morse code story
The specific mistake, an NFT transfer silently raising a permission tier, is unusual. Its shape is common: a system where being persuaded and being able to act are the same event.
Injection you cannot prevent. Expressiveness you can remove.
If you are evaluating any agent that touches money, that is the question worth asking, and it is answerable without trusting anybody’s security page. Ask what the agent is able to write down. If the answer includes an address, every other control is a filter standing between a persuadable model and your funds, and filters are evaluated against the attacks somebody already thought of.
Ours does not include an address. We would still rather you assumed we had missed something, because on four occasions we had.