How to control AI agent spending

Give each spending agent an owner, a purpose, and access to an approved payment account.

Keep test and production permissions separate. A support agent issuing credits should not inherit the permissions of a procurement agent paying suppliers.

In Conto, each agent has its own identity and can be linked to specific wallets, policies, SDK keys, and approval flows.

Decide who can register an agent, assign its payment account, and change its spending rules.

Give payment credentials only the permissions needed for the task. Keep policy administration with an authorized owner or administrator.

Record who changes a budget or approval rule so the responsible team can review it later.

Card limits and expense reports can help control employee spending. Agents also need checks on the recipients and repeated purchases they choose during a task. We discuss these needs in The Enterprise is the Biggest Opportunity for Agentic Payments.

Every production agent should have hard limits.

For many teams, the first useful policy is a three-tier rule: routine spend clears, payments above the approval threshold but below the hard limit need approval, and spend above a hard cap is denied. The same structure shows up in Conto's policy engine.

Choose approved recipients as well as spending limits. A $20 payment to a known provider and a $20 payment to a new wallet may need different decisions.

Review changes to saved payment details. Block excluded recipients and decide whether new recipients need approval.

Use available recipient history and risk information as inputs to your rules. A trust score does not guarantee safety.

Choose which requests need a person’s approval.

The better pattern is approval by exception. Route a payment to review when it crosses an amount threshold, uses a new recipient, falls outside normal hours, fails a trust check, or makes an unusual number of payments in a short time.

Show the amount, recipient, triggering rule, and deadline. Keep the reviewer’s decision with the request.

A support agent resolves a billing issue and requests a $12 credit for an existing customer.

An example policy allows credits below $25, requires approval from $25 through $100, and blocks amounts above $100. Recipient and payment-frequency rules still apply, even to a small credit.

The record shows which rule applied, who approved the request if needed, and whether the credit completed.

Choose whether Conto manages payment execution or your own system signs and sends.

With a managed wallet, Conto checks the request before signing and sending. With an external wallet, your payment system must require Conto authorization, send the approved payment, and report the result. Conto cannot stop transfers that bypass that check.

A retry loop can repeatedly charge a paid API or request the same payment.

Set limits on payments per minute or hour and spending per service. Use alerts for repeated failures and a freeze rule when the workflow needs to stop.

Monitor pending approvals, new recipients, changed payment details, and rapid budget use while the task is running.

Assign someone who can review alerts and stop the connected payment process.

An audit trail should answer a plain question: why did this payment happen?

Keep the request, amount, recipient, rule result, approval, and final payment status together.

Test an approved payment, a blocked payment, and a request held for review. Check both the returned decision and what the wallet did. A successful payment alone does not prove blocked requests stay unpaid.

Do this in a sandbox with a real agent, real policy logic, and realistic payment context. The docs walk through the same approach in Testing Payments Safely.