How do I enforce an AI agent's payment caps at the execution boundary instead of in the prompt, and record the approval details with each payment?

What should I check, step by step?

1. Remove the cap from the prompt as the control. You can leave a sentence telling the model the budget so it plans well, but the number that matters lives in a policy store the agent's tools can only read.

2. Find the boundary: the single function, proxy or issuer hook every payment must pass. If the agent holds a raw API key, card number or wallet key it can call around your wrapper, so give it a scoped credential that only works through the boundary.
3. At the boundary, check in this order: policy exists and isn't expired, payee is allowed, amount is under the per-payment cap, amount plus spend already recorded for this task and this agent is under the task and period caps, and an approval is present if the amount is over the approval threshold.
4. Count spend from your own record of authorized payments, not from what the agent says it has spent. Reserve the amount when you allow it and release it if the payment fails, so parallel calls can't each pass the same remaining budget.
5. For approvals, compare a hash of the exact action (amount in minor units, currency, payee, item or quote id) with the hash the person approved, and check the approval's expiry. A different amount or payee is a different action.
6. Write the approval details onto the payment: approval_id, approver, decided_at, policy_id, policy_version and action_hash. Stripe allows 50 metadata keys of up to 40 characters with values up to 500 characters, enough for ids and a hash; put anything bigger in your own store and reference its id.
7. Write every allow and every deny, with its reason code, to storage the agent can't edit, and keep the same ids there so the payment and the decision can be joined later.
8. Add an instrument-level limit as a backstop (card spending controls, a small dedicated wallet), so a bug in your boundary still can't spend the whole balance.

Why isn't a spending cap in the agent's prompt a real control?

OWASP's LLM01:2025 Prompt Injection entry describes inputs that change a model's behaviour in ways the developer didn't intend, including through content the agent reads such as web pages and documents. A spending rule held only in the prompt can be overridden the same way.

• OWASP's LLM06:2025 Excessive Agency entry recommends enforcing authorization in downstream systems rather than relying on the LLM to decide whether an action is allowed, and limiting what extensions can do. A payment cap is exactly that kind of downstream check.
• Even without an attack, models miscount. The agent may not know about payments made in another branch, a retry it didn't see, or a currency conversion. The boundary sees every payment; the model sees its context window.

Where is the execution boundary for agent payments?

In your own code: the tool function the agent calls to pay. It's the simplest place, but only works if the agent has no other way to pay (no raw keys in the environment, no generic HTTP tool that can reach the payment API).

• In front of the wallet or API: a gateway or proxy that holds the real credential and forwards only calls that pass policy. The agent gets a credential that is useless anywhere else.
• At the issuer: Stripe Issuing applies spending controls on the card and can send an issuing_authorization.request webhook for each authorization so your endpoint approves or declines it in real time. Coinbase's CDP SDK offers spend controls (per-payment and cumulative caps) for x402 clients.
• Use more than one layer for money that matters: your boundary for task-aware caps and approvals, and the instrument's own limits as the last stop.

What approval details should be recorded with each agent payment?

On the payment object: approval_id, approver, decided_at, policy_id, policy_version, action_hash and the task id. Stripe copies PaymentIntent metadata to the Charge it creates as a one-time snapshot, and includes metadata in webhook events, so the details travel with the payment.

• In your own append-only record: the full decision (allow or deny, reason code, caps and spend-so-far at decision time), the approval request and response, and the payment id once it exists.
• Never put card numbers, bank details or secrets in metadata. Stripe's docs say not to store sensitive information there.
• Record denials too. A pattern of denied payments is often the first sign of a prompt injection or a runaway loop.

What are the common failure modes?

The cap is enforced in the tool wrapper, but the agent also has a shell or HTTP tool and the API key in an environment variable, so it pays around the wrapper.

• Spend-so-far is read from the agent's memory or session state, which the agent can rewrite or lose on restart.
• Two parallel tool calls both read 'remaining budget 40' and each spend 30, because the check and the reservation aren't atomic.
• The approval is checked as 'some approval exists for this task' instead of 'an approval for this exact amount and payee', so a changed amount rides on the old yes.
• The approval is recorded in a chat thread, but nothing on the payment points to it, so months later nobody can tell which rule allowed a charge.