AI Agent Spending Limits: A Decline Is Not a Decision

There is a moment in every agent project where somebody asks the question that stops the room. The agent works. It reads the requirements, finds the vendor, builds the cart, and stops at a checkout button it cannot press. Someone says the obvious thing: give it a card with a limit on it. And that is where most teams set their ai agent spending limits and move on.

This article is for the engineer or operations lead who has been handed that decision, and who has to make it before the agent ships.

I want to argue that the card is the wrong first move, not because a card limit is bad, but because it answers a question nobody asked. A limit on a card can do exactly one thing when the answer is no. It can decline. And a decline, in a system where an agent has already done twenty minutes of work to reach checkout, is not a decision. It is a failure with the money intact.

• There are two kinds of agent spend and they need different controls. Transactional spend is what the agent buys from other people. Operational spend is what the agent costs you to run. This article is about the first one, which almost nobody writes about
• Of the twelve pages ranking for this topic that I read, eight are published by a company selling a payment rail: a card, a wallet, a ledger, a bank account. Their answer to every question is a scoped credential, because that is the layer they own
• A spending limit can live at four layers and only one of them can escalate. Prompt text is advisory, the payment instrument can only decline, the ledger can only refuse to post, and the orchestration layer is the only one that can pause and ask
• When agents exceed their scope, enterprises overwhelmingly do not block. In a Cloud Security Alliance survey of 418 practitioners, 38 percent route the action to human approval, 24 percent require it be logged, and only 11 percent block it automatically
• In our own platform the approval is bound to the exact arguments of the tool call, compared as sorted JSON. Approving a 900 dollar payment does not approve ten 90 dollar ones, because the arguments differ and the gate fires again

Table of Contents

• Two Kinds of Agent Spend
• What the Ranking Guides Recommend
• Where AI Agent Spending Limits Can Live
• A Decline Is Not a Decision
• What Enterprises Do When an Agent Exceeds Scope
• The Fleet Scale Objection
• The Protocol Layer and What It Does Not Decide
• Building the Gate
• Five Failure Modes Worth Designing For
• What We Built and What We Did Not
• What To Do This Week
• Frequently Asked Questions

Two Kinds of Agent Spend

AI agent spending limits are rules that cap what an autonomous agent may pay, and they can be enforced at four different layers: the system prompt, the workflow that orchestrates the agent, the payment instrument it presents, and the ledger the money posts from. Only the orchestration layer can pause and ask a human instead of refusing.

Ramp draws a line in their guide to agent spending controls that I have not seen anywhere else, and it is the right line. Agent spend splits into two categories that share a word and nothing else.

Transactional agent spend is money leaving your account and arriving in somebody else's: the agent books the travel, renews the licence, pays the vendor invoice, buys the part. Operational agent spend is what it costs to run the agent at all, meaning tokens, compute and API calls. The two need different controls and are routinely confused.

The two have different owners, different failure modes, and almost nothing in common. Operational spend fails gradually and shows up on an invoice. Transactional spend fails instantly and shows up in someone else's bank account. You can recover from a surprising token bill by changing a model. You cannot un-buy a thing.

This distinction matters here because our own writing has been lopsided about it. We have covered operational spend four separate ways, in AI agent cost optimization, LLM cost alerts, AI agent observability and parts of AI agent governance. We have never written about the other half. Neither, as far as I can tell, has anyone who is not selling a card.

What the Ranking Guides Recommend

I went through the pages that rank for this topic. Twelve of them, published between April and September 2026, which tells you that ai agent spending controls are three quarters old as a written subject. Two I read end to end, Ramp's and Formance's, because they are the two making arguments rather than listing features. The rest I read closely enough to answer one question about each: where does this page put the control?

Here is the whole set, so the count below is checkable rather than asserted. Ramp, which issues corporate cards. Formance, a ledger. Fystack, on its own blog and again syndicated to Medium, and MoltPe, both wallets. Meow, a bank. Locus and Chimoney, payment infrastructure. Then two Reddit threads in r/AI_Agents, a Startup Fortune writeup, and a DEV Community post.

Eight of those twelve pages are published by a company that sells a payment rail. The four that are not are the two Reddit threads, the DEV post and the media writeup, and the Reddit threads are the only place anyone asks the question from the buyer's side.

One of them, a practitioner writing up a spending mandate layer built for agents, states the requirement more precisely than any vendor page does. Limits have to be cumulative across merchant, session, agent and workflow, evaluated before each authorisation, with the audit record capturing the attempted amount, the rule evaluated and the decision.

I want to be precise about what I am claiming, because "vendors write about their own products" is not an insight. The point is narrower. Every one of these pages contains the phrase "approval workflow" or something close to it, and every one of them then implements that approval as a threshold on a payment instrument. That is not an approval workflow. That is a spending cap with a customer support ticket attached.

Here is the sentence from Ramp's page that shows the seam clearly: agents "inherit the issuing user's existing spend limits and approval chains, so no transaction bypasses your controls." That is a true and useful property. It is also an approval chain that exists in the finance system and has never heard of the agent, the run, or the twenty minutes of work sitting behind the charge.

Where AI Agent Spending Limits Can Live

Formance makes the strongest technical argument on this SERP, and it is worth restating properly because I am going to disagree with only one part of it. Their claim is that spending limits stack in four layers of increasing strength, and that only the bottom one structurally holds.

I think the layering is right and the ordering is measuring the wrong axis. Strength is not the only property that matters. Here is the same stack, scored on what each layer can actually do when the answer is not a simple yes.

A limit written only into a system prompt is the weakest of the four for a reason that has its own entry in the OWASP Top 10 for LLM Applications: prompt injection is LLM01, and an instruction that a hostile input can overwrite was never an enforcement mechanism. The general form of that problem, and the layers that do hold, is what LLM guardrails covers.

Read the escalate column. It has one entry. Every other layer in this stack, when the policy says the answer is not an automatic yes, has exactly one move available, and that move destroys work.

Formance is right that a ledger is the only layer that structurally closes the concurrency race, where three agents read the same budget headroom inside the same 200 millisecond window and each commits against it. An orchestrator does not close that race and I am not going to pretend it does. Keep the ledger. The argument is not that one layer replaces another. It is that the layer everybody skips is the only one with a third option.

A Decline Is Not a Decision

Here is the part that none of the twelve writes about.

Every one of them discusses what happens to the money when a control fires. Not one discusses what happens to the run. I looked for it specifically, including in the two I read end to end, and the word does not appear in that sense on any of them.

Picture the actual sequence. A procurement agent receives a request, searches three suppliers, compares terms, resolves a part number against your inventory system, builds a cart, and calls its payment tool for 940 dollars against a 500 dollar per transaction cap. The card declines. Correctly. The money is safe.

Now count what you lost. The supplier comparison is gone. The resolved part number is gone. The agent's reasoning about why this supplier and not the other two is gone, because it lived in a context window that ended when the tool call failed. Whoever picks this up tomorrow starts from the request.

Worse, look at what the agent does next. A well built agent handles tool failures by retrying or adapting. An agent that just had a 940 dollar charge refused and has any latitude at all will try 500.

This is the mechanism behind the workaround a DEV Community writeup on preventing agent overspend names directly: cap the transaction and the agent makes ten smaller payments instead of one large one. Every one of those charges is inside the cap. The cap is working as designed and the outcome is worse than no cap, because the spend is now fragmented across ten records.

The failure is not the cap. The failure is that the only vocabulary the cap has is no, so a system that needed to ask a question asked nothing and improvised instead.

What Enterprises Do When an Agent Exceeds Scope

I went looking for evidence that the industry actually behaves the way this SERP recommends, and found the opposite in the survey the SERP itself keeps citing.

The Cloud Security Alliance published Autonomous but Not Controlled on 21 April 2026, based on 418 responses from IT and security professionals collected in January 2026. Most pages that cite it quote the headline number: 65 percent had an agent related incident in the previous twelve months, and of those, 35 percent reported financial losses.

Two paragraphs further down is the number nobody quotes. When agents exceed their scope:

• 38 percent of organisations require human approval for the action
• 24 percent require that it be logged
• 11 percent block it automatically

Only eleven percent block. The single most recommended control on this SERP is the least common response in practice, and the most common response is the one the SERP has no mechanism for. The same survey found 53 percent run agents autonomously for low risk tasks with human review reserved for higher risk actions, and only 13 percent operate fully autonomous models. Conditional gating is not an edge case. It is the majority design.

One disclosure the other citations of this survey leave out, and it belongs here. Token Security commissioned the report, financed it, and co-developed the questionnaire with CSA analysts. That is disclosed in the release itself. It does not invalidate the numbers, and a vendor selling agent identity controls has an interest in a finding that says agents need controls. Read the 38 percent knowing who paid for the question.

The Fleet Scale Objection

There is a serious argument against everything I have written so far and I would rather make it myself than have you find it.

Formance argues that at fleet scale, human on the loop beats human in the loop. Their reasoning: at tens of thousands of agent tasks a day, transaction by transaction approval either blocks the fleet or produces rubber stamping, and policy encoded as budget structure runs at machine speed while humans handle exceptions.

This is correct. It is also not an argument against a gate, it is an argument against a badly placed gate, and the distinction is the whole design.

A gate that fires on every transaction is the failure they describe, and I have watched it happen. Approvals become a queue, the queue becomes a chore, the chore becomes a reflex, and within two weeks you have manufactured a permanent record showing that a human approved everything, which is strictly worse than having no record at all. We made this exact argument in human in the loop AI agents: fewer, better gates.

The gate belongs on the residue. Conditions decide every case they can decide, and the person sees only what the conditions could not. AI agent spending limits work the same way a good alerting threshold does: the value of the rule is measured by how rarely it has to wake somebody up.

If your policy is written well, that is a handful of purchases a week out of thousands, and every one of them is genuinely ambiguous. If it is a hundred a day, the policy is the thing that is broken, not the gate.

Notice that the CSA numbers describe exactly this shape. Fifty three percent autonomous for low risk with review for high risk is not human on the loop and it is not human in the loop. It is conditional, and the condition is where the engineering goes.

The Protocol Layer and What It Does Not Decide

Agentic commerce is buying and selling in which an AI agent acts for a person or a business, carrying out discovery, comparison and checkout on their behalf. In 2026 it is governed by two open standards that do different jobs: one standardises the checkout exchange, the other standardises the proof that a human authorised it.

You cannot write about agentic commerce without addressing those protocols, and you also should not let them distract you, so here is the short version and the part that matters for spending limits.

Two standards define the space. The Agentic Commerce Protocol, developed by Stripe and OpenAI and released under Apache 2.0, standardises the checkout: how an agent and a business exchange a cart and a payment credential, with the business staying the merchant of record. The agentic commerce protocol deliberately leaves the accept or decline decision with the merchant, on a per agent, per transaction or custom logic basis.

AP2, the Agent Payments Protocol, was announced by Google on 16 September 2025 with more than 60 partner organisations including Mastercard, PayPal, American Express, Adyen and Coinbase.

It works as an extension of A2A and MCP, and it solves authorisation with Mandates: cryptographically signed, tamper proof records of what a user agreed to. An Intent Mandate captures the request, a Cart Mandate captures the approved contents and price.

Now read AP2's own description of the case where nobody is watching. For delegated tasks the user signs "a detailed Intent Mandate upfront" that "specifies the rules of engagement, price limits, timing, and other conditions," and the agent may generate a Cart Mandate automatically "once your precise conditions are met."

Something has to evaluate whether the precise conditions are met. AP2 gives you an unforgeable record that the conditions were agreed. It does not run them against this purchase, at this moment, with this vendor and this running total. That evaluation happens in your system, before the mandate is exercised, and it is the same evaluation this whole article is about. The protocols make the proof portable. They do not make the decision.

For most teams starting out, the honest answer is that agentic payments standards are not yet on the critical path. If your agent buys from vendors you already have accounts with, you need policy, a gate and an audit record, and you need them this quarter.

Revisit the protocols when a merchant you have no relationship with is the counterparty. If you want the surrounding argument about when a new agent protocol earns its keep, we worked through it for a different pair of standards in A2A protocol vs MCP.

Building the Gate

Enough architecture. Here is the shape, and then a workflow you can import.

An ai agent purchase approval chain has four parts in this order: request, policy evaluation, branch, and only then the agent that holds the payment tool. The policy check runs in code, not in a prompt, because the whole point is that it is not something a model can talk its way past. This is the same reasoning behind treating prompt injection as an input problem rather than an instruction problem.

What the pause actually holds

This is the part I can be specific about, because I can read our own source. When a gate fires on an agent tool call in Heym, the node returns a result with status pending rather than an error. Held alongside it are the agent's own state, the summary of what it wants to do, and the planned tool call: the tool name, the tool source, and the arguments.

Approval is matched with a strategy called exact_args. The approved arguments and the attempted arguments are serialised as sorted JSON and compared for equality. If they differ in any field, the approval does not match and the gate fires again.

That single detail is what closes the split payment workaround. A ceiling of 500 dollars approves any charge under 500 dollars, including ten of them. An approval bound to {vendor: "Acme", amount: 940, ref: "PO-4471"} approves that request and nothing else. Come back with 90 dollars and it is a new question, asked again, with a fresh record.

The pending request carries a review link with a time to live of 168 hours, one week, after which it expires rather than silently approving. On approval the workflow resumes through the same execution, so the run continues rather than restarting.

{
  "heym": true,
  "nodes": [
    {
      "id": "spend_note",
      "type": "sticky",
      "position": {
        "x": 40,
        "y": 40
      },
      "data": {
        "label": "setupNote",
        "stickyTitle": "What this workflow is for",
        "stickyColor": "amber",
        "stickyWidth": 340,
        "stickyHeight": 250,
        "note": "A purchase request comes in as structured data.\n\nCheckSpendPolicy runs with Allow network off, so the policy cannot be reached from outside the run.\n\nOnly the review route costs a person anything. The refuse route never reaches a payment rail, because a decline throws away everything the run already did."
      }
    },
    {
      "id": "spend_input",
      "type": "textInput",
      "position": {
        "x": 40,
        "y": 360
      },
      "data": {
        "label": "PurchaseRequest",
        "text": "{\"vendor\":\"Acme Supply\",\"amount\":940,\"currency\":\"USD\",\"category\":\"parts\",\"ref\":\"PO-4471\"}"
      }
    },
    {
      "id": "spend_history",
      "type": "textInput",
      "position": {
        "x": 40,
        "y": 560
      },
      "data": {
        "label": "WindowSoFar",
        "text": "[{\"vendor\":\"Acme Supply\",\"amount\":310},{\"vendor\":\"Northwind\",\"amount\":120}]"
      }
    },
    {
      "id": "spend_check",
      "type": "code",
      "position": {
        "x": 420,
        "y": 440
      },
      "data": {
        "label": "CheckSpendPolicy",
        "codeSource": "import json\n\nALLOWED = {\"Acme Supply\", \"Northwind\"}\nPER_TXN = 500.0\nPER_WINDOW = 2000.0\n\n\ndef main(params):\n    req = json.loads(params.request)\n    spent = json.loads(params.history)\n    vendor = req[\"vendor\"]\n    amount = float(req[\"amount\"])\n    window_total = sum(float(r[\"amount\"]) for r in spent)\n    vendor_total = sum(float(r[\"amount\"]) for r in spent if r[\"vendor\"] == vendor)\n\n    if vendor not in ALLOWED:\n        route, why = \"refuse\", \"vendor is not on the allowlist\"\n    elif window_total + amount > PER_WINDOW:\n        route, why = \"refuse\", \"window cap would be exceeded\"\n    elif amount > PER_TXN:\n        route, why = \"review\", \"above the per transaction ceiling\"\n    else:\n        route, why = \"allow\", \"inside every limit\"\n\n    return {\n        \"route\": route,\n        \"reason\": why,\n        \"amount\": amount,\n        \"vendor\": vendor,\n        \"vendor_total\": vendor_total,\n        \"window_total\": window_total,\n        \"window_remaining\": PER_WINDOW - window_total,\n    }\n",
        "codeRequirements": "",
        "codeParameters": "{\n  \"request\": \"$PurchaseRequest.text\",\n  \"history\": \"$WindowSoFar.text\"\n}",
        "codeAllowNetwork": false
      }
    },
    {
      "id": "spend_gate",
      "type": "condition",
      "position": {
        "x": 780,
        "y": 440
      },
      "data": {
        "label": "NeedsAHuman",
        "condition": "$CheckSpendPolicy.result.route == \"review\""
      }
    },
    {
      "id": "spend_agent",
      "type": "agent",
      "position": {
        "x": 1140,
        "y": 330
      },
      "data": {
        "label": "PlaceTheOrder",
        "hitlEnabled": true,
        "systemPrompt": "You place approved purchase orders. State the vendor, the amount and the reference in one sentence, then call the ordering tool exactly once with those values. Never split a payment into smaller ones, and never change an amount that has been approved.",
        "userPrompt": "Purchase request: $PurchaseRequest.text\nPolicy result: $CheckSpendPolicy.result"
      }
    },
    {
      "id": "spend_auto",
      "type": "output",
      "position": {
        "x": 1140,
        "y": 560
      },
      "data": {
        "label": "AutoDecided",
        "outputText": "Route $CheckSpendPolicy.result.route for $CheckSpendPolicy.result.vendor at $CheckSpendPolicy.result.amount USD. Reason: $CheckSpendPolicy.result.reason. Remaining this window: $CheckSpendPolicy.result.window_remaining USD."
      }
    }
  ],
  "edges": [
    {
      "id": "spend_e1",
      "source": "spend_input",
      "target": "spend_check"
    },
    {
      "id": "spend_e2",
      "source": "spend_history",
      "target": "spend_check"
    },
    {
      "id": "spend_e3",
      "source": "spend_check",
      "target": "spend_gate"
    },
    {
      "id": "spend_e4",
      "source": "spend_gate",
      "target": "spend_agent",
      "sourceHandle": "true"
    },
    {
      "id": "spend_e5",
      "source": "spend_gate",
      "target": "spend_auto",
      "sourceHandle": "false"
    }
  ]
}

The Python in that node ran before publication. Against the sample request of 940 dollars from an allowlisted vendor with 430 dollars already spent in the window, here is exactly what it returns:

{
  "route": "review",
  "reason": "above the per transaction ceiling",
  "amount": 940.0,
  "vendor": "Acme Supply",
  "vendor_total": 310.0,
  "window_total": 430.0,
  "window_remaining": 1570.0
}

That is the case worth seeing: inside the window cap, over the per transaction ceiling, so a person decides and the run waits rather than dying. Change the vendor to one not on the allowlist and the same code returns refuse, which never reaches the agent and therefore never reaches a payment rail.

Five Failure Modes Worth Designing For

These are the ones I would build tests for, drawn from the failure reports across the pages I read and from our own runs. Each one defeats naive AI agent spending limits in a different way.

1. Split payments. An agent refused one large charge attempts several small ones. Defeated by cumulative counting plus approvals bound to exact arguments, not by any per transaction cap.
2. The stale read. Several agents read the same remaining budget in the same instant and each passes the check. This one is real and an orchestrator does not fix it. It needs an atomic posting at the ledger, which is Formance's argument and it stands.
3. Scale errors. A model emits 1,200,000 where it meant 12,000, or the wrong currency code. Validate the amount as a typed number against a ceiling in code before anything downstream sees it, and reject rather than clamp.
4. Retry duplication. A transient failure at the payment step retries and pays twice. Every reserve, capture and release needs an idempotency key that survives the retry, and you will only notice the duplicate if the run is traced end to end.
5. Orphaned holds. A run pauses for approval, nobody responds, and reserved headroom is never released. Ours expires at 168 hours, which is a deliberate ceiling rather than a default; whatever yours is, make sure something releases the hold when it passes.

What We Built and What We Did Not

Being straight about the boundary, because this is where product posts usually stop being useful.

We build a workflow platform. What exists and is verifiable in our source: an approval gate that suspends a run rather than failing it, holds the agent's state and the planned tool arguments, matches approval against those exact arguments, and expires at 168 hours.

Alongside it, a code node that runs sandboxed with network access off by default, which is where policy belongs. A condition node for the branch. An audit trail for who approved what. Cost alerts that resolve dollars through the same pricing path the traces view uses.

What we have not built: a payment rail. We do not issue cards, hold balances, or post to a ledger. There is no Heym integration with the Agentic Commerce Protocol or AP2 today, and I am not going to describe one that does not exist. If your agent needs to move money, that comes from Stripe, Ramp, your bank or your own ledger, called from an HTTP node like any other API.

That is the honest shape of the recommendation. Keep the rail. Keep the ledger if you have fleet concurrency. Add the layer above them that can ask instead of only refusing, because that layer is missing from every guide on this subject and it is the one the CSA respondents are reaching for when 38 percent of them route out of scope actions to a person.

What To Do This Week

Ordered by what returns the most for the least work.

1. Split your two spend lists. Transactional and operational, one page. Most teams discover they have controls on one and nothing on the other, and now they know which.
2. Move the limits out of the prompt. Anything currently expressed as "do not spend more than" in a system prompt is advisory text. Move it into a policy check that runs in code, on structured input.
3. Add the cumulative counter. Per transaction ceilings alone are the control that invites its own workaround. Useful ai agent budget controls count per vendor, per run and per window, not just per charge.
4. Gate the residue only. Route review, not everything. If you cannot state the fraction of purchases that will need a human, your policy is not written yet.
5. Keep the scoped card. This is the floor and it should stay. It is just not the design.

The question that stopped the room has a better answer than a card with a limit on it. AI agent spending limits are a design problem before they are a payments problem.

Give the agent a policy it cannot argue with, a path that pauses instead of breaking, and a rail underneath that holds when both of those are wrong. Then the interesting cases reach a person with the cart still intact, which is the only version of this where the twenty minutes of work survives the decision.

If you want to see the gate before you build it, the purchase approval workflow above imports into Heym directly. The same pause-and-resume pattern applied to a different kind of request is already live as the PTO request approval template, and the human in the loop guide covers the mechanics of the pause in more depth than this article needed.

Frequently Asked Questions

How do you control what an AI agent buys?

With three controls at three layers, not one. Policy decides whether the purchase is permitted, by vendor, category and cumulative amount. Orchestration decides whether a human sees it first. The payment instrument enforces the ceiling the other two agreed on. Most guides answer with a scoped card, which is only the third control. A card can refuse a charge but cannot tell you the agent was buying the right thing from the wrong vendor.

Who should own AI agent spending governance?

The team that owns the workflow, with finance setting the ceilings. The reverse split produces the failure everyone reports: limits live in a system that cannot see what the agent was doing, so every breach reads as a declined card rather than a workflow that needs fixing. Name one human owner per agent.

What happens if my agent hits the daily spending limit?

It depends entirely on which layer the limit lives at. A limit on the card declines, the tool call fails, and the run usually dies at checkout with the cart discarded. A limit in the orchestration layer pauses the run, records why, and asks a person. The second can be resumed. The first has to be started over.

How do you prevent AI agents from overspending?

Cumulative limits rather than only per transaction ones, and approvals bound to the exact request. An agent that cannot spend 900 dollars once will spend 90 dollars ten times, and each charge is inside the cap. Count per vendor, per run and per window, and make one approval cover one argument set.

Is a scoped virtual card enough?

Necessary, not sufficient. A single use card scoped to one merchant and one amount is a good control and the fastest thing to put in place. It cannot decide. It has no view of the run and no way to escalate. Use it as the floor under the policy.

What is the difference between the Agentic Commerce Protocol and AP2?

ACP standardises the checkout, with the business as merchant of record. AP2 standardises the proof of authorisation through signed mandates. One moves the order, the other proves a person agreed. Neither decides whether your agent should be buying this.

Do I need a protocol to let an agent spend money?

Not for internal spend. If the agent buys from vendors you already have accounts with, you need policy, an approval path and an audit record, all buildable today. Protocols matter when the counterparty is a merchant with no prior relationship to you.

Sources

• Cloud Security Alliance, Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises, 21 April 2026, 418 respondents, commissioned and financed by Token Security
• Google Cloud, Announcing Agent Payments Protocol (AP2), 16 September 2025
• Stripe and OpenAI, Agentic Commerce Protocol, Apache 2.0
• Ramp, How to set spending controls for AI agents, 29 May 2026
• Formance, AI Agent Spending Limits That Actually Hold, 1 September 2026
• DEV Community, How to prevent AI agents from overspending, 2 September 2026
• OWASP, Top 10 for LLM Applications, prompt injection as LLM01
• Wikipedia, Agentic commerce, entity reference
• r/AI_Agents, Built a spending mandate layer for AI agents, 8 June 2026, practitioner thread