AI Agent Approvals and Spending Limits Guide

An AI agent that can call tools can delete data, buy things, run up cloud and model bills or grant access, and a prompt telling it to be careful does not stop any of that. What stops it is a set of hard limits enforced outside the model: which actions need a person's approval, how much the agent may spend per action, per session and per period, and when a stronger confirmation is required. This guide covers how to classify agent actions, set approval boundaries and thresholds, design per-action, session and adaptive spend limits, use step-up mechanisms such as decoupled approval and rich authorisation requests, and measure whether the limits work. It is for security architects, IAM and NHI teams, AI platform engineers and finance or risk owners who sign off what agents may do. The design of approval gates and reviewer experience is covered in the Human-in-the-Loop for AI Agents Guide; this guide concentrates on thresholds, budgets and step-up.

Key takeaways

Enforce outside the model. Approval boundaries and spend limits belong in the tool layer, gateway, payment credential or cloud account, where a manipulated agent cannot talk its way past them.
Classify actions before setting numbers. Destructive, financial, privilege-changing and external actions need different boundaries from reversible writes, and some should simply be prohibited.
Layer limits. A per-action cap alone is defeated by many small actions; combine per-action, per-session, per-period and velocity limits, with the most restrictive applying.
Bind approvals to the exact action. The approver should confirm the specific amount, payee, resource or command, and the enforcement point should reject anything that differs.
Expect lag in budget data. Many cloud and card budgets aggregate with a delay, so a hard cap needs headroom and a fast pre-authorisation check, not only an alert.

What needs an approval boundary

OWASP LLM06:2025 Excessive Agency lists "excessive autonomy" as a root cause, with the example of an extension that deletes a user's documents without confirmation, and recommends human approval for high-impact actions and complete mediation in downstream systems. The first job is deciding which actions are high-impact. Classify by effect, not by tool name, because one tool (a shell, a SQL connection, a generic HTTP call) can perform actions of every class.

Action class	Examples	Default boundary	Typical limits
Read	Search, fetch records, summarise	No approval	Query rate, data volume per session, token budget
Reversible write	Create ticket, draft document, add label	No approval within bounds	Count per session; changes logged and revertible
Destructive or irreversible	Delete records or files, drop tables, force push, terminate instances	Approval every time, or prohibited in production	Zero by default; bulk operations blocked
Financial	Payments, purchases, refunds, credits, subscriptions	Approval above a threshold; prohibited above a ceiling	Per transaction, per session, per day or month, per payee or category
Resource consumption	Launching compute, model calls, paid API calls	Within budget; approval to exceed	Token and spend budgets, instance quotas, timeouts
Privilege or identity change	Grant roles, create keys, change MFA, add OAuth apps	Approval every time by someone other than the requester	Zero by default
External communication	Send email, post publicly, share files externally	Approval for new recipients or bulk sends	Recipients per session, attachment size

Prohibit before you gate: OpenAI's Practices for Governing Agentic AI Systems notes that some actions should be blocked entirely rather than approved. Production deletes and privilege grants are usually in that set for general-purpose agents.
Do not trust tool self-descriptions: the Model Context Protocol tools specification says clients must consider tool annotations untrusted unless they come from trusted servers. Classify third-party tools yourself rather than relying on a server's claim that a tool is read-only.
Autonomy level: the boundary for each class depends on how much the agent decides alone. See the AI Agent Autonomy Levels Framework.

Designing thresholds and spend limits

A spend limit is a ceiling on value or consumption that the agent cannot exceed without a new decision. Limits should be layered so that no single bypass, such as splitting one large purchase into many small ones, defeats them.

Limit type	What it stops	Where to enforce	Watch for
Per-action cap	One large mistaken or injected transaction	Payment credential, tool wrapper, API gateway	Splitting into many small actions
Session spend limit	Runaway loops within one task	Agent runtime or gateway keyed on session ID	Agent restarting sessions to reset the counter
Period budget (daily, monthly)	Gradual overspend across sessions	Card or account controls, cloud budgets, model provider spend limits	Aggregation lag; late-posted fees
Velocity limit	Bursts of actions or spend in a short window	Gateway rate limits, card authorisation rules	Legitimate peaks; set per agent, not globally
Category and payee allow-list	Spending on the wrong things or people	Merchant category and country controls, payee registry	New payees added by the agent itself
Adaptive limit	Spend that is in budget but out of character	Risk engine using behaviour and context	Opaque decisions; keep a fixed hard ceiling underneath

How enforcement points behave in practice

Card controls: Stripe Issuing spending controls apply to cards and cardholders with spending_limits (an amount, an interval such as per authorisation, daily, weekly or monthly, and optional categories) plus allowed or blocked merchant categories and countries. Where limits overlap, the most restrictive applies. Stripe states aggregation is best effort with up to 30 seconds of delay, and that tips and fees posted later can push spend over a limit.
Model provider limits: the Claude API supports an organisation spend limit below the tier cap and per-workspace spend and rate limits, with organisation limits always applying. When a custom limit is reached, requests fail with an error stating when access resumes. Give each agent or agent group its own workspace or project so one runaway agent cannot consume the organisation's budget.
Cloud budgets: AWS Budgets actions can apply an IAM policy or service control policy, or target specific EC2 or RDS instances, at a threshold, either automatically or after manual approval. Google Cloud documents that an alerts-only budget does not cap usage, that costs are reported with a delay, and that Pub/Sub budget notifications can automate responses such as disabling billing on a project.
Agent payment protocols: Google's Agent Payments Protocol (AP2) describes mandates in an open stage that records constraints such as a budget and allowed instruments, and a closed stage that authorises a specific checkout and amount, chained as signed credentials. Visa Intelligent Commerce describes users approving a payment instruction with a passkey and the network validating the authorisation against that instruction. See the Agent Payments Protocols Guide and the Agentic Commerce Identity Guide.

Setting the numbers

Start from the business task: derive the per-action cap from the largest legitimate transaction the task needs, and the session limit from a realistic worst case of one task, not from what feels comfortable.
Leave headroom for lag: where aggregation is delayed, set the enforced cap below the true tolerance, as Google advises setting a budget below available funds.
Use the existing delegation of authority: an agent acting for a person should never have a higher approval threshold than that person has in the finance delegation matrix.
Keep hard ceilings fixed: adaptive limits may lower what is allowed when signals look unusual; they should never raise it above the fixed ceiling without a person.

Model and cloud cost runaway as an attack (Denial of Wallet in OWASP LLM10:2025 Unbounded Consumption) is covered in depth in the Denial-of-Wallet and AI Agent Cost Runaway Guide.

Step-up approval mechanisms

When an action crosses a boundary, the agent should pause and a person should confirm through a channel the agent cannot forge. The strength of that confirmation should rise with impact.

Mechanism	How it works	Strength	Best for
In-session confirmation	Client shows the proposed tool call and the user clicks approve or deny	Low to medium: same session the agent operates in	Reversible writes, low-value actions, developer tools
Return of control	Agent framework stops and hands the proposed call to the application, which executes only on confirmation	Medium: application, not model, executes	Business actions in custom agent apps
Decoupled approval (OpenID CIBA)	Client requests approval; user authenticates on a separate device and sees a binding message	High: separate device, verified identity	Payments, privilege changes, actions while user is away
Transaction-bound authorisation (RFC 9396)	Request carries `authorization_details` with the exact action and amount; token is issued for that only	High: resource server enforces the approved detail	Payments, data exports, any parameterised high-impact API
Passkey-signed instruction	User approves a purchase instruction with a passkey; downstream checks match the instruction	High: phishing-resistant, bound to instruction	Agentic purchases on card networks
Two-person approval	A second, independent approver confirms	Highest	Large payments, production deletes, admin grants

Return of control example: in Amazon Bedrock Agents, user confirmation can be enabled on an action group function; the agent returns a returnControl object with an invocationId, and the application sends back a confirmationState of CONFIRM or DENY. AWS presents this as a protection against prompt injection in content the agent reads.
CIBA details: the OpenID CIBA Core 1.0 specification identifies the user with login_hint, login_hint_token or id_token_hint, supports poll, ping and push delivery, and returns an auth_req_id with an expires_in lifetime. Use binding_message to show the amount and payee on both devices.
RAR details: RFC 9396's example uses type payment_initiation with instructedAmount, creditorName and creditorAccount. The granted details travel with the token so the resource server can reject a payment to a different creditor or for a different amount.
Approver identity: require MFA for approvers, short-lived approval tokens and logging of every approval interaction, as the AWS Agentic AI Security Scoping Matrix recommends for approval-gated agents. See the Conditional Access Guide.

Where identity fits

Limits only work if they attach to something the agent cannot swap. Bind each limit to the agent's own credential: a dedicated card or token per agent, a separate model provider workspace or API key per agent, a separate cloud account or project for agent-launched resources. If an agent shares a human's card, API key or cloud role, its spending is indistinguishable from the human's and its limit is the human's limit. Treat payment credentials and model API keys held by agents as high-value non-human identity secrets, vaulted and rotated, because a stolen key bypasses every agent-side gate. The LLMjacking 2024 to 2026 page shows how stolen cloud credentials and API keys were used to run up model bills for attackers, which is exactly what per-key spend limits contain. See the AI Agent Authorisation Guide and the LLMjacking Guide.

Decision guidance

Approval vs limit: use approvals where each instance needs judgement (a payment to a new payee, a delete); use limits where instances are routine but the total matters (model calls, small purchases). Approving routine actions creates fatigue; OpenAI's governance paper warns that frequent or context-poor approvals tend to be rubber-stamped.
In-session vs decoupled: in-session confirmation is acceptable when the person is present and the impact is reversible. Use decoupled, transaction-bound approval when money moves, when the user is not present, or when the agent reads untrusted content that could forge an approval request in the chat.
Fixed vs adaptive limits: fixed limits are predictable and auditable; adaptive limits catch out-of-pattern behaviour. Most organisations should start fixed and add adaptive tightening later, keeping fixed ceilings.
Small organisations: use platform features first: per-key or per-workspace spend limits at the model provider, card spending controls, cloud budget actions, and built-in tool confirmation. Prohibit destructive and privilege actions for agents entirely.
Large organisations: centralise enforcement in an agent gateway or policy engine with a shared action taxonomy, map thresholds to the finance delegation matrix, and require two-person approval above set values. See the Policy-as-Code for Authorisation Guide.

How to implement

Inventory agent capabilities: list each agent's tools, credentials, payment instruments, model keys and cloud accounts.
Classify actions: map every tool operation to an action class and mark prohibited operations; remove tools and scopes the task does not need.
Set limits in shadow mode: deploy the gateway or wrapper in log-only mode for two to four weeks, recording which calls would have needed approval or breached a limit.
Tune and agree: review shadow results with the business and finance owner, set per-action, session and period values, and record them with an owner.
Enforce in rings: enable enforcement for one agent or team first, then widen. Configure the platform limits (cards, provider workspaces, cloud budgets) as a backstop under the gateway.
Test bypasses: try splitting transactions, restarting sessions, prompt-injecting an approval request, changing parameters after approval and using a second tool to reach the same effect. See Red Teaming AI Agents for Identity Abuse.
Roll back safely: if limits block legitimate work, raise a specific limit for a specific agent with an expiry; never disable the gateway globally. Keep the kill switch independent of the limit system. See the AI Agent Kill Switch and Containment Guide.

Detection and measurement

Log each proposed action with agent identity, delegating user, action class, parameters, amount, limit evaluated, decision (allowed, approval required, denied), approver and timestamps. The MCP tools specification says clients should log tool usage for audit and show tool inputs to the user before calling the server.

Limit breaches blocked: count and value of actions stopped by a limit per agent per month; investigate sudden rises.
Spend against budget: actual agent spend as a percentage of approved budget, per agent and in total.
Approval rate and time: share of approval requests approved and median time to decision; near-total approval in seconds suggests rubber-stamping.
Parameter mismatches: executions rejected because they differed from the approved amount, payee or resource. Any occurrence warrants review.
Unbound credentials: agents spending through shared or human credentials rather than their own limited ones (target zero).
Aggregation lag: measured delay between spend and limit evaluation on each platform, used to set headroom.

Framework mapping

Framework	Reference	Relevance
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency	Require user approval for high-impact actions; complete mediation in downstream systems
OWASP Top 10 for LLM Applications 2025	LLM10:2025 Unbounded Consumption	Denial of Wallet; rate limiting, quotas, timeouts and throttling
NIST SP 800-53 Rev. 5	AC-3, AC-5, AC-6	Enforcement of limits; approver separate from requester; least privilege per action class
NIST SP 800-53 Rev. 5	AU-10, AU-12, SI-4	Non-repudiation of approvals; audit records of actions and decisions; monitoring of spend and velocity
NIST CSF 2.0	PR.AA-05, DE.AE-02	Authorisations defined and enforced; analysis of anomalous agent activity
MITRE ATT&CK	T1657 Financial Theft; T1496.004 Cloud Service Hijacking; T1485 Data Destruction	Impacts that payment, consumption and destructive-action limits contain
MITRE ATLAS	AML.T0051 LLM Prompt Injection; AML.T0053 AI Agent Tool Invocation	How an agent is induced to take the action the limit must stop

Common failure patterns

Policy in the prompt: "never delete production data" written as an instruction is not a boundary. In the Replit AI agent database deletion the agent ran destructive commands during a declared code freeze; the fixes Replit announced, such as separating development and production databases, were controls outside the model.
Per-action cap only: an agent below the per-transaction limit makes hundreds of transactions; without session and period limits nothing stops it.
Alert mistaken for a cap: a cloud budget configured to email at 100% while usage keeps running, discovered when the invoice arrives.
Approval not bound to parameters: the user approves "pay supplier invoice" and the executed call carries a different amount or account, because the approval token was not tied to the details.
Shared credentials: agents using a person's card or the organisation's main API key, so no agent-level limit exists and a leaked key is unlimited.
Counter resets: session limits keyed on something the agent controls, so starting a new conversation or sub-agent resets the count.

Practitioner checklist

Classify every agent tool operation into action classes and list prohibited operations.
Enforce approvals and limits in a gateway, tool wrapper or downstream system, never only in the prompt.
Give each agent its own payment token, model workspace or key and cloud account or project, each with its own limits.
Set per-action, session, period and velocity limits, with fixed ceilings beneath any adaptive logic.
Bind approvals to exact parameters using transaction-bound authorisation or signed instructions for financial actions.
Use decoupled approval on a separate device, with MFA, for payments and privilege changes.
Run new limits in shadow mode, then enforce in rings with platform limits as a backstop.
Test splitting, session resets, parameter changes and injected approval requests before go-live.
Track blocked breaches, spend against budget, approval quality and parameter mismatches monthly.

AI Agent Action Approvals and Spending Limits Guide: Thresholds, Budgets and Step-Up