If you want to limit how much an AI agent can spend, the limit has to live somewhere the agent cannot reach. A number in the system prompt is a suggestion. A number checked by a server before any card is issued is a limit. This post covers the limit types Authoryze supports, how they combine, and how to set them.
Why prompt-based limits don't work
The obvious way to cap an agent is to tell it. "Never spend more than $50 without asking." It works until it does not, and the ways it fails are ordinary. A long task pushes the instruction out of the agent's working context. A web page the agent reads contains text that tells it the limit was raised. A retry after a timeout charges the same $40 twice, which is under the limit each time and over it in total. The agent misreads a price in a foreign currency. None of these need a malicious model. They are normal bugs, and the only thing standing between them and your money is a sentence the model may or may not still be weighing.
There is a second problem. A prompt-based limit is only checked by the thing it is limiting. The agent evaluates whether the agent is in bounds. If you give it a real card, there is no second party in the loop.
Authoryze moves the check to the server. The agent asks for each purchase through request_purchase, Authoryze evaluates the request against the rules you configured, and no card exists until the evaluation passes. The agent can be wrong, confused, or injected, and the rules still hold. That is the property to look for in any payment tool, and it is covered in what to look for in AI agent payment infrastructure.
The limit types
Each agent in Authoryze has its own rules. You can set any combination of the following.
Per-transaction limit. The largest single purchase the agent can make. A request over it is denied outright, with the limit and the requested amount in the denial reason. This is the first check that runs and the simplest to reason about. If your agent buys API credits and SaaS seats, a $100 per-transaction cap means a misread price or a $2,000 annual plan cannot go through under any circumstances.
Daily, weekly, and monthly caps. Rolling windows on total spend. Each one is checked against what the agent has already spent in that window plus the new request. A $30 daily cap with $25 already spent denies a $10 request. The reset times are visible to the agent through get_spending_summary, so a well-behaved agent can wait for the window to roll over rather than fire off requests that will be denied. Example 3 in the docs shows an agent doing exactly that.
Total budget. A lifetime cap on the agent. Once cumulative spend reaches it, every further request is denied until you raise it. This is the right control for a project agent with a fixed allocation, or for a trial where you want a hard ceiling on the downside regardless of time.
Merchant allowlists and blocklists. A list of domains the agent may buy from, or may not. Matching includes subdomains, so allowing amazon.com also allows aws.amazon.com. A request to a merchant outside the allowlist is denied and the reason names the approved list, which gives the agent enough information to explain the problem to you instead of retrying. For an agent with a narrow job, the allowlist is the most effective single rule you can set, because it removes whole categories of mistakes before amounts are even considered.
Cooldown between purchases. A minimum number of minutes between one purchase and the next. This blunts the retry loop failure, where an agent repeats an action it already completed. Combined with idempotency keys, which are covered in how to stop an AI agent from making duplicate purchases, it makes accidental double buys hard to produce.
Aggregate caps across agents. Per-agent limits have a gap. Three agents with $50 daily caps can spend $150 a day between them, which may be far more than you meant. Authoryze lets you set daily, weekly, and monthly caps at the account level that apply to every agent combined. They are checked after the per-agent rules, and hitting one is a denial whose reason says it was an account-wide cap rather than the agent's own. This is the defense against multi-agent collusion, whether deliberate or the accidental result of three agents each doing their job. The security docs describe how the check is ordered.
Auto-approve thresholds
The rules above are hard limits. A violation is a denial and nothing is issued. The auto-approve threshold is different. It is the line between purchases the agent can complete on its own and purchases that come to you first.
A request that passes every rule and is under the threshold is approved immediately. A request that passes every rule but is over the threshold goes into pending review. You get an email with the merchant, the amount, the agent's justification, and which agent asked, and you approve or deny it from the email or the dashboard. The agent polls check_status while it waits. There is no deadline on that wait. The request stays pending until you decide.
The threshold lets you set the hard limits generously and still keep a hand on anything unusual. An agent with a $500 per-transaction limit and a $25 threshold can buy small things all day and will still stop for the $300 purchase. Set the threshold to zero to approve everything by hand, or set it equal to the per-transaction limit to let the agent operate fully inside its rules. Example 2 in the docs walks through a request that crosses the threshold.
Automatic spending envelopes
By default, an approved purchase over the threshold needs a one-off authorization from you sized to that exact amount. If you want the agent to handle a run of purchases without a tap each time, you can authorize an automatic spending envelope on the agent's page in the dashboard.
An envelope is an amount the agent can draw against, either one-time or recurring on a schedule. You confirm it with a passkey. Every rule above still applies inside it. The envelope does not raise a limit or bypass a merchant list. It only removes the per-purchase authorization for spend that is already in policy. Drawing a card through retrieve_card consumes envelope room, and once the envelope is used up, the next request routes to you for approval with a reason that says why. The setup docs describe how to authorize one.
How to set them
- Create the agent. In the dashboard, go to Agents, then Create agent. Give it a name and an auto-approve threshold. Each agent gets its own API key and its own rules, so an agent that buys cloud credits and an agent that books travel should be two agents with two rule sets.
- Set the per-agent rules. On the agent's page, fill in the limits you want. Leave a field blank to skip that rule. A reasonable starting point for a new agent is a low per-transaction limit, a daily cap, a short allowlist of the merchants it actually needs, and a threshold below the per-transaction limit.
- Set account-wide caps. In Settings, add daily, weekly, or monthly aggregate caps. These apply across every agent you have now and every agent you create later.
- Optionally authorize an envelope. If the agent will make many small in-policy purchases, authorize an envelope on its page so it does not need a tap for each one.
- Verify from the agent's side. Connect the agent to your assistant using the MCP configuration docs and ask it to show its spending summary. The response lists every configured limit and how much room is left. If a limit is missing from the response, it is not set.
Rules take effect on the next request. Changing them does not touch purchases already approved.
Common questions
Can the agent change or ignore its limits?
No. Rules are stored in your Authoryze account and evaluated on the server when the agent calls request_purchase. The agent can read its limits through get_spending_summary and cannot write them. An instruction in a prompt, or in a web page the agent reads, has no effect on the evaluation.
What happens when a request breaks a rule?
It is denied before any card is issued. The response includes a reason that names the rule and the numbers involved, and usually a suggestion, such as retrying after the window resets or asking you to raise the limit. The denial is recorded in the dashboard with the rest of the agent's history.
Do limits apply to purchases that need my approval?
Yes. The rules run first, and a request that violates one is denied without ever reaching you. Only requests that pass every rule and exceed the threshold come to you for a decision. Approving a request never overrides a rule.
How do aggregate caps interact with per-agent limits?
Both are checked. A request has to fit under the agent's own daily cap and under the account-wide daily cap. The stricter of the two decides. The spending summary reports both, under the agent's fields and under a separate user aggregate object, so the agent can see which one is binding.
Ready to put real limits on an agent? Create an Authoryze account, set the rules on your first agent, and they are enforced from its first request.