Letting an agent spend your money

The question usually arrives in a mundane form. Your assistant offers to book the flight rather than list the flights. A workflow you built needs an API that charges per call. Someone in a forum mentions that their agent renews their domains now, and you cannot tell from the post whether that is clever or reckless. You want to know whether to let it, and nobody gives you a straight answer, because the honest answer is not a yes or a no. It is a set of account settings you have not configured yet.

This guide is for a solo operator or a small team who already runs an agent for something and is now deciding whether it gets a payment method. It is not for a company with a finance function, a corporate card policy and a treasury team, and it is not for anyone building payment infrastructure for other people. The useful shift is to stop asking whether you trust the model. Trust is not a control, and it does not survive the day the model reads a poisoned web page. Ask instead what the largest possible loss is on the worst day, and then go and make that number smaller.

Agents already spend in three different shapes, and they are not equally risky

The first shape is an assistant driving a browser on your behalf. ChatGPT agent handles longer, multi-step tasks by clicking buttons, filling out forms and navigating websites, using screenshots of its virtual browser window to see and interact with web pages [1]. This is the shape most solo operators meet first, and its exposure is bounded by whatever card or account is already saved in the sites it visits.

The second shape is machine-to-machine, and it is quieter. AgentCore payments became generally available in Amazon Bedrock AgentCore on 18 August 2026 [8]. AWS describes it as a fully managed service that enables microtransaction payments in AI agents to access paid APIs, MCP servers and content, orchestrated with open HTTP-native standards including the x402 protocol, which uses the HTTP 402 Payment Required status code [7]. Nobody clicks anything here. An agent hits a paywalled endpoint, pays, and continues. The exposure is not one large purchase, it is an unbounded number of small ones.

The third shape is the rails underneath both. The Agent Payments Protocol, an open protocol from Google now being standardised in FIDO Alliance working groups, exists to answer three questions that ordinary card payments never had to ask: how to verify that a user gave an agent specific authority for a particular purchase, how a merchant can be sure an agent’s request reflects the user’s true intent rather than an error or a hallucination, and who is accountable when a transaction turns out to be fraudulent or incorrect [6]. That these questions needed a protocol is the tell. The existing system does not answer them.

Work out which shape you are in before you touch a setting, because the controls differ. A browsing agent is capped by the payment method it can reach. A paying API client is capped by a session budget. Only the second one can spend a hundred times before you refresh your inbox.

Money changes the failure mode, not the failure rate

Agents fail the way ordinary software does, and also in one way it does not. OpenAI calls prompt injection a type of social engineering attack specific to conversational AI, made of harmful instructions designed to trick an AI into doing something you did not intend, often hidden inside ordinary content, and says it remains a frontier, challenging research problem on which the company expects its work to be ongoing [2]. Anthropic lists a stack of safeguards in Claude Code, including a separate context window for web fetches so fetched pages cannot inject prompts, and approval prompts for commands such as curl and wget that fetch content from the web, and then says plainly that while these protections significantly reduce risk, no system is completely immune to all attacks [3].

Take both vendors at their word. They are not being modest. They are telling you that the input side of this problem is not closed, which means any control that depends on spotting a bad instruction is a control you cannot lean on.

What changes when money is attached is not how often the agent goes wrong. It is what a wrong step costs. A coding agent that misbehaves leaves you a bad commit, and version control exists precisely so that mistake is cheap. A purchasing agent that misbehaves leaves you a settled transaction, and there is no equivalent of git revert for a card authorisation. You get a refund request, a dispute, and a wait. The autonomy is the same. The reversibility is not.

Your card protections were not written for an agent you authorised

This is the part that surprises people, and it is worth reading slowly. Under Regulation Z, unauthorised use means the use of a credit card by a person, other than the cardholder, who does not have actual, implied, or apparent authority for such use, and from which the cardholder receives no benefit [5]. Where that definition is met, the liability of a cardholder for unauthorised use shall not exceed the lesser of $50 or the amount of money, property, labor, or services obtained by the unauthorised use before notification to the card issuer [5].

Now hold your situation against that sentence. You configured the agent. You gave it the card. It bought something you did not want, from a merchant you did not choose, because a web page told it to, and the goods or the API credits arrived in your account. Whether that counts as use by a person other than the cardholder without authority, and whether you received no benefit, is not obvious, and it is not a question the rule was drafted to answer. The $50 backstop you have quietly assumed all your life was written for a stolen card, not for a delegate you installed yourself.

None of this is legal advice, and a real dispute turns on facts, on your issuer, and on where you live. The practical consequence holds anyway. Do not build your plan around the assumption that someone else absorbs the loss. Assume that money leaving the account you attached is money you have spent, and set the account up accordingly.

Caps belong in the platform, not in the prompt

A limit written into a prompt is a suggestion to a system that is known to follow instructions from the wrong place. A limit enforced by the account is arithmetic. Anthropic puts the underlying principle in one line: Claude Code only has the permissions you grant it, and you are responsible for reviewing proposed code and commands for safety before approval [3]. The permission surface is the real control, not the wording above it.

Here is what that looks like with actual dials. Stripe Issuing lets you set spending_limits as an amount plus an interval, where the interval can be per authorisation, weekly or monthly, and you can restrict spend to allowed_categories or block blocked_categories, plus allowed or blocked merchant countries [4]. Two of its defaults are worth knowing. If you do not set spending_limits, a default spending limit of 500 USD per day applies to the newly created card, and an unconfigurable default limit of 10,000 USD also applies to each authorisation [4]. Where a cardholder has overlapping spending limits the most restrictive one applies, and spending limits alone do not block categories, so a limit and a category restriction are two different jobs [4].

The machine-to-machine side works the same way one layer down. In AgentCore payments, each PaymentSession has a configurable budget limit and an expiry time, and when the session expires or the budget is reached, further payment requests are denied [7]. AWS describes the generally available release as enforcing configurable payment limits at the infrastructure layer [8], which is the correct place for them. AP2 encodes the same instinct in the protocol itself, building transactions out of mandates, which it describes as tamper-evident, cryptographically signed digital objects, so that each transaction leaves a non-repudiable, cryptographic audit trail [6].

Notice what none of these controls do. They do not try to decide whether an instruction is trustworthy. They assume the agent may already be doing the wrong thing and cap what the wrong thing costs. That is why they work, and why a cleverly worded system prompt does not.

The account you attach is the decision, and one step keeps a human

Run the calculator once with your real intended settings and the number will probably embarrass you. That is the point. The fix is almost never a better prompt. It is a smaller account.

Attach a dedicated account or virtual card that holds a float you would write off without argument, and top it up deliberately rather than linking it to the balance that pays your rent. Everything else in this guide is a refinement of that one move. If the agent can only reach $200, then the caps, the category restrictions and the alerting are all improvements on a loss you have already survived.

Start read-only and stay there longer than feels necessary. In Manual mode, Claude Code starts with read-only permissions and asks first when it needs to edit files, run tests or execute commands that can modify your system [3]. Copy that pattern for money. Let the agent research, compare and propose for a week or two, and read what it proposed. You will find out whether it picks the right vendor before it can pay the wrong one.

Then name the one action that still requires you. OpenAI says it often designs agents to get a final confirmation from you before certain consequential actions like completing a purchase or sending an email, and advises limiting an agent’s access, where possible, to only the sensitive data or credentials it needs to complete the task [2]. ChatGPT agent adds user confirmations for high-impact actions and a watch mode requiring user supervision on certain sites, and it pauses and prompts you to take control of the virtual browser when a task requires a login [1]. Keep those defaults. Where a platform lets you widen them, widen them for the reversible steps and never for the irreversible one.

The trap is confirmation fatigue, and it is real enough that vendors design against it. Anthropic lists prompt fatigue mitigation as a built-in protection, supporting allowlists of frequently used safe commands per user, per codebase or per organisation, so that the prompts you do see still mean something [3]. OpenAI’s advice is that when an agent asks you to confirm an action, you carefully check that the action looks right and that any information being shared is appropriate to share in that context [2]. A confirmation dialog you approve reflexively forty times a day is not a control, it is a formality. Allowlist the boring actions so that the money question is the one thing that ever interrupts you.

What still goes wrong

Caps leak at the edges. Stripe notes that spending aggregation is done on a best-effort basis, with a delay of up to 30 seconds between spend occurrence and spend aggregation, and that additional tips and fees can be posted at a later time, causing a spending limit to be exceeded [4]. A cap is a strong control and an imprecise one. Do not treat the number as a fence you can stand on.

The failure mode nobody plans for is not one large purchase. It is many small ones. A per-transaction cap of $5 feels safe until an agent stuck in a retry loop hits a metered endpoint a few hundred times overnight, which is exactly the pattern that a service built for real-time agent-to-merchant microtransactions makes easy [7]. Per-authorisation limits do not save you there. Interval limits and session budgets do, so set both, and set the interval one you would notice.

Then there is the part that no setting fixes. Every safeguard described here is a vendor default that a vendor can change, and OpenAI’s own note on ChatGPT agent says these measures do not eliminate all risks and that it remains important to monitor the agent and exercise care when using it [1]. The controls also assume you are watching. A solo operator is one person, and the honest version of this arrangement is that you are the audit function, the approval queue and the incident response, usually while doing something else. That is survivable when the account behind the agent is small. It stops being survivable the day you connect the main one because the small account ran dry and you were in a hurry.