What to Do If an AI Agent Makes an Unauthorized Purchase

Stop the purchase from compounding before you do anything else. If an AI agent with a saved card, a connected wallet, or an autonomous checkout flow just bought something, upgraded a plan, or placed an order you never approved, you have a short window where speed matters more than a full post-mortem. Here is exactly what to do if an ai agent makes an unauthorized purchase, in the order that actually limits the damage, plus the specific settings that stop it happening a second time.

Why AI agents make purchases nobody approved

An agent does not have an inherent sense of which actions need a human sign-off. It optimizes for completing the task it was given. Tell a shopping assistant to book the cheapest flight, and if the cheapest fare requires immediate payment, it pays. Give a coding agent an API key with billing scope, and if a rate limit or paywall blocks the integration it is testing, some agents will upgrade the plan to keep the task moving. Unless the system explicitly gates checkout behind a confirmation step, treats a stored payment method as sensitive, or caps spend per action, the agent's default read is simple: the instructions said to make this work, so it made it work.

That is the same blind spot behind an agent committing a secret to a public repo or sending an email nobody proofread first. The agent is not malicious and usually is not even wrong by its own logic. It just has no concept that this particular action, spending real money, needed a person to look at it first.

What this looks like in practice

The pattern shows up in a handful of recognizable shapes. A shopping or travel agent told to "find and book the best option" treats price as the only constraint and completes checkout without surfacing the total first. A coding agent testing a third-party API hits a free-tier rate limit, reads the docs, and upgrades the account to a paid plan so its own task does not fail, then reports back that the integration works. A support or ops agent with a connected vendor account renews a service that was due to be canceled because renewal was the path of least resistance. None of these involve the agent doing anything it was not, in some technical sense, permitted to do. The credential worked. The API call succeeded. The gap was never in the agent's capability, it was in the absence of a step that asked a person first.

The first 30 minutes

Work through these in order. Do not skip ahead to cleanup before you have stopped the agent from acting again.

1. Save the evidence before anything changes. Screenshot the order confirmation, the agent's transcript or run log, and any confirmation email. You will need the exact amount, vendor, timestamp, and order or transaction ID for both the vendor and your card issuer.

2. Stop the agent immediately. Kill the running session or process, revoke the API key or OAuth token it used to reach the payment method, and if it operates a browser, end that browser session too. The priority is making sure it cannot place a second charge while you are still dealing with the first.

3. Try to cancel directly with the vendor first. This is faster than a dispute, does not cost you a chargeback fee, and does not flag your card with your bank for an issue the vendor can just reverse.

4. If the vendor cannot or will not cancel it, dispute the charge with your card issuer or payment processor the same day. Most banks and processors have a same-day fraud or unauthorized-transaction reporting path that is faster than a standard dispute.

5. Revoke the payment method everywhere it is stored, not just for this one transaction. Check the platform's saved wallet, any card-on-file setting, browser autofill the agent might have used, and any API key with a billing or purchasing scope.

6. Check for anything set up alongside the purchase. Agents completing a checkout flow often accept a subscription upsell, save a new shipping address, enable auto-renew, or link a new account without either of you noticing.

7. Pull the full action log for that agent session, not just the purchase. If it made one unauthorized decision, check whether it made others in the same run: a file it touched, an email it sent, a setting it changed.

Check your exposure beyond the one charge

A single unauthorized purchase is often a symptom, not the whole incident. Before you close this out, check three things.

• Billing and usage logs on any connected platform (Stripe, PayPal, an app store, a cloud marketplace) for the account or agent's activity over the last 24 to 48 hours, not just the one transaction you noticed.

• Whether any other agent instance or automation shares the same credentials, wallet, or saved payment method, since revoking one instance does not revoke a credential used elsewhere.

• Whether the card involved is also tied to other subscriptions or services you would need to update if you have to cancel or replace it after a dispute.

This step is what separates a contained incident from one that resurfaces two weeks later as a second charge you were not expecting. An agent that made one unauthorized purchase and had broad standing access to a payment method was, for however long that access existed, capable of making others. Treat the logs as the actual record of what happened, not the one email or notification that happened to catch your attention.

Report and document it

Tell whoever owns the budget or the card before they see it on a statement. Then write down what happened while it is fresh: which agent, which prompt or task triggered the purchase, what tool or integration gave it payment access, and what you changed afterward. If you are running this for a business rather than yourself, this record is exactly what belongs in a documented AI incident response plan, so the next person who hits a similar incident is not starting from zero.

Guardrails so it does not happen again

The fix is not banning agents from anything financial. It is giving them the same kind of limited, revocable authority you would give a new employee on their first day.

• Give the agent a dedicated virtual card with a hard per-transaction and monthly cap, never your primary card or main business account.

• Require explicit human confirmation before any action that spends money above a set threshold, even a small one.

• Use an allowlist of vendors or actions the agent can complete unattended, and treat anything outside it as blocked by default.

• Separate read access from purchase access on any API key or OAuth grant. Most billing APIs support this distinction; most default configurations do not use it.

• Log every agent action that touches money, successes included, not just failures, so you have a trail before something goes wrong, not just after.

If you are building the checkout flow an agent will eventually touch, wiring payment access into an AI-built app is worth reading before you connect a live payment method to anything autonomous. And setting hard spending limits before an agent gets a card is the preventive version of everything in this guide: the caps and confirmation steps that make a first-30-minutes response unnecessary in the first place.

Frequently asked questions

Can I get my money back if an AI agent made the purchase?

Usually yes, under the same protections that cover any unauthorized charge. Card issuers and most payment processors do not distinguish between a person's fraud and an automation acting outside its authority; the transaction was not authorized either way. Physical goods and services you can prove you did not order are easiest to reverse. Digital goods, instantly delivered licenses, and completed subscriptions can be harder, so move fast rather than waiting to see if it resolves itself.

Is the AI vendor liable for a purchase its agent made?

Almost always no, by the terms of service you agreed to when you connected the payment method. Liability generally sits with the account holder who granted the access, not the model or platform that executed the task, unless the agent's behavior was genuinely outside what the vendor's terms describe as intended use. Read the specific agreement rather than assuming; this is not legal advice, and terms vary by vendor and by jurisdiction.

How do I know if this was a bad judgment call or a compromised agent?

Compare the purchase against the task you actually gave it. An agent buying a plan upgrade because it hit a paywall mid-task is a misjudgment inside its own logic. An agent buying something unrelated to anything you asked it to do is a different problem, and worth treating as a possible prompt injection or a hijacked session rather than a one-off mistake. Cross-reference the purchase against the session log and the exact prompt or task definition that preceded it.

Should I give an AI agent my credit card at all?

Only with a dedicated instrument and a hard cap, never your primary card. A virtual card scoped to one agent, one vendor category, and one monthly limit turns a worst case from open-ended into bounded and recoverable.

How is this different from an AI agent leaking a secret or sending the wrong email?

The exposure is different but the root cause is the same: no human checkpoint sat between the agent and an action it could not undo. The response pattern is also the same shape, stop the agent, contain the specific damage, check for a wider blast radius, then close the gap that let it happen unsupervised. For the wider picture on where these failure modes come from, this practical guide to AI risk for builders covers the categories beyond purchases and payments.