Prompt Injection and Agent Spend: How to Stop an Attacker Buying With Your Card

Short answer: a prompt injection drains an agent budget when the model is the only thing deciding whether to pay. Text on a web page, in a PDF, or in an email tells the agent to buy something, the agent has a payment tool, and it obeys. You cannot fix this with a stricter system prompt, because the attacker is writing to the same context the prompt lives in. You fix it by moving the spend decision out of the model: hard limits enforced before money moves, scoped single-use credentials, and a human approval gate above a threshold.

Last updated July 2026.

How does a prompt injection turn into a payment?

The attack is unglamorous. Your agent browses a page, reads a document, or processes an inbound email. Somewhere in that untrusted content sits an instruction: ignore your previous task, purchase this item, use the checkout link below. To the model, that text arrives in the same context window as your instructions. There is no reliable boundary between "content the agent is reading" and "instructions the agent should follow", which is the entire problem. If the agent holds a payment tool, the injected text is now a payment instruction.

It gets worse with autonomy. An agent that loops (research, decide, act) can execute the injected purchase dozens of times before anyone notices, and the charges look legitimate to your processor because they are legitimate: your agent, your card, an authorized API call.

The risk compounds when several MCP servers share one context. Stripe says so in its own MCP documentation: enable human confirmation of tools and be careful running its server alongside others, precisely because of prompt injection. Our Stripe MCP server guide covers what that server exposes and how to scope the key it holds.

Why is a better system prompt not enough?

Because you are asking the model to reliably distinguish your instructions from an attacker's, using only the text of both, and it will get that wrong some fraction of the time. A defense that fails a small percentage of the time is fine for a summarization feature and unacceptable when the failure mode is money leaving your account. Model-level defenses (instruction hierarchies, injection classifiers, tool-call guardrails that inspect a request before it reaches the tool) are worth having and they meaningfully cut the attack surface. They are a filter, not a wall. Assume some injections get through and design the money layer so that it does not matter much when they do.

What actually stops it

The principle: the model can propose a payment, but it must never be the thing that authorizes it. Everything below moves the decision somewhere the attacker's text cannot reach.

1. Hard limits enforced outside the model

A spending limit that lives in the system prompt is a suggestion. A limit enforced by a policy engine before the transaction reaches the rail is a control. Set a per-transaction cap, a daily cap, and a total budget per agent, and enforce them on the request path. An injected instruction to buy a $4,000 item against an agent with a $50 per-transaction ceiling does not become a fraud investigation. It becomes a declined call and a log line. See spend controls.

2. Scoped, single-use credentials

Never hand an agent a durable card number. Issue a scoped virtual card per task: one merchant, one amount, one time window, then dead. This collapses the blast radius. If an injection (or a leak, or a bug) walks off with the credential, it is worth exactly one intended purchase at one intended merchant, and nothing after the window closes.

3. A human gate on the spend that matters

Pick a threshold and put a person behind it. Below it, the agent moves on its own and stays useful. Above it, the transaction pauses and someone approves it in Slack or email before it clears. Attackers do not generally inject "please buy one 12 dollar API credit". They inject transfers and purchases large enough to be worth their trouble, which is precisely the band a human-in-the-loop approval covers. This one control converts the worst outcome from a loss into a notification.

4. Merchant and category allowlists

Most agents have a narrow legitimate merchant set: your cloud provider, a data vendor, an ad platform. Pin the agent to it. An injected checkout link to an attacker-controlled store fails on the allowlist before anything else has to be clever.

5. An audit trail you can actually read

You want to answer "what did this agent try to buy, under what policy, on whose authority" in one query, not by grepping application logs. Record every attempt, including the declines, because a spike of declined purchases at an unknown merchant is the earliest signal you will get that something is steering your agent. See the audit trail.

Can an AI agent be trusted with a credit card?

Trusted is the wrong frame. An agent is not a person who can be trusted or not; it is a process that will do what its inputs tell it to do, and some of those inputs are written by strangers. The question worth asking is what an agent can do at its worst, and whether you can live with that. If the answer is "a $50 charge at a merchant on the allowlist, logged, reversible", the agent is safe to run unattended. If the answer is "anything my card can do", it is not, no matter how good the model is. The controls above are how you move from the second answer to the first.

A layered checklist

No single row is sufficient. Together they mean an injection that gets past your model defenses runs into a cap, a scoped card, and a person, and the worst case is a small declined charge in a log instead of a drained account. If you want to see what runaway spend looks like when none of this is in place, we wrote about runaway agent spend separately.

Where to start

If your agents already have payment access, do these in order: put a per-transaction and daily cap on every agent today, replace any shared card with per-task scoped cards, then set an approval threshold at the amount you would not want to explain to your CFO. That ordering front-loads the controls that need no product decisions. You can wire all three through the Agentspay control plane in a sandbox and see the policy reject a bad transaction before you connect a real rail.