What Is Agent Overreach?
Agent overreach is a descriptive name for an action by an AI agent that goes beyond the authority its user or operator delegated: buying a different item or quantity, paying more than a per-purchase or total limit allows, paying a merchant or payee outside the approved set, or acting after the mandate expired or was revoked. In an overreach dispute, the user's complaint that the agent exceeded its instructions is true. That is what separates overreach from mandate repudiation, where the agent stayed within its authority and the user disputes the purchase anyway.
Updated
What is agent overreach?
The phrase is not a defined term in the AP2 or Verifiable Intent specifications, or in the US payment rules quoted below; this page uses it to name the pattern. The Verifiable Intent README describes the risk without naming it: "The agent might select the wrong product, overspend, or transact with an unapproved merchant."
The idea of a delegate who exceeds their authority predates agents. US consumer-payment rules already contain it. The Regulation Z commentary says that if a cardholder grants authority to a person "who exceeds the authority given, the cardholder is liable for the transaction(s) unless the cardholder has notified the creditor that use of the credit card by that person is no longer authorized" (12 CFR 1026.12). The Regulation E commentary has the same rule for debit and other electronic transfers (12 CFR 1005.2). Both give a family member or co-worker as the example. Neither addresses software a consumer set up to buy for them. This summarizes the rules and their official commentary; it isn't legal advice.
Worldpay's 2026 analysis of agentic commerce liability says a shopper who claims their agent "acted outside what they authorized is making a dispute claim, not a fraud claim," and that "Today's frameworks don't yet have a clean answer for who absorbs that." American Express has announced one specific commitment for the future: its Agent Purchase Protection terms name as eligible agent errors "transactions where the purchase deviates from the Card Member-authenticated purchase intent," on U.S. American Express credit cards, for registered agents and under conditions it publishes.
Overreach is a result, not a cause: a misread instruction, a skipped check, an attacker steering the agent through agent hijacking, or context that was out of date.
How agent overreach works
Limits on an agent come in two kinds: those checked against the purchase itself, and those checked against state that other purchases and the user can change. They fail differently:
| Limit | Checked against | Typical overreach |
|---|---|---|
| Item, quantity, category | This purchase | Wrong product or size |
| Amount per purchase | This purchase | One order over the cap |
| Approved merchants or payees | This purchase | Unapproved seller |
| Total budget, purchase count | Every earlier purchase | Cap exceeded across orders |
| Expiry, revocation | The mandate's current status | Purchase after the user cancelled |
The first three can be verified from the purchase and the signed mandate alone. Mastercard's Verifiable Intent specification calls limits like these "Machine-enforceable constraints (amount, payee, merchant)" and verifies them "at execution time." The last two need state: what was already spent, and whether the mandate is still live right now.
An illustrative revocation case, with constructed timings: at 10:00:00 a user cancels a weekly grocery mandate in the agent app. The agent workers read mandate status from a cache refreshed every 60 seconds, so at 10:00:20 a worker places the order against the cached status, "active." The order fits the signed constraints and is authorized normally. It is still overreach: the user withdrew the authority 20 seconds earlier.
Why agent overreach matters in real-time systems
The stateless kind is the easier problem. Signed constraints let merchants and networks reject an order outside them; Google's AP2 security considerations say constraint enforcement "ensures that the worst-case financial and logical impacts are strictly bounded." The stateful kind depends on what the deciding system read. A budget total that trails recent orders, or a revocation that hasn't reached every worker, produces overreach that no single check sees, worst when several agent instances act on one mandate at once.
The fix is to check limits in code before the action, against current state, and to reserve in the same transaction as the check. For mandates, revocations, per-agent limits and reservations held in Tacnode, writes are transactional, so two instances cannot both commit spend past one cap, and a revocation is visible to the next check once committed. For a card network's or issuer's own ledger, Tacnode enforces nothing; it gives the agent's decision accurate context, and the network's controls still apply on their side. Concurrency for agent decisions is covered in ACID for agents.
FAQ
Related terms
Mandate repudiation names a dispute in which a user denies a purchase an AI agent made within the authority they gave it. A decision-time record settles it.
An agent mandate is a signed record of what a user authorized an AI agent to buy: one exact purchase, or constraints such as a budget the agent must keep to.
Agent spend limits cap what an AI agent may commit per transaction, period or agent. They are only as accurate as the spend total they are checked against.
Authorization-time context is everything a payment or purchase decision must read when it authorizes: mandate status, remaining budget, limits and recent spend.
A race condition occurs when a system's outcome depends on the timing of concurrent operations, letting interleaved reads and writes corrupt shared state.
Mastercard Verifiable Intent is an open spec for signed proof of what a user let an AI agent buy, with limits that merchants and payment networks can check.