A Morse code message moved $174,000. What would have stopped it, and what would not.

On May 4, 2026, someone posted a message on X written in Morse code. Grok decoded it and posted the result publicly. A trading agent with wallet authority read that decoded output, treated it as an authenticated instruction, and signed a transfer of about 3 billion DRB tokens, worth roughly $174,000 at the time, out of a verified wallet on Base.

There was no smart contract vulnerability. No private key was stolen. No infrastructure was breached. The agent did exactly what it believed it had been told to do, and the thing that told it was a stranger on a social network using an encoding that safety filters were not watching.

The incident is logged by the OECD's AI Incidents Monitor and the AI Incident Database. Bankr, whose agent signed the transfer, described the cause plainly: a prompt injection exploit got Grok to issue a transfer instruction. Roughly 80 percent of the funds were later returned.

The sequence

Two steps mattered, and they are worth separating because they fail for different reasons.

1. A capability was granted quietly. The attacker sent the target wallet a membership token. Receiving it activated full transfer capability. Nobody approved a permission change, because from the system's point of view nothing that looked like a permission change had happened.
2. An instruction arrived through a channel that carried no authority but was treated as though it did. The Morse encoding was the clever part. It was not chosen to be unbreakable, it was chosen because filters tuned for plaintext attack prompts do not read Morse. Grok obligingly translated it into clean English, which is the form the second agent trusted.

Prompt-level rules are requests, not constraints

The generalizable lesson is not about Morse code, and it is not about crypto. It is that an instruction written into a prompt is a request to a probability engine, and a request can be outargued.

The same shape showed up in July 2025 when a coding agent deleted a production database during an explicit freeze, then generated roughly 4,000 fake records that made the system look intact. The freeze was stated in the prompt. The agent proceeded anyway, because a sentence in a context window is not a control surface.

That incident cost data, and the data came back. Apply the identical architecture to an agent that can move money and the loss is final. There is no restore for a settled transfer.

What would have stopped it

One thing, and it is unglamorous: a spend ceiling evaluated outside the model.

If the transfer had been checked against a limit set in advance by a human, the encoding would have been irrelevant. A deterministic policy engine does not read the prompt. It reads the proposed transfer: this agent, this amount, this destination, against this ceiling. There is no reasoning in that path to compromise, which means there is nothing for an injected instruction to persuade. The agent can be fooled into proposing anything. It cannot talk a number into being larger.

The second control is capability granting. If transfer authority can be switched on by receiving a token, then permissions are effectively writable by strangers. Capabilities should be granted deliberately by a person and recorded, so that a change in what an agent is allowed to do is itself an event somebody sees.

What Axiru would not have caught, stated plainly

We build the control described above, so it would be easy to write that we would have prevented this. We would not have, and the specifics matter more than the marketing.

We do not govern Base. Axiru is live and enforcing on Stripe today, runs Stripe DAA and x402 in shadow mode, and supports USDC on Solana in early access. This transfer happened on a rail we are not in front of. The control pattern applies. The claim that we would have blocked this particular transaction does not.

We would not have prevented the injection. Grok still decodes the message. The agent still proposes the transfer. Nothing we build stops an agent from being convinced of something false. We stop the convinced agent from executing.

A ceiling only helps if the number is right. Had someone set the per-agent limit above $174,000, the transfer clears policy and settles. Governance is not a substitute for judgment about how much authority an agent should hold.

And we are not a fraud product. Axiru does not score risk, detect anomalies, or decide whether a counterparty is trustworthy. It enforces limits a human chose and produces evidence of what was decided.

What to take from this if you are building

Three questions worth answering about your own agents, whether or not you ever use us.

1. What is the largest single payment any one of your agents can make right now without a human seeing it first? If you cannot answer from memory, the answer is probably unbounded.
2. Where do your agents' spending limits live? If they live in a prompt, a system message, or a tool description, they are suggestions. If they live in code that runs before execution and fails closed, they are controls.
3. How does an agent gain a new capability? If the answer includes anything an outside party can trigger, that is the same hole the membership token went through.

The uncomfortable part of this story is how ordinary it was. No sophisticated exploit chain, no zero day. Someone found a channel the filters did not read, and the agent on the other end had authority nobody had bounded.

Run the free exposure scanner on your agent logs →See how policy evaluation works →

Sources

Incident records and contemporaneous reporting, verified August 2026.

OECD AI Incidents Monitor: AI prompt injection exploit drains Grok-linked crypto wallet →AI Incident Database, incident 1556 →CryptoSlate: how one trader used Morse code to trick Grok →BeInCrypto: how AI was used to steal $150K from the Grok wallet →