Prompt Injection: The Drain Your AI Agent Signs
Nobody hacked the key. Somebody talked to the keyholder.
The modern crypto wallet has an intern. It reads your Telegram, watches your positions, rebalances at three in the morning and never asks for a raise. It also does exactly what it is told, by anyone who can get words in front of it. That is prompt injection: hiding an instruction inside content the agent reads — a token description, a forum reply, a webpage, a tool listing — so the model treats an attacker's sentence as your order.
Researchers at Princeton demonstrated it against ElizaOS, the open-source framework a lot of on-chain agents are forked from, by poisoning the agent's memory so later, unrelated sessions routed transfers to an address the operator never chose. The Freysa experiment showed the softer version in public, when a carefully written message convinced an agent to release a prize pool of about $47,000 that its own rules said it must never release. No exploit, no zero-day, no leaked seed. A conversation, with a signature at the end of it.
What Makes This Different
Every drain we normally document ends with a human clicking confirm. Here the human is asleep. The agent holds a key, or a session key, or an approval broad enough to act, and the attacker's job is not to break cryptography but to write a convincing sentence in a place the agent will read. The model cannot reliably tell your instruction from the text it is processing, because to a language model both arrive as the same thing: words in the context window.
You gave the intern the safe combination. Somebody left a note in the inbox signed with your name.
A Very Polite Robbery
The first sign is usually a transaction you cannot place. Correct format, correct gas, correct signer — your agent's signer — and a destination nobody on the team recognises. The logs show the agent decided to send it. The logs are honest.
Trace it backwards and the trigger is embarrassing. A token whose on-chain description contains a line addressed to the model. A pull request comment. A support ticket. A tool description in an MCP server the agent connected to that morning. The attack surface of an AI agent is every piece of text it is allowed to read.
In the Princeton work the payload did not even need to fire immediately. It sat in the agent's persistent memory, survived the session, and steered later transfers — which is why an operator reviewing the day's prompts finds nothing wrong. The instruction was accepted last week.
Traditional malware needs to run on your machine. This one only needs to be quoted.
Why The Model Cannot Tell The Difference
A language model does not have a privileged channel. Your system prompt, the user's message and the untrusted webpage the agent just scraped all land in the same context window as text. Priority is a suggestion written in that same text, and suggestions can be outranked by a more forceful sentence further down.
OWASP lists prompt injection as LLM01 — the first risk on the list — precisely because there is no general fix. Filters catch known phrasings. Attackers write new ones, in base64, in a foreign language, in a token symbol, inside a comment in a JSON blob the agent parses. NIST's adversarial ML taxonomy says the same thing in colder language: this is an open problem, not a patch note.
Now attach a wallet. The moment an agent can call a signing function, every text-handling weakness becomes a payments weakness. The bug is not that the model got confused. The bug is that a confused model was allowed to spend money.
We built software that follows instructions, then handed it the keys and acted surprised when it followed instructions.
Vocabulary Decoded
Five terms. Learn them now, or learn them from a block explorer later.
Prompt injection
What it sounds like:
A jailbreak trick for making chatbots say rude things.
What it actually is:
Command execution through content. If the agent reads it, the agent may obey it. When the agent also holds a key, obedience becomes a transfer. OWASP ranks it as the number one risk in LLM applications for a reason.
Indirect injection
What it sounds like:
A more complicated version of the same thing.
What it actually is:
The attacker never talks to your agent. He plants the sentence where your agent goes looking — a token's metadata, a scraped article, a GitHub issue, an RSS feed. He does not need your attention. He needs your agent's reading list.
Memory poisoning
What it sounds like:
Corrupted data in a database somewhere.
What it actually is:
An instruction written into the agent's long-term memory so it applies to sessions that have not happened yet. The Princeton ElizaOS paper showed the payload persisting across contexts and platforms, quietly redirecting later transfers.
Tool poisoning (MCP)
What it sounds like:
A broken plugin.
What it actually is:
A malicious instruction hidden in the description of a tool the agent can call. The user sees a friendly tool name in the UI; the model sees a paragraph telling it to exfiltrate keys or reroute a payment. Invariant Labs documented this against real MCP servers.
Session key
What it sounds like:
A temporary login for convenience.
What it actually is:
A standing permission to act without you. Scoped correctly it is a seatbelt. Scoped lazily — any contract, any amount, no expiry — it is the whole wallet with extra steps.
None of these are exotic. All of them are cheap, and all of them work while you sleep.
How The Attack Runs
Five stages. Only the last one shows up on a chart.
Stage 1: Find what the agent reads
Public agents advertise their own plumbing. Which chains, which feeds, which Discord, which tools, which framework. Half of them are forks of the same open-source repository with the config left in the README.
Reconnaissance here is reading documentation the team published on purpose.
Stage 2: Write the sentence
The payload is short and imperative, formatted to look like system text: an updated treasury address, a mandatory compliance step, an urgent operator override. Politeness is optional. Confidence is not.
It is social engineering, except the target has no colleague to double-check with.
Stage 3: Plant it where it will be read
Token name and description fields. A reply in a monitored channel. A page the agent summarises. A tool description on an MCP server the team added for convenience. Anywhere text enters the context window.
The cheapest vector in this list costs one on-chain token deployment.
Stage 4: Wait for authority
The instruction sits until the agent has a reason to act — a rebalance, a payout, a bridge, a scheduled transfer. In memory-poisoning cases it persists across sessions, so the trigger can be days after the plant.
The delay is the point. It separates the cause from the effect in every log you will read.
Stage 5: The agent signs
Funds move with a valid signature from a key the team controls, through infrastructure the team approved, in a transaction that will never be reversed because nothing about it was invalid.
No alarm fires, because from the chain's point of view the owner just paid someone.
The Timeline: How We Got Here
Documented milestones, in order.
2022–2023: prompt injection gets a name, then a rank
Simon Willison names the class in September 2022; researchers then demonstrate direct and indirect injection against LLM applications. OWASP places it at LLM01, the top entry of its Top 10 for LLM Applications, and states plainly that no complete mitigation exists.
The industry response was mostly to add more text telling the model to ignore text.
November 2024: Freysa pays out
An experimental agent is given a prize pool and one rule — never release the funds. After 481 failed paid attempts from 195 participants, message number 482 reframes the release function as an incoming deposit and the agent transfers $47,316 in ETH to the winner.
A game, with real money, that priced the exact cost of talking a machine out of its own policy.
2025: agents get wallets at scale
Open-source frameworks put trading, treasury and social agents on-chain by the thousand. Most run on forks, most hold hot keys, and the fastest way to ship is to give the agent broad approvals and worry later.
Every fork inherits the parent's threat model, including the parts nobody read.
March 2025: memory poisoning is demonstrated on ElizaOS
Princeton researchers publish plug-and-play attacks that write false context into an ElizaOS agent's persistent memory, causing unauthorised crypto transfers in later sessions. Prompt-level defences do not stop it, because the payload is no longer in the prompt.
Auditing the prompt is like reading today's newspaper to find out what the intern agreed to last week.
2025 to 2026: the tool layer joins in
As agents standardise on MCP for external tools, Invariant Labs shows that tool descriptions themselves are executable text. A connector can be benign on install and hostile after an update the operator never reviews.
Supply-chain risk, except the payload is a paragraph of English and nothing recompiles.
Three years of warnings, one direction of travel: more autonomy, same context window, bigger balances.
Signals Worth Acting On
- An agent with an unlimited approval or a hot keyIf the answer to 'what is the maximum this agent can move' is 'everything', the model's reliability is now your custody model.
- Tokens whose name or description contains sentencesMetadata is for humans and indexers. A paragraph of imperative English in a token field is aimed at something that reads for a living.
- New tools or connectors added without reviewRead the tool description, not the tool name. That description is the part your model actually obeys.
- Persistent memory with no expiry and no auditIf you cannot list what your agent believes and when it learned it, you cannot tell whether it was taught.
- Transfers that only the agent can explainAny outgoing transaction with no matching human decision is an incident until proven otherwise, even when the amount is small.
The pattern is never carelessness. It is a sensible convenience granted once and never revisited.
The Numbers
What is publicly documented, without the speculation.
LLM01 — first place on the OWASP list
Prompt injection is ranked the top risk for LLM applications, with mitigation described as partial rather than complete.
~$47,000 released by conversation alone
The Freysa agent transferred its prize pool after a crafted message reframed its own hard rule. No code was exploited.
Persistence across sessions and platforms
The ElizaOS study showed injected memories surviving context resets and steering later, unrelated transfers.
One deployment to reach thousands of agents
A single poisoned token or tool description is read by every agent that indexes it, which is what makes this cheap at scale.
The Second Act: Who Pays When The Robot Decides
The interesting question is not technical. It is that a valid signature from your own key is, legally and practically, your transaction.
The chain sees an owner
There is no field for 'the model was misled'. Settlement is final, the signature verifies, and the counterparty is under no obligation to care about your architecture.
The exchange sees a customer
If funds reach a centralised venue quickly, a report with hashes can help. Once they are split and bridged, the practical route closes in hours, not days.
The insurer sees a config
Coverage for agent-initiated loss is immature. Where it exists, it asks about scoped keys, spend limits and human approval gates — the controls most teams skipped to ship faster.
Treat an autonomous signer as an employee with a company card: a limit, a category, a second approver above a threshold, and a monthly statement somebody actually reads.
Autonomy is a feature you buy with liability. Very few teams read that invoice before signing.
Why Competent Teams Still Get Hit
None of the usual mistakes are required here, which is the uncomfortable part.
The confirmation screen is gone
Every habit that protects a human — read the address, check the amount, sleep on it — assumes a human is present. Autonomy removed the reviewer, not the risk.
The perimeter is unbounded
You can enumerate the ports on a server. You cannot enumerate every sentence your agent might read tomorrow.
Frameworks ship with trust turned on
Defaults favour capability: broad tool access, persistent memory, hot keys. Every one of those is a reasonable demo setting and a poor production one.
Audits check contracts, not context
A perfect smart contract will happily execute a transfer that a poisoned model requested. The flaw lives between the two, where nobody's scope ends up.
The lesson is not that agents are bad. It is that an agent is a signer, and signers get governed — with limits, allowlists and a human on anything that hurts.
What To Actually Do
In order of how much it helps.
- Never give an agent an unlimited key. Use a scoped session key or a dedicated wallet with a working balance. The blast radius should be a bad day, not a bad year.
- Put a human gate on value. Above a threshold, above a new destination, above a new contract — the agent proposes and a person signs. Slow is a feature at that size.
- Allowlist destinations and contracts. An agent that can only pay addresses you pre-approved cannot be talked into paying one you did not, no matter how good the sentence is.
- Treat everything the agent reads as untrusted input. Token metadata, scraped pages, DMs, tool descriptions. Strip, quote and label external content so it never arrives dressed as an instruction.
- Audit and expire memory. Log what the agent stores, review what it believes, and let long-term memory age out. A belief nobody can trace is a liability nobody can revoke.
Checks Worth Running This Week
None of these take long, and all of them are skipped.
List every key your agents can use
Where it lives, what it can sign, what the ceiling is. If the answer requires a meeting, that is the finding.
Read your MCP tool descriptions
Open the raw JSON, not the pretty UI. Look for instructions aimed at the model rather than at the developer.
Revoke stale approvals
Revoke.cash or your explorer's approval tab, on every chain the agent has ever touched. Unlimited and unrecognised are the two words that matter.
Dry-run a red-team prompt
Plant a harmless override in a source your agent reads and see whether it complies. Better your sentence than someone else's.
Alert on any outgoing transfer
One notification per agent-initiated payment. It will not stop the first one; it decides whether there is a second.
An autonomous wallet is a staffing decision. Most teams hired it and skipped the onboarding.
AI Agent Wallet Safety Checklist
Worth keeping next to the deploy script, not in a bookmark you never open.
Give agents scoped session keys, never the main wallet or an unlimited approval.
Set a hard per-transaction and per-day spend ceiling in code, not in the prompt.
Allowlist every destination address and contract the agent may touch.
Require human approval above a value threshold or for any new destination.
Label and sandbox all external text so it can never read as a system instruction.
Review MCP tool descriptions on install and after every update.
Log, audit and expire long-term memory; alert when the agent stores a new directive.
Alert on every agent-initiated outgoing transfer, regardless of size.
Got a Suspicious Message?
Use our AI-powered detector to analyze potential scams instantly.
Key Takeaways
- 1Prompt injection is command execution through content, and OWASP ranks it as the top risk in LLM applications with no complete fix available.
- 2When an agent holds a key, a text-handling weakness becomes a payments weakness — the signature is valid and the transfer is final.
- 3Indirect injection needs no contact with you: a token description, a scraped page or a tool listing is enough.
- 4Memory poisoning demonstrated on ElizaOS persists across sessions, so prompt-level review will not find it.
- 5Freysa showed the public version: roughly $47,000 released by conversation, against the agent's own explicit rule.
- 6The defences that work are boring and structural: scoped keys, spend ceilings, destination allowlists, human gates on value, audited memory.
The intern signed. Nobody asked you.
Frequently Asked Questions
Sources & Citations
Research for this investigation compiled from publicly available blockchain data, security reports, and community documentation.
genai.owasp.org
modelcontextprotocol.io
revoke.cash
Verification: All blockchain transactions and addresses referenced in this article can be independently verified through the linked blockchain explorers. We encourage readers to conduct their own verification.
Methodology: Every case requires at least three independent sources plus verifiable on-chain evidence before publication. Full standards: /methodology
Legal notice: This assessment is based on publicly available data, including on-chain records, official statements and reported incidents. It is journalistic and educational analysis, not legal advice, an accusation of criminal conduct or a court finding. Named companies, projects, domains, wallets and individuals are described as reported by the cited sources; a company name may appear because fraudsters impersonated it, not because the company did anything wrong. If you believe something is inaccurate or out of date, write to cryptostrapon@proton.me and we will correct it and log the change. Editorial policy