How to Secure AI Agents That Hold Crypto Wallets

In early May 2026, someone robbed an AI agent with a Morse-code message.

The agent, Grok, had an auto-provisioned wallet and was wired to a trading bot that could move funds. The attacker did two things. First, they sent the agent a membership NFT that, inside that bot's ecosystem, quietly unlocked elevated transfer permissions. Then they replied to the agent asking it to "translate" a Morse-code string. Decoded, the message was a financial instruction: send about 3 billion DRB tokens to this address. The agent decoded it, the bot executed it, and roughly 150,000 to 200,000 dollars in tokens left the wallet on the Base network. Most was later returned after the community unmasked the attacker, but the lesson stuck.

Here is the uncomfortable part: teaching the model to distrust Morse code would not have saved it. The next attack is base64, or a QR code, or a sentence hidden in a token's metadata. You cannot patch this at the model. You have to contain it.

Why you cannot just prevent this

An AI model reads its instructions, the user's request, and any content it retrieves as one undifferentiated stream of text. There is no reliable way, inside that stream, to mark some words as trusted commands and others as untrusted data. So an instruction buried in a web page or a token's metadata can be executed as if you had typed it yourself. This is prompt injection, and it is not a bug with a patch. Even OpenAI has said it is unlikely to ever be fully solved.

The researcher Simon Willison calls the danger the lethal trifecta: an agent is a liability when it combines three things, access to something valuable, exposure to untrusted content, and the ability to act in the world. A wallet-holding agent that reads token metadata and can sign transactions has all three. And on-chain, "act" means an irreversible transfer. A single landed injection is not a wrong answer. It is a completed theft.

There is a scarier variant. Researchers at UC Santa Barbara tested hundreds of the LLM API routers that sit between agents and models, and found some silently rewrote the agent's tool calls and even drained a researcher's own test wallet. The attacker never touched your prompt or your wallet directly. They sat in the plumbing. Which means your containment has to assume even the model's transport is hostile.

The shift that fixes it: contain, do not prevent

The 2026 consensus among people who actually secure these systems is blunt: assume some injections will land, and make sure a landed injection cannot do much. Or as one security team put it, the prompt injection problem is not solvable, but the permissions problem is. You stop bounding the model's behavior and start bounding its blast radius.

Concretely, that means the wallet, not the prompt, is where the rules live.

The containment toolkit

Stack these. Each one shrinks what a hijacked agent can do:

• Least privilege. An agent that cannot call a transfer tool cannot be injected into a transfer. Scope every tool to the minimum. The Grok drain happened because a permission could be escalated at runtime and nothing re-checked it.
• On-chain spend caps. Per-transaction and per-period value ceilings enforced by the wallet, so an injection can move at most the capped amount.
• Destination allow-lists. Transfers only to pre-approved addresses. A drain to an attacker's fresh wallet is rejected by the signer, whatever the model "decided."
• Session keys. Short-lived, narrowly scoped sub-keys, valid for an hour, one contract, a tiny cap. Compromise is bounded in time and scope.
• Human in the loop. Require explicit human approval for large or irreversible transfers. Ledger frames the model well: agents propose, humans sign, hardware enforces, with the real transaction shown on a device so an injection cannot spoof what the human approves.
• MPC wallets. The private key is never assembled in one place, and signing passes through a policy service that checks the transaction against rules before any signature exists.
• Transaction simulation. Dry-run the transaction and check its real effect, who receives what, against policy before you sign. Catches innocent-looking calls that actually drain a balance.
• Isolation. Keep the agent that holds tools away from raw untrusted content. One planner with tools that never reads the open web, one reader that processes untrusted text but holds no keys.

Account abstraction: the trusted kernel

The most important idea is that you can put these rules on-chain, where no prompt can talk its way past them. This is what account abstraction gives you.

With ERC-4337 and EIP-7702, which is live on Ethereum mainnet since the Pectra upgrade, a wallet becomes programmable. Spending limits, allowed-contract lists, and session-key expiries are enforced by the account's own validation logic at signing time. EIP-7702 even lets an ordinary wallet temporarily gain these powers without moving funds to a new address. The effect is profound: even a completely hijacked agent can only produce transactions the smart account will actually accept. The security guarantee is written in Solidity and checked by the chain, not dependent on any claim that the model is robust.

The correct mental model, and the one we build to: the language model is untrusted middleware. The smart account is the trusted kernel.

How we build this

This is exactly the thinking behind DCP, our agentic security product, and how we approach wallet infrastructure and agentic payments: least privilege, hard on-chain limits, and human approval for anything irreversible, all enforced below the model. It is the same least-privilege discipline we cover for agents in general in AI agent security, applied where the stakes are highest, because a payment tool is the one tool where a single mistake is final.

If you are giving an agent a wallet, the wallet is where the security has to live. Talk to us before it holds real money.

References

• Giskard, how Grok got prompt injected: the Morse-code drain, with the permission-escalation detail.
• CoinDesk, a hidden flaw could expose wallets: the malicious LLM router research.
• Simon Willison, the lethal trifecta: why access, untrusted input, and the ability to act is a dangerous combination.
• EIP-7702 on Ethereum mainnet (Pectra): programmable accounts and session keys, live on mainnet.