Is Agent Payment Safe? Six Places a Purchase Can Go Wrong

You give a research agent a $10 budget to buy data. It finds a $1 API, and the payment is reported as successful. That alone does not mean the purchase was safe: the source could be unreliable, the file might never arrive, or the budget could exist only as an instruction in the prompt.

Scope: This transaction is illustrative. We have not security-tested any product or payment network. Protection and responsibility depend on the product, protocol, agreement, and jurisdiction.

flowchart LR A[User sets task and budget] --> B[Agent selects service] B --> C[Independent system checks permissions] C --> D[Payment tool executes payment] D --> E[Check delivery and records]

Six points of failure

Stage	What can go wrong	Checks to consider
Selection	Irrelevant data or a provider impersonating a trusted source	Record the reason for choosing; compare sources; require approval for new merchants
Task and rules	The user asks for research but sets no budget	Limit amount, duration and purpose; require approval for larger purchases
Payment permissions	The agent can call tools beyond those needed for the task	Scope permissions by tool, recipient and action; revoke unused credentials
External content	A page or tool response contains instructions to change the recipient	Treat external content as data; independently check amount, recipient and policy at the payment tool
Payment status	A timeout prompts the agent to pay twice	Keep a request identifier, check status first and follow the service’s retry rules
Delivery and tracking	Money leaves but the file is missing or unusable	Record payment and delivery separately; provide a way to investigate and contact the merchant

Not every wallet includes these controls, and none guarantees that risk is eliminated. A semantic rule such as “buy research material only” may be difficult to enforce automatically; combine it with recipient restrictions, categories and human review where appropriate.

Why a budget is not enough

Suppose the per-purchase limit is $3 and the total budget is $10. Two useless $2 purchases may comply with both limits. A cap reduces financial exposure; it does not prove that a product is useful. An allowlist narrows the merchants involved but cannot guarantee their data is correct.

Ask whether network fees count against the budget, how concurrent requests are handled, whether an approval shows the final amount and recipient, and when revocation takes effect for submitted requests. Marketing claims are not a substitute for testing these behaviors.

Enforce checks at the payment tool

Telling a model not to overspend is a reminder. A real restriction needs to be enforced by the tool or service that can cause the payment. OWASP’s prompt injection guidance recommends checking tool parameters and permissions outside the model and binding approvals for sensitive operations to the specific action. These controls reduce risk; they do not guarantee that prompt injection is impossible.

A user should be able to understand who can spend, who can receive funds, the maximum amount, expiry, how to pause access, and how to investigate a problem. Continue with agent wallet basics and wallet key control.