Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
How Do You Set a Spending Limit for an AI Agent?
Put the limit on the instrument the agent spends with, a virtual card with its own cap, and have a named person approve anything above a threshold, so a hijacked run cannot exceed the card. Then check what the model reads on the payment page, because a card limit caps the loss and not the exposure.
A $500 virtual card ends one kind of loss. An agent that has been hijacked can still spend the $500 and cannot spend $5,000, so the worst case is a number a finance team can write down before the run starts. That is the argument for putting the limit on the instrument rather than in the instruction, and it is half of what a security review needs.
The other half is what the agent reads on the way to spending. A checkout page, a supplier portal's payment screen and a card manager's dashboard all render values the agent has to handle: the card number, the expiry, the billing address, the vendor's bank details. A model that reads them holds them, and the card limit does not take them back. A cap placed on the card and nothing else has bounded the charge and left the reading where it was.
The two halves meet in one record type: a $500 virtual card issued for supplies, spent by an agent on a page that shows the number it is spending with. Whether the cap holds and what the run collected on the way are separate questions, and they take separate controls.
Key findings
- For the cap to bind a hijacked run, the amount has to sit on the instrument the agent spends with, and the values on the page where it pays would have to be replaced with consistent tokens before the model reads them, so the run holds CARD_001 and the real number resolves only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each purchase above the threshold and a record of what the model received, because a card limit bounds the charge and says nothing about what the agent collected (What Is an AI Control Record?).
- None of the card pages reviewed states what the model receives from the page where the card is used; Ramp documents the limit and the merchant restriction, and links to a product for agents without describing it (Ramp, Virtual cards, 2026).
- Ramp's card page says a virtual card can carry "its own limit by transaction, day, or month so no card can overspend," and that a card can be restricted "to a single vendor or merchant category to block unwanted charges" (Ramp, Virtual cards, 2026).
- Brex's help center says "Creating a dedicated card for each of your vendors is one of the easiest ways to control spending," while creating one stays with "admins and any other users with the specific product capability" (Brex, 2026).
Where should a spending limit sit, on the card or in the prompt?
Horton and colleagues describe agents as "autonomous software systems that perceive, reason, and act in digital environments to achieve goals on behalf of human principals, with capabilities for tool use, economic transactions, and strategic interaction" (MIT Sloan, 2026). A system with economic transactions in its remit will reach a payment page, and the first decision is where its limit lives.
A limit written into the agent's instructions is text the model reads, and the same run that reads a poisoned product page can read past the sentence that says to stop at $500. Beurer-Kellner and colleagues state the rule: once an agent ingests untrusted input, "it must be constrained so that it is impossible for that input to trigger any consequential actions" (Beurer-Kellner et al., 2025). A card limit is that constraint at the payment step, where the issuer, not the model, decides whether the charge goes through.
The shape matters as much as the size. Ramp's card page offers a limit set "by transaction, day, or month" and a single-use card that "automatically closes after one payment" (Ramp, Virtual cards, 2026). A $500 monthly cap permits five $100 charges from a hijacked run; a $500 per-transaction cap on a single-use card permits one. Its controls page adds that a fund marked "Does not repeat" will not reset (Ramp, Controls, 2026).
The record here is a $500 virtual card issued for supplies. The agent buys printer paper and toner from a new supplier. Redirected to buy a $500 gift card, the card does not distinguish the two; the merchant restriction and the category block narrow it, and both are set before the run.
What does the agent read on the page where it pays?
A checkout page shows the agent the card it is spending with. The number, the expiry, the security code and the billing address are rendered on the page, and the model reads them to fill the form. A supplier portal's payment screen works the same way: the vendor's bank details and remittance address sit in the fields the agent matches against an invoice, so "a model that reads the whole vendor record to match an invoice holds all of it" (Can AI Work NetSuite Payables Without Bank Details?).
What a model reads, it can repeat. A study of browsing agents reports "prompt injection, domain validation bypass, and credential exfiltration" among its findings and shows "how untrusted web content can hijack agent behavior" (How Do I Design an Agent Workflow That Assumes the Agent Gets Hijacked?). A card number in a context window is a credential in that window, and a hijacked run can write it into a form, a chat or a summary.
A card limit answers the charge and not the reading. A stolen number can be used elsewhere until the card expires or the period's cap is consumed, which is why Ramp offers a card that "automatically closes after one payment" as well as a limit (Ramp, Virtual cards, 2026). The stronger design replaces the number on the page with a token, so the model works with CARD_001 and the real number resolves only at the approved destination (What Is Render-Layer Tokenization?). A value the model never received cannot be disclosed later (What Is Least Exposure?).
What do the vendors themselves say?
The card pages describe the limit precisely and the reading not at all, which is why the table separates the two.
| Dimension | What the page documents | What a buyer should verify |
|---|---|---|
| Limit shape | Ramp: a limit "by transaction, day, or month"; Brex: "granular spend controls on a per-vendor basis" | Which period the cap resets on, and whether the agent can reach more than one card |
| Merchant scope | Ramp: a card restricted "to a single vendor or merchant category" | Whether the allowed category names the supplier or a marketplace that sells anything |
| Expiry and single use | Ramp: a card that "automatically closes after one payment" | Whether the run needs a second payment, and what replaces the card when it does |
| Approval above a threshold | SAP: "the invoice is then automatically blocked for payment" and released "in a separate step" | Who releases the block, and what that person sees before releasing it |
Ramp's product page is explicit: a virtual card can carry "its own limit by transaction, day, or month so no card can overspend," and a card can be restricted "to a single vendor or merchant category to block unwanted charges" (Ramp, Virtual cards, 2026). Its controls page explains the decline: "All spend from merchants not classified in the selected categories is declined," and "Any transactions over this amount will be automatically declined" (Ramp, Controls, 2026).
Brex's help center recommends "a dedicated card for each of your vendors" as "one of the easiest ways to control spending," with "granular spend controls on a per-vendor basis," and card creation is permissioned to "admins and any other users with the specific product capability" (Brex, 2026).
SAP's course page shows the same control in a different place: when an upper tolerance is exceeded, "the invoice is then automatically blocked for payment," the block "applies to all items in an invoice," and a person "must release a blocked invoice in a separate step before it can be cleared for payment" (SAP Learning, 2026). The tolerance is set per company code, and the page states standard behavior.
Who approves a purchase above the limit, and what should a buyer ask for in writing?
An approval above a threshold is a decision by a person, and the card limit is what makes the threshold real. The card stops the run at $500; the approval covers a $900 purchase.
The approval is the step an attacker targets. OWASP's entry for HITL dialog forging describes an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP Foundation, n.d.). A dialog that shows a $90 purchase while the request is for $900 is the failure this names, and it is a reason to put the approved amount and destination in the record, not only in the dialog.
A bounded credential is not an approver. A session's permissions can be "the intersection of the role's identity-based policy and the session policies," which limits what a run can reach and still leaves no person answering for the action (Does a Coding Agent Need Approval Before Spending Money?). Supervised Delegation puts the person in the design: a named person grants access and approves each consequential action (What Is Supervised Delegation?).
FINRA's 2026 oversight report lists "AI agents acting autonomously without human validation and approval" among the risks it flags, and warns that "Agents may act beyond the user's actual or intended scope and authority" (FINRA, 2025). An approval with a name and a time is the reconstructable part.
In writing, ask for the approved amount and destination on the record, what the model receives from the rendered screen where the agent pays, and the log in the buyer's own system, with "agent identifiers, real-time monitoring, and activity logging" (Chan et al., 2024) and "attributing actions, properties, and other information to specific agents" (Chan et al., 2025) as the research proposes. Of the 15 AI agents reviewed, 6 document asking a person before completing a payment or purchase, and Ramp, Brex and SAP were outside that review, so the approval above the limit is a control the buyer writes into the workflow (Do AI Agents Ask Before Making a Payment?).
What does a governed environment change?
A governed environment acts where the page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the card number renders as CARD_001 on the checkout page and stays CARD_001 on the confirmation page. Real values resolve only at the approved destination, at the moment of an approved action, so the payment form receives the number and the transcript does not. That is a different control from a cap on the card, and it covers the part of the run a cap cannot see.
For this page's question it changes two things a card limit leaves open. A run that never received the card number cannot carry it out of the session, and the token it holds is worth nothing on another site. The record holds each screen as the model read it, each action, each decline and the name of the approver, exported to the organization's own monitoring.
The limit and the approval stay. A governed environment does not replace the card's cap or the person at the threshold, and it makes the screen in between carry nothing that can be spent elsewhere. The three controls answer three questions: how much can be charged, who said yes, and what the model saw. A spending limit is a strong answer to the first and no answer to the third, and the third is the one a hijacked run exploits.
What the record shows
The control that answers this question has three parts, in different places: a cap on the instrument, a named person at the threshold, and tokens on the rendered screen before the model reads it. The card pages make the first two practical and leave the third open; they document limits, merchant restrictions, expiry, single-use cards and permissioned creation, and none of them covers what the model receives when it reads the checkout screen. The conclusion for a $500 supplies card is narrow. The cap holds against a hijacked run that tries to overspend, because the issuer declines the charge, and it does not hold against a run that reads the number and uses it elsewhere. A finance team should check this in an afternoon: issue a test card with a $500 cap, run one agent purchase on a checkout page, and compare the amount the card allowed with the values in the run's transcript.
Methodology and limitations
This page rests on the public documentation of two corporate card providers, one invoice verification course page, three research preprints, FINRA's 2026 annual regulatory oversight report, an OWASP attack entry, one industry analysis and RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation and none was tested for this page, so "not described in the pages reviewed" means the pages reviewed and not a claim about what a product does. Vendor features change and the page carries its date; RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
How do you set a spending limit for an AI agent?
Put the limit on the card the agent spends with and keep the amount in the issuer's system rather than the prompt. A virtual card with a per-transaction or monthly cap, a merchant category restriction and an expiry date gives a finance team a number it can write down before the run. Then pair the cap with a named approver above the threshold and a record of the screens the agent read. The cap decides how much can leave, and the other two decide what the run collected.
Does a card limit tell you what the agent read?
No. A limit is a rule about money, and the page that shows the card number is a separate exposure. The card pages reviewed describe caps, merchant restrictions and expiry, and none describes what the model receives when it reads the checkout screen. A run that reads the number and stores it in a summary has collected a credential the limit does not reach. Check the transcript for the number itself, not only for the amount.
Who should approve a purchase above the limit?
A named person with the authority to spend, not the model and not a rule. The approval should show the amount, the supplier and the destination, and it should be recorded with the approver's name and the time. OWASP's entry on forged approval dialogs describes attacks that alter what the dialog shows, so the record has to carry the request the person actually approved. A threshold without a name is only a setting in the card console.
What does the model receive when it reads a card number on a payment page?
Whatever the page renders, which on most checkout pages is the full number, the expiry and the security code. A governed environment replaces those values with consistent tokens before the model reads the screen, so the run holds CARD_001 and the real number resolves only at the approved destination. Ask which of the two your tool does, because a limit on the card does not change the answer.
What record should a card limit leave?
One record per run: the screens the model received, each charge and each decline, the token or the value that appeared on the page, and the name of anyone who approved a purchase above the threshold. The card vendor's console holds the charges, and the record a reviewer needs also covers the reading. Export it to the organization's own monitoring so the evidence outlives the session.
Are virtual cards enough on their own?
For the charge, usually yes, and for the reading, no. A card with a cap and a merchant restriction stops an overspend at the issuer, and it does not stop a run that reads the number from carrying it elsewhere. The pair that covers both is a capped card and a screen where the number is a token. A buyer who has only the first has bounded the loss and left the exposure.
How RedactSure Keeps the Card Number Off the Rendered Page
A card limit bounds the charge and leaves the card number on the page the agent read. Ramp's page offers a card that "automatically closes after one payment," a control that expires the number rather than replacing it (Ramp, Virtual cards, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the browser rendered the real number on the checkout page, the model read it, and a hijacked run could carry it to another site until the card expired. Inside the governed environment the page renders CARD_001, the real number resolves only at the payment form a named person approved, and the record holds the screen as read.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
Bring one purchase you would let an agent make and see, with test values, what the model reads on the payment page. Then check who approves a charge above the limit and what the record holds afterwards. Book a demo