AI Agent Payment Incident Runbook: What to Do When an Agent Misbehaves With a Payment Credential

Q: Is an onchain stablecoin payment always unrecoverable once it's sent?

For x402's exact scheme specifically, yes by design — its FAQ describes it as a push payment that is 'irreversible once executed,' with the main path back being a seller-initiated business-logic refund, not a platform reversal. Other schemes and rails differ; check the specific rail before assuming this generalizes.

An AI agent with payment access just did something it shouldn't have, or you suspect it's about to. The order is: contain (kill the credential and pause the agent before anything else), investigate (reconstruct what the agent tried versus what actually executed), then prevent (turn the specific gap into a control that can't be talked around). Where a vendor's own docs describe a mechanism, this page names and quotes it; where they don't, it stays generic rather than guessing.

This comes up often enough to deserve a standing page: people on Hacker News have asked why a shopping agent ended up with "an unrestricted browser and a memory containing card details, date of birth, and SSN information" (HN, 2026-09-28); developers on the x402 GitHub have asked "how do you handle an unreliable or bad-actor agent today?" (x402 issue #3345) and asked maintainers to "avoid paywall fraud" outright (x402 issue #508). None of those threads land on a step-by-step answer — this is an attempt at one.

In the first 15 minutes

Do these in order. Don't wait for a root cause before you act.

1. Revoke or rotate the credential

Kill the specific credential the agent used — API key, wallet access key, or virtual card — not the whole account.

Stripe MCP: revoke the session directly: "To revoke a session: 1. Find the client in the OAuth sessions list. 2. Click the overflow menu (⋯). 3. Select Revoke access" (Stripe MCP docs). If the agent used an API key instead of OAuth, rotate the key. Note the deadline either way: "Beginning October 31, 2026, Stripe MCP no longer accepts full-access secret keys or restricted API keys without the Agent tag" (same source) — reissue with an Agent-tagged key now rather than twice.
Stripe-issued virtual card: you don't need to wait for a key rotation to propagate. Stripe's agent-issuing guide describes flipping the card off directly: "If the agent flags a transaction, freeze the card immediately while the issue is investigated," via one API call setting the card's status to inactive (Stripe Issuing for agents). This is also the case for single-use cards before an incident even happens: "Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use" (same source).
Wallet access key (Circle, Coinbase, Tempo, or similar): revoke or delete the key from the provider's dashboard or CLI. This runbook found no published, quotable self-service "revoke this key" documentation from those three — treat that as a gap to close via support.
Generic fallback: no scoped revoke option in two minutes? Rotate everything the agent had access to — a broken integration beats a credential you're not sure is still live.

2. Pause the agent

Killing the credential stops new payments; it doesn't stop the agent retrying or taking non-payment actions. Stop the process, disable scheduled runs, or pull it from the orchestration loop. If it shares infrastructure with other agents (a gateway, a key, a budget pool), isolate it rather than shut down the whole fleet.

3. Freeze pending payouts where the platform allows it

Authorized-but-unsettled payments are sometimes stoppable; settled ones generally aren't. Check your dashboard for anything pending, authorized-not-captured, or scheduled, and cancel or void what you can. This is genuinely platform- and rail-specific — a pending card authorization, a scheduled ACH payout, and a submitted onchain transaction behave differently, and no universal mechanism exists. No cancel/void action? Move to "recover money" below rather than assume one is hidden.

Investigate

Containment buys time; it doesn't tell you what happened. You need three things:

The tool-call log — every tool invocation, with arguments, timestamps, and the prompt that triggered it. Stripe MCP tool call logs are visible in Workbench (referenced from Stripe's MCP docs).
The decision log per payment attempt — separate from the tool-call log, a record of every time a payment was checked against your spend policy (cap, allowlist, approval threshold), including rejections. A tool-call log tells you what the agent asked for; a decision log tells you what your controls did about it — the piece most teams don't have until after their first incident. Our runnable example shows a minimal version: cap, allowlist, approval threshold, idempotency, and a decision log enforced before the payment executes, in plain Node.
The provider's own transaction history — ground truth for what actually executed. Reconcile it against your logs; a mismatch between "the agent's log says it tried X" and "the dashboard shows Y happened" is itself a finding.

Reconstruct the sequence: what the agent attempted, what your controls allowed or blocked, what the rail actually executed. Watch for a rejected oversized payment followed by several smaller ones adding up to the same total.

Prompt injection is a likely cause, not a remote one. Any tool that reads untrusted content — a webpage, an email, a support ticket — can carry instructions that redirect what the agent pays for next. Stripe's MCP docs call this out: "Enable human confirmation of tools and exercise caution when using the Stripe MCP with other servers to avoid prompt injection attacks" (Stripe MCP docs). If a payment attempt doesn't trace back to a legitimate user request, check what content the agent read beforehand. For more, see spending controls for AI agents.

Recover money

Disputes, refunds, and chargebacks are platform- and rail-specific. Nothing here is legal advice.

Card-rail payments generally go through your provider's dispute process. Stripe documents filing a dispute programmatically against an Issuing transaction when an authorized amount doesn't match the settled amount: "it flags the transaction and initiates a dispute" via POST /v1/issuing/disputes (Stripe Issuing for agents). Start with your card issuer's actual process, not an assumed timeline.
x402 payments using the exact scheme are generally not reversible once executed. Its FAQ is explicit: "The exact scheme is a push payment" that is "irreversible once executed" (x402 FAQ). What's available instead is a cooperative refund: "Business-logic refunds: Seller sends a new token transfer back to the buyer" (same source) — getting money back depends on the seller choosing to send it, not a platform undo.
Other rails and wallets (bank transfers, other settlement schemes, other card networks) have their own recovery mechanics not independently verified here — go to your provider's documentation rather than assume the above generalizes.
This page doesn't tell you whether you're liable for a loss or what your provider's terms say about the scenario. That's a legal and contractual question specific to your agreements.

Prevent the next one

Most incidents trace back to a control that existed in theory but wasn't enforced before execution:

Scoped credentials, not master keys — every agent gets its own key, wallet access key, or card, never one shared or reused from a human account.
Per-agent spending caps. Circle Agent Wallets let you "set USDC spending limits for outbound transfers and x402 payments," with limits that "can be time-bound (for example, daily, or monthly)" (Circle docs); Coinbase's Agentic Wallet CLI documents "configurable caps per session and per transaction" (Coinbase docs); Tempo's wallet CLI lets "--max-spend and scoped access keys ... enforce budgets per request and per key" (Tempo docs).
Allowlists for destinations and merchants — a compromised agent can't pay a new destination even within budget.
Approval thresholds for above-routine spend. Stripe's MCP server builds this in: "Stripe requires human confirmation before it takes certain stripe_api_write actions, such as refunds and outbound payments," via a link that expires after 24 hours if unapproved (Stripe MCP docs) — worth replicating on rails that don't offer it natively.
Idempotency keys on every payment call, so a retried request can't double-spend.
Rolling budgets, not just static caps — a per-transaction cap won't stop a hundred small payments draining a budget in an hour.
Alerts on threshold crossings and unusual velocity, so a human finds out during the incident, not at reconciliation.
A decision log for every payment attempt, approved or rejected — the artifact that makes "investigate" above possible.
A kill switch — one action that revokes the credential and halts the agent, tested before you need it.

Pink Agentic AI Payment (early access) enforces per-agent spending caps, allowlists and approval thresholds at the MCP layer, before a payment executes.

For a starting policy to adapt, see the AI agent spending policy template; for wiring controls into a payment flow, see spending controls for AI agents and how to let an AI agent pay for API usage. Choosing an MCP payment server? Payment MCP servers compared covers what each vendor's docs say about confirmation, scoping, and controls.

Printable checklist

AI AGENT PAYMENT INCIDENT — FIRST 15 MINUTES
[ ] Revoke/rotate the specific credential the agent used (API key / wallet access key / virtual card)
[ ] Pause or isolate the agent (stop process, disable schedule, remove from orchestration loop)
[ ] Freeze/cancel any pending, not-yet-settled payments where the provider allows it
INVESTIGATE
[ ] Pull the tool-call log (what the agent asked for)
[ ] Pull the decision log (what your spend controls allowed/rejected)
[ ] Pull the provider's transaction history (what actually settled)
[ ] Reconcile all three; flag any mismatch
[ ] Check whether the agent recently read untrusted content (prompt injection)
RECOVER
[ ] Start your specific provider's dispute/refund process (rail-specific, not universal)
[ ] Confirm whether the rail used is reversible before promising a recovery timeline
PREVENT THE NEXT ONE
[ ] Scoped credential per agent (no shared/master keys)
[ ] Per-agent spending cap (with rolling window, not just per-transaction)
[ ] Destination/merchant allowlist
[ ] Approval threshold for above-routine spend
[ ] Idempotency keys on every payment call
[ ] Alerts on threshold crossings and unusual velocity
[ ] Decision log for every payment attempt, approved or rejected
[ ] Tested kill switch

FAQ

Is an onchain stablecoin payment always unrecoverable once it's sent? For x402's exact scheme specifically, yes by design — its FAQ describes it as a push payment that is "irreversible once executed," with the main path back being a seller-initiated business-logic refund, not a platform reversal (x402 FAQ). Other schemes and rails differ; check the specific rail before assuming this generalizes.

Should I revoke the agent's credential or the whole account first? The credential, scoped as narrowly as possible. Revoking a whole account is faster to decide but breaks every other integration using it. A properly scoped, single-agent credential should be revocable on its own — a reason to scope credentials before an incident, not during one.

What if I don't have a decision log for the payment the agent made? Your investigation is limited to the tool-call log and the provider's transaction history, and you'll be inferring intent rather than confirming it. Treat the missing log as a finding, and set one up (see the runnable example) before the next incident.

Does a prompt injection incident change who's responsible for the payment? This page doesn't answer liability questions — those depend on your contracts, provider terms, and jurisdiction. Operationally, prompt injection is a documented risk for agents with payment tools (Stripe MCP docs); the fix is a control (approval thresholds, allowlists, human confirmation), not something to reason around after the fact.

Last updated 2026-09-29. This is operational guidance, not legal advice.