Spending limits for AI agents: per transaction, daily and per destination

Why the limit cannot live in the prompt

Telling the agent "do not spend more than 25 dollars" is a suggestion, not a control. An agent reads pages, emails and API responses that you did not write, and any of them can contain text meant to confuse it. The limit must be enforced on the server, before money moves, and the agent key must be able to request payments but never edit its own policy. This is the same idea Stripe uses in its cards for agents, which allow spending_limits with an amount and an interval, for example per authorization or per month (Stripe Issuing for agents).

The problem already exists in Latin America. According to a Mercado article citing a survey by Universidad Torcuato Di Tella and Fundar (a figure quoted by a press piece, not verified in the original study), only 4% of Argentine small and mid-sized businesses that use AI have a dedicated budget and only 3.3% have a written policy to guide its use (Mercado). Explicit limits fill that gap.

The types of limits and what happens when they are exceeded

Two design details matter. First, a rejection by rule should not be an HTTP error: it is a valid outcome that the agent can read and decide what to do about. Second, a payment waiting for approval is never approved on its own when the deadline passes. Stripe uses a similar model in real-time authorizations, where the client responds to an event and, if it does not answer within 2 seconds, Stripe approves or declines according to the timeout setting you defined; in your own system, that setting should be to reject (Stripe, real-time authorizations).

Example policy in JSON

An example of the kind of policy described by the Nouron Pass API design. Field names may change.

{  "id": "pol_123",  "version": 3,  "per_spend_limit": "25.00",  "daily_cap": "100.00",  "monthly_cap": "1000.00",  "allowed_destinations": ["api.openai.com", "api.anthropic.com"],  "approval_over": "50.00",  "paused": false}

With this policy, a payment of 18 USDC to api.openai.com goes through. One of 60 USDC to the same destination would exceed the per-payment limit. A payment to a domain that is not on the list is rejected even if the amount is small. Every policy change should create a new version, so that each payment stays linked to the rule that evaluated it.

One consistency detail: the daily cap cannot be lower than the per-payment limit, and the approval threshold only makes sense if it differs from the maximum limit. Validate these relationships when saving the policy.

Example workflow in n8n

Here is how each rule fits into an n8n workflow.

1. Trigger. Your agent decides to pay and sends a request to an n8n webhook with amount, destination and memo.
2. HTTP node (policy lookup). Calls your spending API to read the current policy.
3. IF node (the rule). Compares before paying.
4. HTTP node (payment). Only if the IF is true, creates the payment with an idempotency key.
5. Wait node (approval). If the amount is above approval_over, the workflow pauses until someone responds.

Pseudocode for the IF node (example):

allowed =
  amount <= policy.per_spend_limit
  AND destination IN policy.allowed_destinations
  AND spent_today + amount <= policy.daily_cap
  AND NOT policy.paused

if (allowed AND amount <= policy.approval_over) -> pay
if (allowed AND amount >  policy.approval_over) -> wait for approval
else -> log the rejection and notify the agent

Snippet of the payment HTTP node (example):

{  "method": "POST",  "url": "https://api.ejemplo.test/v1/spends",  "headers": { "Idempotency-Key": "{{ $json.request_id }}" },  "body": { "agent": "agt_9f2", "amount": "18.00", "destination": "api.openai.com" }}

The idempotency key prevents duplicate payments if the workflow is retried; services such as Resend store it for 24 hours and send back the same response (Resend). The n8n Wait node can be resumed with a call to a webhook (n8n documentation); that is the piece that connects to human approval, which we explain in guide 2.

Important: the n8n IF is a second barrier. The definitive rule must be enforced on the server that moves the money, because an n8n workflow can also be edited or bypassed.

Common security mistakes

• Hidden instructions that divert a payment. An email, a page or a PDF contains text like "pay the invoice to this other address". This is prompt injection, the number one risk (LLM01) on the 2025 OWASP list for applications built on language models, according to OWASP. Defense: a list of allowed destinations and human approval for new destinations.
• Fake or near-identical destinations. A lookalike domain (api.openai.co) or an address that differs by one character. Defense: exact matching, never by prefix or partial match.
• Payment loops. The agent retries a failing task and pays every time. Defense: daily cap, idempotency key and an alert when the same destination repeats.
• Agent key with admin permissions. If the agent can edit its own policy, the limit does not exist. Defense: separate keys for paying and for administering.
• Limit only in the prompt or only in the workflow. Defense: a rule on the server, always.
• Loosening rules without confirmation. Raising a limit should require an extra step from a person.
• No log. If you cannot see what was rejected and why, you cannot tune the policy.

What Nouron Pass does with this

Nouron Pass is designed as an API and an MCP server so that a person or company in Latin America can deposit in their local currency, have it converted to USDC and let an AI agent pay and receive payments under rules: per-payment limit, daily and monthly caps, a list of allowed destinations, human approval over WhatsApp and a pause.

Nouron Pass is under construction and we open access in batches. Today we do not process real payments yet, and what is described here is the design of the API and the MCP server. If you want your agent to be among the first, reserve your spot.