What is prompt injection, and how can it drain an agent's wallet?

What exactly is prompt injection?

Prompt injection is any input that gets an AI model to treat attacker-written text as a command. An AI model reads everything as one stream of text, so it has no reliable built-in way to tell “instructions from my owner” apart from “words that happen to be in this email”.

The US National Institute of Standards and Technology (NIST) separates two forms:

• Direct prompt injection comes from the person typing to the model, for example a user trying to talk a chatbot past its rules.
• Indirect prompt injection arrives through content the model is given to work on, such as a web page, a file, a social media post or another agent’s reply. NIST’s glossary describes it as injection through control of a resource rather than through the user’s own input (NIST’s definition of indirect prompt injection).

NIST’s AI security team calls the agent version “agent hijacking”: hidden instructions in something the agent processes lead it to take harmful actions it was never asked to take (NIST’s technical blog on agent hijacking evaluations).

For a chatbot, a successful injection usually means a bad answer. For an agent with a wallet, it can mean a signed transaction that cannot be reversed.

How does hidden text become a transaction?

Hidden text becomes a transaction when an agent that reads untrusted content also holds the permission to move money without a separate check. The chain usually has five links:

1. The plant. The attacker puts text where the agent will read it: a post, a reply, a web page, a token description, a document.
2. The read. The agent pulls that text into its working context while doing its normal job.
3. The confusion. The model treats part of the text as an instruction rather than as data.
4. The tool call. The agent calls its payment or trading tool with the attacker’s address and amount.
5. The signature. The wallet signs, because the request came from the agent it trusts.

Breaking any one link stops the attack. In our view, the most dependable defences sit at links 4 and 5, because links 2 and 3 are the hardest to control.

What has this looked like in real incidents?

Three widely reported cases show three different routes to the same outcome: an agent moving money its owner never meant to move.

The encoded message (May 2026). An attacker posted a message written in Morse code and asked a widely used AI chatbot on a large social network to translate it. The translation, posted publicly by the chatbot, read as a payment command addressed to an AI trading assistant that watched the chatbot’s posts for instructions. Reports say the attacker had first sent a membership NFT (a token acting as a pass) to the chatbot’s linked wallet, which reportedly unlocked transfer permissions. About 3 billion tokens, valued at roughly $150,000 to $200,000, were moved and sold. Coverage described this as prompt injection, not a smart contract flaw. Some reports, not officially confirmed at the time, said a large share of the funds was later returned.

Neither system was “broken” in the usual sense. One agent produced text, and another agent treated that text as an authorised order.

The follow-up (May 2026). A little over two weeks later, the same trading assistant service said an attacker had accessed 14 user wallets. A security researcher estimated that the attacker’s addresses held about $440,000. The cause had not been established at the time of reporting; security researchers offered competing explanations. The service paused transfers and said it would reimburse lost funds.

The control panel (March 2025). An attacker got into the dashboard of a well-known AI agent that posts crypto market commentary. From there, they queued two fraudulent prompts telling the agent to send 55.5 units of the Ethereum network’s native currency, worth about $106,200. The team said the AI itself had not been manipulated and core systems were not affected. Strictly, this was account takeover, not injection, but the lesson overlaps: whoever can put words in front of the agent controls its wallet.

Why can’t developers just fix it?

Because there is no known complete defence, and the evidence so far says determined attackers can often find a way in. NIST’s early agent-hijacking tests found that new attacks designed by red teams raised success from 11% for the strongest baseline attack to 81%. Across five test tasks, letting an attacker retry each attack 25 times raised the average success rate from 57% to 80%.

In March 2026, NIST’s AI standards centre reported on a large public red-teaming competition, analysed with the UK AI Security Institute and other partners. More than 400 participants made more than 250,000 attack attempts against 13 frontier AI models in agent settings. At least one successful attack was found against every one of them (NIST’s write-up of the agent security red-teaming competition).

That does not mean every agent is easy to break. It means a model’s resistance is not a safety guarantee. The controls that hold up are the ones that sit outside the model.

What could go wrong?

The biggest risk is an agent that reads public content and can also pay without asking anyone. That combination turns every stranger who can post text into a possible signer of your transactions.

Four patterns from the incidents are worth naming:

• Agents trusting agents. One agent’s output became another agent’s instruction. As agents start paying and instructing each other, each link in the chain inherits the weaknesses of every link before it.
• Disguised text. Encoding, translation and formatting tricks can carry an instruction past filters that look for obvious commands.
• Permissions that change from outside. A token sent to a wallet reportedly upgraded what the agent could do. Anything that can grant permissions without a human is part of the attack surface.
• The prompt box as a key. A compromised dashboard let an attacker type orders directly. Access to the agent’s control panel deserves the same protection as a private key.

Legal and recovery questions follow. Whether victims are repaid depends on who operates the service and what they choose to do; there is no general rule that protects users.

The trust takeaway

Assume any agent that reads the open internet can be talked into something. Then make sure that “something” is capped, logged and, above a threshold, confirmed by a person. In our judgement, an agent is only as safe as the permissions it holds when the model gets fooled.

Before you trust an agent near a wallet, ask:

• What does it read? Public posts, web pages and other agents’ replies are all possible injection routes.
• Can it pay without a human? If yes, what is the cap per transaction and per day?
• Are destination addresses allow-listed? An agent that can only pay known addresses is much harder to drain.
• Can anything outside change its permissions? Tokens, passes or messages should never unlock new powers on their own.
• Who can reach the control panel? Ask how dashboard and prompt access are secured.
• Is every action logged? You need a record of what it read and why it acted.