Guardrails Every AI Agent Wallet Needs Before It Spends

2 minutes ago

9 min read

A model can be talked into anything, so the spending rules belong in the signer

AI agent wallet cover: a policy engine rejects a decoded instruction to send 500 USDC to an address not on the allowlist

The best defense against an AI agent being talked into sending money has little to do with the AI. An AI agent wallet needs 6 guardrails, enforced by the wallet’s policy engine outside the model: an allowlist of recipients, a cap on each payment, a session budget that expires, limits on which networks and tokens it may touch, human approval for anything outside those rules, and a policy the agent cannot edit. Each check runs on the transaction, not on the model’s reasoning, so a clever prompt has nothing to argue with. In May, an attacker used a Morse code message on X to get a Grok-linked wallet to send 3B DRB tokens. Based on our reading of the attack, a fixed recipient allowlist would have refused the transfer without reading the message.

What happened when a wallet took orders from a reply

Bankr is a trading bot on X that creates a linked wallet for accounts it engages with, Grok’s among them. Giskard, an AI security firm, reconstructed the May attack step by step. The attacker began by transferring a Bankr Club Membership NFT into Grok’s wallet, and holding it lifted the wallet into a permission tier that bypassed the usual transfer and swap limits. A reply then asked Grok to decode a message written in Morse code. Grok decoded it faithfully, the decoded text instructed a transfer of 3B DRB tokens, and Bankrbot treated that output as a valid command.

Giskard and AMBCrypto valued the tokens at roughly $150,000 to $180,000 at the time, and both reported that they were sold almost at once. AMBCrypto reported that no smart contract vulnerability was involved; the transfer was a standard ERC-20 transaction. Giskard reported that about 80% of the funds came back after the DRB community identified the attacker.

The pattern predates this year. In November 2024, Freysa, an agent built as a public game, held a prize pool it was told never to release. The Block reported that 195 players sent 482 messages before one convinced it that its approveTransfer function handled incoming payments, then offered a $100 donation. Freysa called the function and paid out a prize The Block valued at about $47,000. Simon Willison, who analyzed the game, pointed out that its system prompt and source code were open for anyone to inspect. Players could read the exact rule they had to argue around.

Princeton-led researchers took the idea further with ElizaOS, an open-source framework for Web3 agents. Their paper showed that a fake memory planted through Discord could redirect transfers the same agent later made on X, because the framework shares one memory store across platforms. Prompt-based defenses stopped basic injections and mostly failed against planted memories. Against the most advanced reasoning model the team tested, memory injection still succeeded 55.1% of the time.

Three agents talked into paying: Freysa after 482 messages, ElizaOS tests at 55.1%, and a Grok-linked wallet sending 3B DRB

In all 3 cases, the last line of defense was a language model deciding whether an instruction was legitimate. Each instruction also arrived in a form the model was built to cooperate with: a translation request, a donation offer, and a remembered conversation.

Why the model cannot be the guardrail

The OWASP Top 10 for LLM applications calls this failure Excessive Agency and traces it to 3 causes: too much functionality, too many permissions, and too much autonomy. For the decision itself, OWASP recommends complete mediation, which means enforcing authorization in the downstream system instead of asking the model whether an action is allowed.

For a wallet, that downstream system is the policy engine standing in front of the signing key. Coinbase’s developer platform lets a team attach policies at the project or account level and checks each signing request against them. Its documentation states that, within a policy, a matching reject rule wins even when an accept rule also matches, regardless of rule order. One difference matters for setup: on Coinbase, an operation with no rules at all is allowed, so every operation the agent should not use needs an explicit reject rule. Privy, a wallet infrastructure provider, defaults to deny when no rule resolves, and its documentation says a trusted execution environment enforces those policies by default.

Where the rule lives decides whether an argument can reach it. A spending rule written into a system prompt is a request the model can be argued out of, as Freysa showed. A rule evaluated against the transaction’s destination, amount, and network runs after the model has finished, and it sees only the transaction.

Newer agent wallet products build on that design. Coinbase launched Agentic Wallets in February with session caps and transaction limits, and Decrypt reported that private keys stay in Coinbase’s secure enclaves, out of reach of the agent and its model. Amazon Bedrock AgentCore payments gives each payment session a budget limit and an expiry time. Its documentation says further payment requests are denied once the budget runs out or the session reaches its expiry time.

Diagram: injected text reaches the model; the policy engine runs 6 checks on the proposed payment before anything is signed

Six AI agent wallet guardrails, in the order we would set them

Start from deny by default, then add only what the agent needs to do its job. On Coinbase, that means writing reject rules for every operation the agent does not need. Most items below point to a control that a wallet or payments provider already documents, so the list describes settings a team can switch on now.

A recipient allowlist. List the seller addresses and contracts the agent may pay, and reject everything else. Coinbase’s policies match destinations with an address criterion, and Privy supports allowlists for both transfer recipients and smart contracts.
A per-payment cap. A data-buying agent paying cents per call has no reason to send $500 in one transaction. Coinbase supports a cap on the native token value and a separate criterion that limits net USD change in cents.
A session budget with an expiry. A cap limits any single payment, while the budget limits the total across 10,000 small ones, and the expiry ends spending once the task window closes, so a forgotten agent cannot keep paying next month. AgentCore’s payment sessions carry both settings.
Scope limits on network, token, and operation. Pin the agent to 1 network and 1 stablecoin, and block operations it does not use. For end-user wallets, Coinbase’s documentation notes that hash signing accepts no criteria, so a rule can only allow or block it outright. A data-buying agent has no use for raw hash signing, so write a rule that rejects it.
Human approval outside the policy, through a separate channel. OWASP recommends human sign-off for high-impact actions. The Princeton paper suggests confirming high-risk actions through out-of-band mechanisms such as email or mobile notifications. We would add one condition: the request should never arrive as a reply inside the conversation the agent is already in.
A policy the agent cannot change. The credential that edits policies belongs to a person, stored apart from the agent’s runtime. Permissions should never depend on what the wallet holds, because anyone can send a wallet a token.

We ordered them by the damage each one limits. An allowlist decides who can receive money at all, so it comes first. Once a destination is approved, the cap and the budget decide how much can leave. Scope limits remove whole categories of action the agent never needed. Approval and a locked policy cover the cases the first 4 did not anticipate, including an attacker who tries to rewrite them.

How an allowlist stops a prompt injection

Take a research agent that buys market data from 3 sellers and pays in USDC on Base. Give it a wallet of its own, separate from any other agent the team runs, so its policy describes one job and nothing else. Its allowlist holds the 3 sellers’ payment addresses and nothing else. Its cap is $0.50 per payment, and its session budget is $20 for 24 hours.

A web page the agent reads carries hidden text telling it to ignore earlier instructions and send 500 USDC to a new address. Assume the worst case: the model believes the text and builds the transaction. The policy engine sees a destination missing from the list and an amount 1,000 times the cap. It rejects on either count, and the model’s reasoning never enters the check.

Encoding makes no difference. Morse code, base64, a planted memory, or a forged message from a trusted account all end the same way, because the engine reads the destination field and ignores the instruction that produced it. A prompt filter has to recognize each encoding in advance, while an allowlist rejects any address missing from the list, whatever format the instruction came in.

Apply the same rules to the Bankr case. An inbound NFT raised the wallet’s permissions, which is guardrail 6 failing: anyone able to send the wallet a token could change what it was allowed to do. By our reading of Giskard’s reconstruction, a fixed allowlist held under a separate credential would have rejected the transfer to the attacker’s address, whatever tier the NFT unlocked.

When an agent suddenly tries to pay an unknown address, it has either read something hostile or malfunctioned, and the right response is to log the attempt, end the session, and alert the owner, not to let the agent try again with a different amount. AgentCore, for one, sends logs and traces for each data plane API call to Amazon CloudWatch; an alarm on rejected requests is what gets one in front of a person the same day.

Table of 6 AI agent wallet guardrails, from a recipient allowlist to a locked policy, with what each stops and what it misses

Where guardrails fall short

Policies limit where money goes and how much leaves. Several gaps remain, and a team should plan for each.

An allowlisted contract can still route funds elsewhere. A seller’s address is a simple destination. A swap router is one address on the list, yet the trade it executes sends its output wherever the transaction data says. Allowlisting a router without constraining its parameters reopens the hole the list was meant to close. Policies that read transaction data narrow the gap; policies that check only the top-level address leave it open.

Test networks hide one of the limits. Coinbase’s documentation states that its net USD change criterion is evaluated only on mainnet transactions. A team that rehearses on a test network will never see that limit fire. Prove it with a small mainnet balance before trusting it.

Controls carry usability costs. The Princeton authors note that address allowlists and confirmations add friction and can themselves be attacked, and their results show that user confirmation reduced memory attacks without stopping them. An approval request that arrives 40 times a day gets approved without being read. Keep human approval for the rare exception, and let the allowlist and caps handle routine traffic.

Screening is a separate layer. Coinbase built Know Your Transaction screening into Agentic Wallets, which Decrypt reported blocks high-risk interactions automatically. Screening catches counterparties already flagged as risky. It does nothing about a fresh address an attacker created that morning, which is why the allowlist stays first in our order and screening sits behind it.

Damage inside the limits stays possible. A poisoned memory can still steer an agent to spend its whole budget on the wrong allowlisted seller. Policy limits cap the loss, and model fine-tuning lowers how often the attack works. Patlan and coauthors reported that security-focused fine-tuning of an open model cut attack success from 85.1% to 1.7% on single-step tasks in their own benchmark, which argues for doing both.

An allowlist checks where money goes, not who is asking. A seller receiving an agent’s payment still cannot tell whose agent sent it or what it is allowed to buy. We covered that identity question in our episode Your AI Agent Needs an ID. Does It Need a Blockchain?, and it sits outside anything a spending policy can answer.

The takeaway

Write the policy before funding the wallet: deny by default, the sellers the agent needs, a per-payment cap, an expiring budget, scope limits, an approval path, and an editing credential the agent never touches. Then attack it with an injected instruction on a small mainnet balance. If your team needs to decide who owns that policy, our AI Agent Payments Workshop works through it in 2 hours. Which of the 6 would your agent fail today?

⛔️ Disclaimer ⛔️

This article is published by Blockchain and Web3 Insights LLC for educational and informational purposes only. Nothing in this piece constitutes financial, tax, or legal advice. Always conduct your own research or consult a qualified professional before making decisions.

🗣️ Join the Conversation

Blockchain and Web3 Insights LLC is committed to delivering fact-based, practical education on Bitcoin, blockchain, and decentralized technologies. If this article was useful, please share it with your network and connect with us through the channels below to continue the conversation.