In May, an X user posted a message in Morse code, asked an AI to translate it, and walked away with six figures from a wallet he didn't own.
The mechanics, as reported by CCN and Giskard, were almost embarrassingly simple. The attacker put "drain the wallet" into Morse code and asked Grok to decode it in public. The Bankr trading bot wired to that account treated the decoded text as an instruction and complied. Reports put the losses between $150,000 and $200,000, and the incident now sits in the OECD AI incident registry.
The write-ups that followed mostly reached the same conclusion: better filters. Detect exotic encodings. Sandbox translations. Scan tool descriptions for injected instructions. All of that is useful. None of it is the point.
Agents will always be trickable
The attack surface of an LLM agent is language itself. Every message it reads - a tweet, a tool description, a document it was asked to summarize - is a potential instruction, and the set of ways to smuggle an instruction past a filter is unbounded. Morse code worked in May. Base64 has worked. Unicode confusables have worked. Whatever the scanners catch next quarter, the quarter after that produces something they don't.
This is an arms race with a structural asymmetry: the attacker needs one encoding that slips through; the defender needs to anticipate all of them. Arms races like that are worth running - you should absolutely filter - but you should not build a financial system whose safety depends on winning one.
The real vulnerability was standing credentials
Ask a different question about the May incident: not "how was the agent fooled" but "why could decoded text move money at all?"
Because the agent held live credentials with standing spending power. A hot wallet it could sign from without limits. In other setups it's an exchange API key with withdrawal rights, or a custodial account the agent operates end to end. In every one of those designs, each message the agent reads is one social-engineering step away from everything the agent holds. Compromise the reasoning, inherit the account.
That's the number that should worry you. Not can my agent be fooled - yes, it can, and so can its successor. The number is what a fooled agent forfeits. Call it the blast radius.
Most agent-trading setups today have a blast radius of "the entire balance." That is a choice, not a law of nature.
Shrinking the blast radius is a settlement problem
Here is the structural alternative. Instead of giving the agent an account it can spend from, give it a primitive where money is locked to a cryptographic condition: a hash-time-locked contract (HTLC). The agent's funds move into a contract that will release them to the counterparty only when the counterparty's asset has verifiably arrived - the same secret that claims one leg unlocks the other. If the trade doesn't complete inside a fixed window, both sides are refunded automatically. Both legs clear, or neither does.
Now replay the Morse-code attack against that design. The attacker fully compromises the agent mid-trade. What can the injected instruction actually reach? Not the account - there isn't one. Not the counterparty's leg - it's locked to the same condition. The worst realistic outcome is that a trade in flight fails to complete and unwinds to a refund. There is no standing pool of credentials to drain, because each trade is its own locked box with its own expiry.
PayPal made it safe to pay strangers online by absorbing fraud risk onto its own balance sheet. The equivalent for autonomous agents is not a smarter fraud model - it's settlement where fraud has nothing to grab. Your money never leaves your wallet until theirs arrives.
What atomic settlement does not fix
Honesty section, because this design is not magic:
A compromised agent can still be talked into initiating a valid-but-dumb trade - wrong price, wrong counterparty, wrong size. Atomic settlement bounds the loss to that one trade, and the surrounding machinery narrows it further (sealed-bid RFQ price discovery makes "trade at an absurd price with my accomplice" harder; counterparty verification and per-trade size caps shrink it again) - but bounded is not zero. Judgment risk survives.
Capital lockup and timeout risk are real trade-offs. Funds committed to a trade are unavailable until it completes or refunds, and timeout windows have to be chosen carefully - the two legs can't expire symmetrically or the party revealing the secret can be front-run.
And if the attacker steals the agent's signing key rather than injecting a prompt, that's a different layer of the stack - key custody and policy signers - which no settlement design substitutes for.
Where this runs today
Everything above is live end to end on Ethereum mainnet through six MCP tools - RFQ creation and response, HTLC lock, withdraw, refund, and status - published as the scoped npm package hashlock-tech/mcp. Any MCP-capable model can drive the full lifecycle from the agent's own wallet. Sui contracts are deployed and CLI-tested with gateway wiring in progress, and the Bitcoin flow is validated on signet with mainnet pending - so today, "live" means Ethereum. The V1 contracts are immutable and went through a five-layer verification pipeline (Slither, Halmos symbolic execution, Echidna fuzzing, Stryker mutation testing, plus runtime invariant monitoring). The protocol design is written up in an SSRN paper if you want the formal treatment.
Docs and the live protocol are at hashlock.markets; the MCP server source is on GitHub.
The audit worth running this week
List every credential your agent holds. Next to each one, write down the maximum a single malicious message could move through it. If any line on that list says "everything," that line is your real security roadmap - ahead of the next filter update, ahead of the next model upgrade.
What did your list say? I'm genuinely curious how people are bounding this today - spend caps, policy signers, per-session wallets, something else? Comments open.
Top comments (0)