AI Guardrails in Operations: Check the Proposal, the Total and the Outcome

Thirty-seven refunds worth 8,400 have gone through overnight. Each was below the assistant’s 300-per-action limit. Nobody set a combined limit. This is a fictional failure, with all amounts in the same unspecified currency, but it exposes a familiar gap: checking one request does not control the whole run.

The finance lead needs to know what happened and stop further exposure while legitimate customer cases still receive timely attention. “Tell the model to be careful” cannot provide that control. Permissions, approvals and transaction rules must work even when the assistant misunderstands a message.

This closes our three-part series: part 1 chooses agent work and part 2 follows an MCP connection. Here we put one proposed action through a control process that can be inspected and tested.

Write the boundary before choosing the threshold

For each task, name the owner, permitted records/fields, allowed operation, financial or customer impact and recovery path. A conversational agent acts within the intersection of user rights, delegated tool scope and current policy. An unattended service needs its own limited identity, owner and review. Neither gets a shared administrator login.

Controls belong in the application and downstream services. Hiding a menu or asking the model to obey a sentence is insufficient. Apply access checks to every tool call and to retrieved context, caches, output and logs. Internal notes and external messages can both contain hostile instructions; neither can grant new authority.

Choose limits using realistic loss and legal/business obligations, not a neat example copied from a blog. Include per-action value, aggregate value, action count, concurrency, data export, runtime and model spend. Technical reversibility is only one factor: cancelling a reservation later does not restore a lost sale.

Approve an exact proposal, not a moving target

In this example the agent may prepare a refund proposal, not release money. An authorised finance reviewer sees the original payment, eligible remaining amount, currency, customer remedy, destination, reason, supporting evidence and proposed change. Required separation of duties is enforced; another agent cannot supply the human approval the policy requires.

Bind approval to the exact action, target, amount, currency, destination and version, with validity conditions. A meaningful change invalidates it. Recheck access, payment eligibility, remaining refundable balance and policy at execution, including other refunds already pending. Do not let a different draft reuse the approval.

Previews and dry runs help reviewers, but a simulation is not a payment result and does not lock future state. Show evidence a reviewer may actually access, plus unresolved uncertainty. Give the queue owners and deadlines, escalation and staffing. A cap must route an owed refund for prompt authorised handling, not silently deny customer rights.

Monitor review quality, sampled correctness and delays. High acceptance is not proof of good judgement, and a zero-rejection rate alone is not proof of rubber stamping. Reduce unnecessary approvals where policy allows, but never replace a required approval with a later sample check.

Reserve the shared budget before concurrent actions escape it

Suppose an illustrative execution cap is 500 for a declared period and currency. Already committed or reserved exposure is 340. Two separately approved proposals, A and B, each request 100. If both read “160 left” before either updates the total, both could pass and create exposure of 540.

The business system must check and reserve the shared allowance atomically, so concurrent requests cannot both spend the same capacity. If A reserves first, exposure becomes 440 and only 60 remains; B’s proposed total 540 exceeds the example cap and goes to an authorised exception queue. Approval alone does not override that execution rule.

Define which confirmed, in-flight and uncertain operations count, the period/timezone, currency conversion where relevant and who may change limits. Keep uncertain exposure reserved until reconciled; release only after a verified failure/cancellation under policy. A duplicate retry of A must reuse its reservation, not consume another 100. Rate limits alone do not implement this financial cap.

A timeout is not a failed refund

The provider may accept a refund before the response is lost. Store the operation reference and query the existing result before creating another request. Reconcile provider status, amount and the local record; a submitted, pending, succeeded, failed or unknown refund is not the same outcome.

An idempotency key identifies retries of one logical operation with the same intended payload. It needs durable local tracking, atomic duplicate protection and correct provider support. It does not catch the same business request submitted with a fresh key, and provider retention is not necessarily permanent. See Stripe’s idempotency documentation as one provider example, not a universal contract.

Retry only eligible transient failures with bounded exponential backoff, jitter, attempt/time budgets and an owner for unresolved status. Permission denials, invalid inputs and changed proposals need correction or new approval. Do not silently invent a new payment reference because a response is slow.

A completed refund is not a one-click undo. Cancellation depends on provider, method and state; an accounting reversal cannot pull money back from a customer. Stripe’s refund guidance describes limited cancellation cases. An incorrect completed refund needs an authorised resolution, not an unapproved new charge.

Keep evidence that survives a stopped run

Record the requester and acting identity, delegated scope, source references/times, proposal/version, policy decision, approver, operation ID, provider reference, result transitions and correction links. Where available record model, tool, prompt and policy versions; a model alias alone may not reproduce a past response. Ask for concise evidence-based explanations, not hidden chain-of-thought.

Create an attempt record before execution and update it with confirmed outcomes, including refusals and failures. Design for what happens if logging is unavailable before a high-impact action. Protect records against unauthorised edits, audit privileged changes and use tested tamper-evident/retention controls where required. An append-only label alone does not prove nobody can alter storage.

Limit readers and exports, redact sensitive content and agree retention/deletion policy. A reference with necessary evidence is often safer than copying every message. More logs are not automatically better. Blocked-attempt counts can reflect tests or configuration errors, not necessarily a malicious customer.

A kill switch prevents new work within a defined scope. It cannot recall an already accepted bank operation. Test stopping, draining or cancelling queued work, revoking relevant access and identifying in-flight outcomes. A circuit breaker should use explicit signals, an accountable responder and controlled recovery; an alert does not investigate itself.

Test the controls, then test changes to them

Use representative cases and adverse tests: another store’s record ID, an instruction hidden in a supplier file, stale approval, changed destination, two concurrent budget requests, duplicate calls, provider timeout and unavailable audit storage. Use synthetic or authorised protected data. A single successful injection test does not prove immunity.

Compare expected permissions and business outcomes, not just fluent text. Include languages, partial refunds, abstentions, false blocks and customer deadlines. Choose sample sizes for risk and rare events; “fifty cases” is not a universal acceptance standard. Rerun after model, tool, prompt, policy or material data changes; a better average must not hide a critical regression.

Roll out to one team with named reviewers and a tested stop/recovery process. Track verified errors, unauthorised disclosures, unresolved outcomes, review turnaround, aggregate exposure and total operating cost. Preserve human-led fallback when the provider fails. Version rollback restores software behaviour where possible; compensating a business action is a separate decision.

Use frameworks without treating a checklist as certification

NIST AI RMF is a voluntary risk-management reference. ISO/IEC 42001 addresses an organisational AI management system. Neither a cited framework nor a vendor badge proves every model answer or workflow is safe; inspect actual scope and evidence.

Legal duties depend on use, jurisdiction and your role. EU AI Act Article 50 has defined transparency obligations and exceptions; employment or credit uses need separate classification. Do not infer that every ordinary ERP action has the same legal logging/disclosure duty. Check the applicable current text before relying on a deadline.

The practical policy below is a starting structure, not a ready-made legal or spending authority. Finance, operations and security owners must agree the actual limits, reviewers, deadlines and recovery responsibilities.

Task	Before execution	Recovery responsibility
Stock answer	Permitted records/fields and evidence time	Correct the answer; investigate disclosure if any
Purchase draft	No hidden send/reservation; buyer reviews exact version	Withdraw draft under policy; handle any real side effects
Refund proposal	Payment/eligibility, authorised approval and shared execution limits	Finance reconciles provider status; no assumed undo
Internal tag or reservation	Assess downstream effect, scope, volume and allowed reversals	Owner confirms actual recovery; do not promise one-click repair
Payroll, bank change or accounting correction	Separate approved business process; no open-ended agent authority	Named accountable owner and controlled correction process

What the finance lead should find in the morning

The goal is an explainable queue: which requests were proposed, approved, held, executed or left uncertain; what exposure remains; and who owns each next step. In the example, the shared cap can hold B while A’s actual outcome is reconciled. That depends on the controls being correctly implemented and tested, not on a guarantee that every similar message triggers an alarm.

The agent can still prepare useful work. The business has a bounded way to approve it, observe what actually happened and handle exceptions without losing the customer or the evidence.

Reviewed 5 November 2026. Anichur Rahaman is the creator of StoreConsole. The retailer, refund totals and allowance example are fictional teaching scenarios.