# Prompt injection when the agent can spend money

Prompt injection is the insertion of instructions into content an agent reads, causing it to act on the attacker's goals. When the agent can pay, the consequence is a payment the user never intended, carried out with the user's own valid credentials. Signed authorisation proves consent was given, not that it was informed.

Published: 2026-10-14
Last reviewed: 2026-10-14
Publisher: Roundhouse AI Ltd.
Source: https://roundhouseai.io/resources/prompt-injection-and-agent-payments

---

## Why do payments make injection worse?

An agent reads things: web pages, documents, emails, API responses, other agents' output. Any of those can contain text crafted to be read as an instruction rather than as content.

Without a wallet, the worst case is an agent doing something wrong. With a wallet, the worst case is an agent doing something wrong that costs money and cannot be reversed. An on-chain settlement has no chargeback, so the usual last line of defence is absent.

The uncomfortable part is that every control in the payment stack still works correctly during the attack. The key is the right key. The signature is valid. The settlement is final. Nothing is broken; the agent was simply convinced.

## What signed authorisation does and does not prove

Security analysis of mandate-based schemes in 2026 made a point that generalises past any one protocol: **a signed mandate proves the user signed, not that the user understood.**

If an attacker can shape the agent's context, the agent can present a validly signed authorisation for a purchase the user never intended. The signature is real. The intent behind it is not. No amount of cryptography addresses that, because the cryptography is working.

| Control | What it proves | What it does not |
| --- | --- | --- |
| A wallet signature | This key authorised this transfer | That the key holder wanted it |
| An AP2-style mandate | A user signed a description of a purchase | That the user understood what they signed |
| A settlement | Funds moved | That anything was delivered |
| An allowlist | The payee was approved | That the amount or the item was |

> [!IMPORTANT]
> This is why spending controls cannot live in an agent's reasoning. Anything an attacker can talk the agent out of is not a control, it is a preference. The controls that hold are the ones enforced outside the agent, by a wallet, a policy engine or a contract.

## Which controls actually hold?

Published work on agent payment security converges on the same short list regardless of which protocol is in use.

**A per-transaction cap.** Enforced below the agent, so the largest single loss is bounded no matter what the agent was told.

**A rolling budget.** Per session and per day. Caps the cumulative loss from a sequence of individually small, individually plausible payments, which is the shape an injected instruction usually takes when it is trying to stay under a threshold.

**A counterparty allowlist.** For anything high value. An agent that may only pay addresses on a list cannot be redirected to a new one, which removes the most direct version of the attack.

**Short expiry.** A permission that lapses in a day limits a leaked session key to a day. This is the cheapest control on the list and the most consistently omitted.

**A kill switch.** Something a human can trigger that stops spending immediately, without redeploying anything.

[Agent wallet spending controls](https://roundhouseai.io/resources/agent-wallet-spending-controls) covers how these are enforced, and the difference between a provider policy engine and an on-chain permission grant matters: one depends on a server behaving correctly and the other does not.

## Where does the injection come from?

Worth being specific, because the mitigations differ.

**Content the agent fetched.** A web page, a PDF, a scraped result. The classic case. Mitigation is to treat fetched content as data rather than instructions, which models do imperfectly.

**Another agent's output.** Delegation chains mean one agent's response becomes another's context. An [agent card](https://roundhouseai.io/resources/agent-cards-and-a2a-discovery) is published by its subject and is also untrusted content.

**API responses.** Including from services the agent is paying. A seller that returns instructions in its response is attacking its buyer, and an agent that pays strangers is reading output from strangers by construction.

**The agent's own tooling.** Frameworks that store memory, skills or configuration as files can have those files poisoned. Research into agent frameworks in 2026 flagged bootstrapped guidance as a specific vector, since instructions loaded at startup are trusted more than content read later.

## What a seller should know

Two asymmetries worth naming, because they cut against each other.

**You can be used as the attack.** If an attacker can get an agent to pay you, you have received money from a victim. Even if you did nothing, you are in the transaction and the settlement is public and final. A seller with a genuine history of distinct buyers is better placed when that question is asked.

**Your output is your buyer's context.** Anything you return goes into an agent's reasoning. Returning content that reads as instructions, even innocently, is the thing responsible buyers screen for. Return data, labelled as data.

## Frequently asked questions

### Can a model be trained not to fall for this?

It can be made harder to fool, and no current approach is reliable enough to be the only control. This is the reason the enforcement has to be outside the model.

### Does a human-in-the-loop fix it?

For high-value purchases, mostly, if the human is shown what is actually being bought. It does not scale to thousands of sub-cent payments, which is where agents spend most of their calls, so you need both.

### Is this specific to crypto payments?

No. The same attack works on card rails and the consequences differ: cards have chargebacks and a dispute process, on-chain settlement does not. The attack is identical; the recovery is not.

### How would I know it happened?

From the payment record. An unexpected payee, an unusual amount, a cluster of payments outside normal pattern. This is an argument for monitoring an agent's spending as a time series rather than only capping it.

### Does paying a stranger make this worse?

It widens the surface, since you are reading output from a party you have not vetted. Screening the counterparty before paying reduces it. [How to screen one](https://roundhouseai.io/resources/screen-an-agent-counterparty-before-paying) covers the checks that are actually available.

## Where to check this yourself

The payment side is checkable even when the reasoning side is not. [/wallets](https://roundhouseai.io/wallets) shows every settlement an address has made, so an agent's spending can be reviewed after the fact against what it was supposed to be doing. [Vetting a counterparty](https://roundhouseai.io/docs/guides/vet-a-counterparty) covers the pre-payment checks.

---

Roundhouse indexes x402 settlements and ERC-8004 identities into one public record.

- Every article: https://roundhouseai.io/resources.md
- Every surface on this site: https://roundhouseai.io/llms.txt
- The index, endpoints and schema: https://api.roundhouseai.io/v0
- A key of your own, $0.01 over x402, no account: https://api.roundhouseai.io/v0/test/x402
- Limits and the SQL surface: https://roundhouseai.io/docs/api