A prompt is a terrible spending limit

I would be more comfortable giving an AI agent a tightly controlled company card than giving it an unrestricted payment tool and a paragraph that says “be careful.”

The second setup can produce a convincing demo. Ask the assistant to buy supplies, watch it find a reasonable option, approve the result. The harder question comes afterwards: what prevents a different result when the price changes, a request gets retried, or two jobs run at once?

If the only answer is that the agent was told to stay within budget, the budget still needs implementing.

The payment industry is asking who is accountable

On October 7, 2026, the PCI Security Standards Council announced additional guidance for AI in payment environments. Its announcement emphasizes access controls and responsibility as systems gain independence. It also explicitly says the guidance is not a set of mandatory requirements; official PCI standards take precedence.

For a business commissioning an agent, that raises a useful engineering question: which decisions belong to the model, and which must be enforced by the application that carries out the purchase? A model can compare products and explain a recommendation. The authority to commit company money deserves its own implementation.

Write the rule where the purchase happens

Consider an illustrative office-supplies assistant. The business permits purchases from two approved suppliers, with a $150 limit per order and a $500 monthly allowance. Those figures are examples, not suggested limits for every company. The assistant can search catalogs, prepare a basket and explain why it chose the items.

Before placing an order, the application checks the supplier, final amount including delivery and tax, currency, remaining allowance and the authorization for that purchase. Requests outside the permitted scope are rejected or routed for a specific human decision. The agent cannot raise its own limit by editing its instructions.

That separation is consistent with OWASP’s guidance on excessive agency, which recommends enforcing authorization in downstream systems instead of leaving the permission decision to the language model. The practical test is simple: deliberately request something outside the allowance and check what the purchasing system actually does.

The permission should match the job. An assistant that recommends supplies may need catalog access and the ability to create a draft basket. It does not automatically need permission to change supplier bank details, add payment methods or manage every employee’s account. Build the smaller tool when the task is smaller.

The awkward cases belong in the demonstration

Suppose $480 of the monthly allowance has already been used. Two jobs each prepare a $20 purchase. If both read “$20 remaining” before either records its order, they can both appear valid. The application needs to reserve spending against the same shared allowance as one coordinated operation. A reassuring sentence in two separate chats does not resolve the collision.

Then consider a timeout. The supplier may have accepted an order even though your application never received the response. Repeating the purchase with a fresh identity can create a duplicate. The team needs a stable order reference, a way to check the original outcome and a defined retry process.

Stripe’s idempotency documentation provides one concrete example of retry protection: supported requests can reuse a key so a retry returns the earlier result rather than repeating the operation. Its retention and endpoint rules matter. That mechanism does not make an entire shopping workflow duplicate-proof, and a different supplier may offer different guarantees.

I would ask to see an over-budget request, two simultaneous requests and a missing response before accepting this kind of automation. Use a sandbox or controlled test environment. A test should show the supplier-side result as well as the agent’s explanation; a friendly “done” message cannot establish how many orders exist.

Make an approval mean something precise

A button marked “Approve” is only useful if the person knows what it authorizes. Show the supplier, items, quantity, total, currency and delivery details. Tie the approval to that version of the order. If the basket changes after review, check it again against the permitted scope instead of treating an old click as unlimited consent.

Repeated purchases need equally clear boundaries. A recurring allowance should say who granted it, what it covers, when it ends and how it can be revoked. Decide which changes need fresh approval. Otherwise, a workflow intended to save someone a few minutes can quietly acquire authority nobody meant to delegate.

Keep enough of a record to connect the user’s instruction, the authorization, the attempted operation and the supplier’s final response. Redact secrets and unnecessary personal information. The useful record answers what happened and why it was permitted; storing every chat message forever is not the objective.

Give the business a way to stop

The owner should be able to stop new purchases and revoke the relevant access without waiting for another conversation with the agent. Be clear about the limit of that control: stopping future work may not cancel an order already accepted by a supplier. Someone still needs a process for reconciliation, cancellation and refunds where available.

This is where I would spend part of the implementation budget. A more capable model may choose better products. It cannot compensate for a purchasing connection that accepts anything carrying the right credential.

If you are planning an agent that can buy, refund, publish or change business records, start by writing down what it is allowed to commit and how you will test the boundary. Rosecraft’s AI integration work can turn that scope into application behavior. Tell us which task you want to delegate and what a wrong action would cost. That is the conversation to have before handing over access.