What Happens When an AI Agent Gets Hacked?

Key Takeaways

• When an AI agent hacked by prompt injection moves funds, every signature is valid. There is no contract bug and no stolen key, which is exactly what makes it hard to reverse.
• On 4 May 2026 an attacker posted a Morse code reply on X. One agent decoded it, a second treated the decoded text as an authenticated command, and roughly 150,000 to 200,000 dollars in tokens left the wallet on Base.
• Neither agent misbehaved. The failure sat in the gap between them, where decoded attacker text inherited the trust of a peer.
• An NFT sent to the wallet beforehand had granted elevated permissions, bypassing standard transfer limits. An unsolicited inbound asset changed what the agent was allowed to do.
• This is theft, not a contract dispute, and the distinction decides who can realistically recover anything.

What happens when an AI agent gets hacked? Usually nothing that looks like a hack. An AI agent hacked through prompt injection produces perfectly valid, correctly signed transactions. No cryptography is broken and no smart contract is exploited. The agent is persuaded to do something its owner never authorised, and the chain records it as an ordinary transfer.

An AI agent hacked this way is a different problem from the one the industry spent a decade learning to defend against, and most of the security instincts built for exploits do not transfer.

The case that shows exactly how an AI agent hacked in the wild actually fails

On 4 May 2026 an incident was logged in the OECD AI Incidents Monitor involving two agents operating on the Base network. The mechanism is worth walking through slowly, because every step is individually reasonable.

The sequence that produced an AI agent hacked in the wild began mundanely. An attacker sent a reply on X containing a message in Morse code. The first agent, a general assistant, was effectively asked to translate it. Translating an encoded string is a harmless request, and its safety layer treated it as such. It decoded the message faithfully. That decoded output contained financial instructions.

A second agent, one with transaction capability, received that output and treated it as a valid, authenticated command. It executed the transfer. Approximately three billion DRB tokens, valued between 150,000 and 200,000 dollars, left the wallet.

There is a further detail that deserves more attention than it has received. An NFT sent to the wallet beforehand had granted the agent elevated permissions within the transacting service, allowing it to bypass standard transfer limits and swap restrictions. The escalation arrived as an unsolicited inbound asset.

Nobody was compromised, which is the whole problem

Look for the compromised component in an AI agent hacked this way and you will not find one. The first agent was asked to decode a string and decoded it. That is its job, and refusing would make it useless. The second agent received a clearly formed instruction from a system it had reason to trust, and acted on it. That is also its job.

In an AI agent hacked across a peer boundary, the vulnerability lives in the handoff. Text authored by an attacker passed through a decoding step and emerged carrying the authority of a trusted peer rather than the suspicion due to a stranger. Nothing in either system owned that boundary.

This is why an AI agent hacked this way is not fixed by a better model. OWASP catalogues prompt injection as LLM01, the first entry in its Top 10 for large language model applications, and pairs it with LLM08, Excessive Agency, which warns that granting unchecked autonomy to act leads to unintended consequences. The second risk is what converts the first into a loss. A model that can be talked into saying something is an inconvenience. A model that can be talked into signing something is a treasury problem.

Note also that obfuscation defeated the safety layer without defeating the model. The encoding was not a jailbreak. It simply meant the harmful content was not present at the moment the safety check ran, and was present afterwards. Any pipeline that inspects input before a transformation and not after has the same hole.

Why this is theft rather than a contract dispute

We set out in whether an AI agent can legally own a crypto wallet that liability for an agent’s transactions routes back to a human principal, and that the statutory test is whether the action was legally attributable to the person to be bound. Agency doctrine handles the ordinary case: the deployer authorised the agent, so the deployer is bound even by transactions it did not foresee.

An AI agent hacked by a third party breaks that framing. A third party induced the instruction. The principal did not authorise this transfer in any meaningful sense, and the counterparty is not an innocent merchant but the attacker. That is not a dispute about the scope of authority. It is theft executed through a valid signature.

The practical consequence for anyone whose AI agent hacked their own treasury is bleak. In a contract dispute there is a counterparty to sue and a court that can unwind a transaction. In a theft settled on-chain there is an address, a finalised transfer, and whatever cooperation a centralised venue chooses to offer if the funds ever reach one. Our analysis of the 2026 exploit record covers how rarely signature-valid losses come back.

What actually contains an AI agent hacked mid-conversation

Read that list against a real AI agent hacked incident and the pattern is hard to miss. The only control that addresses the model is the one that would not have helped, because the model did what it was supposed to do. Everything that would have held is a constraint on what a signature is permitted to authorise.

This is the argument we made in what an agentic wallet actually is, tested against a real loss. In the threshold model, policy is enforced inside the signing ceremony: a co-signer simply does not participate in a transaction that breaches a cap or sends to an address outside the allowlist, and an unsigned transaction is not a transaction. In the smart-account model, a session key scoped to specific targets and value limits would have rejected the call on-chain.

In this AI agent hacked case the failure was neither. Limits existed at the application layer and were escalated away by a permission the agent had been granted through an inbound NFT. A limit that a received asset can raise is not a limit.

There is a design principle in this that generalises: distrust decoded content. Anything that emerges from a transformation — decoded, translated, summarised, retrieved — should carry the trust level of its origin, not of the component that produced it. Most agent stacks currently do the opposite.

Why This Matters

The agent security conversation is aimed almost entirely at model behaviour: better alignment, better refusals, better jailbreak resistance. This incident says that is the wrong budget line. An AI agent hacked through a peer handoff had no jailbreak in it at all.

What contained the AI agent hacked loss, or failed to, was custody architecture. That reframes the security question from “can our model be tricked” — the answer is yes, permanently, for every model — to “what is the worst thing a fully tricked agent can execute before something refuses to sign.” The first question has no achievable end state. The second is an engineering specification you can write down and test.

There is a second-order consequence for multi-agent systems specifically. Every agent-to-agent connection creates a boundary where content changes hands and trust is implicitly re-granted. Standards work in this area is mostly concerned with letting agents authenticate and pay each other, as we covered in how AI agents pay each other. Very little of it addresses whether an instruction that arrives from a legitimately authenticated peer should be trusted on its content. Authentication answers who sent this. It does not answer who wrote it.

The UAE angle: this is a reportable incident

For a supervised firm in the region, an AI agent hacked into moving client assets is not merely an engineering embarrassment. A licensed entity that suffers a security incident affecting client assets sits inside an incident notification regime, and “our agent was persuaded” is not a category regulators have a comfortable box for.

Our coverage of VARA’s AML screening requirements shows how demanding real-time transaction supervision already is, and the broader mapping sits in what agentic AI regulation in the UAE actually consists of. One point from that piece lands directly here: DIFC Regulation 10 requires a named Autonomous Systems Officer for high-risk processing. After an incident like this, somebody has to explain the decision path to a supervisor. Firms that cannot reconstruct why their agent signed will discover that the audit trail was the compliance control all along. The identity problem we described in why an AI agent cannot open a bank account reappears at the point of recovery, too: the attacker’s address resolves to nobody until it touches a regulated venue.

The limits of this analysis

Several caveats belong on the record. The account of the incident above is drawn from the OECD incident entry and from security write-ups, not from a post-mortem published by the affected services. Reported figures vary between roughly 150,000 and 200,000 dollars, and the precise permission model of the transacting service is described second-hand.

One AI agent hacked is also not a base rate. It shows a mechanism works, not how often it succeeds, and there is no reliable public dataset on how frequently an AI agent hacked by injection results in a loss. Anyone extrapolating a trend from a single case is guessing.

Finally, the controls described here reduce exposure rather than eliminate it. A spend cap bounds a loss; it does not prevent one. An allowlist fails if an attacker can get an address added. The honest position is that autonomous signing authority carries irreducible risk, and the engineering question is how much, not whether.

Frequently Asked Questions

What happens when an AI agent gets hacked?

Typically it signs a valid transaction it was manipulated into approving. No cryptography is broken and no contract is exploited, so the transfer looks ordinary on-chain and is effectively irreversible.

What is prompt injection?

Manipulating a model through crafted input so it follows an attacker’s instructions. OWASP lists it as LLM01, the top risk for large language model applications, and pairs it with LLM08, Excessive Agency.

Has an AI agent actually been hacked for real money?

Yes. On 4 May 2026 an attacker used a Morse code reply on X to induce a transfer of roughly three billion DRB tokens, worth 150,000 to 200,000 dollars, on Base. The incident is catalogued by the OECD.

Is an agent-initiated theft recoverable?

Rarely. The signature is valid and the transfer is final, so recovery depends on the funds reaching a centralised venue willing to freeze them. It is theft rather than a contract dispute, so there is no counterparty to sue.

How do you stop an AI agent being hacked into sending funds?

Constrain what a signature may authorise rather than relying on model behaviour: per-transaction caps enforced at signing, destination allowlists, human confirmation above a threshold, permissions that cannot be escalated by inbound assets, and treating decoded content as untrusted.

By Vaibhav Ali

This article is for informational purposes only and does not constitute financial, investment, or legal advice.

Sources

• OECD AI Incidents Monitor, prompt injection wallet drain, 4 May 2026
• OWASP Top 10 for Large Language Model Applications
• Giskard, technical breakdown of the prompt injection

Related: Can AI agents trade DeFi autonomously, and is it legal? — the four-part test that decides whether your bot needs a licence.

Related: Do AI agents actually need stablecoins? — why the volatility argument is the weakest one, and what UAE rules actually allow.