Give a Service Agent Refund Access Without Exposing Every Order

Consider a staging test called the damaged-blender run. A customer says a blender arrived cracked, asks for a refund, and requests that the shipping address on the account be corrected before another order is placed. The service agent must inspect the order, determine whether the request fits policy, prepare the refund, and propose an address change.

Those steps look like one support conversation to the customer. They are separate security decisions to the systems behind it.

The useful unit of access is not “customer service.” It is a particular action on a particular resource at a particular stage. Least privilege, the practice of granting only the access needed for a task, means the agent may read the damaged-blender order without gaining authority to refund it, and it may prepare an address patch without being able to apply that patch.

That separation matters because the language model is not the authority. It interprets the request and proposes tool calls. An orchestration layer, the software that routes those calls and tracks workflow state, should decide whether each call is allowed.

Turn one support job into separate permissions

Start with a permission matrix rather than a list of tools. For each business object, define what reading, drafting, and executing mean in backend terms.

| Object | Read | Draft | Execute | |---|---|---|---| | Refund | Retrieve eligibility, payment status, prior refunds, and policy inputs | Create a proposed amount, reason code, destination, and supporting record | Submit the refund through the payment or order system | | Order | Retrieve items, fulfillment state, shipment status, and permitted customer details | Prepare a cancellation, replacement, return, or order note | Commit the approved order mutation | | Account edit | Retrieve fields needed for the current case | Prepare a field-level patch showing old and proposed values | Apply only the approved fields to the account |

A draft must be a stored business object, not prose sitting in the model’s context window. For the damaged-blender run, the refund draft should contain the order identifier, proposed amount, refund destination, policy result, and a version reference to the order state the agent inspected. The address draft should identify each field to change. Neither draft should mutate a production record.

This design prevents a common permission leak. If a single `update_customer` function accepts arbitrary fields, an agent authorized to correct a shipping address may also be technically capable of changing an email address, phone number, or account recovery field. Replace that broad interface with field-specific operations or enforce an allowlist at the policy gateway, the service that checks a tool request against permissions and workflow state.

Read access also needs boundaries. The agent handling a cracked product may need fulfillment details and a masked payment reference, but it does not automatically need full payment data, unrelated orders, internal fraud notes, or every account field. Return the smallest response shape that supports the decision. Filtering only what appears in the prompt is weaker than filtering at the API, because the broader data has already crossed the boundary by then.

Keep execution outside the model

The model can request an action. It should not possess a credential that guarantees the action will happen.

In the damaged-blender run, the orchestrator first calls a read-only order endpoint using an identity limited to support retrieval. The model then produces a structured refund proposal. A deterministic policy check compares that proposal with current order state and support rules, after which a human or an automated approval rule records a decision. Only then does the orchestrator request permission to execute.

The execution path should verify several facts together: the approved operation, the target order, the exact draft version, the permitted endpoint, and whether the approval remains valid. If the customer changes the requested refund destination after approval, the old approval should no longer match. The agent must create a new draft rather than editing the approved payload on the way to the tool.

Give the final backend call an idempotency key, a unique value that lets the service recognize a retry of the same operation. Without one, a timeout can leave the orchestrator unsure whether a refund succeeded, and an automatic retry may submit it twice. On an ambiguous response, the fallback is to query transaction status using the key or hand the case to a person, not to generate a fresh refund request.

Tool descriptions are not security controls. Telling a model that it “must obtain approval” may improve behavior, but the refund endpoint still has to reject an unapproved call. Customer text, retrieved documents, and model output are untrusted inputs; none should be able to widen scopes, select a more powerful credential, or mark their own approval record complete.

Use temporary credentials for narrow execution

A broad service token creates ambient authority, meaning any code that holds it can use all of its permissions whether the current task needs them or not. If that token can read orders, issue refunds, and edit accounts, a prompt injection or orchestration bug can turn one compromised conversation into access across the support system. Rotation limits how long a stolen token works, but it does not narrow what the token can do while valid.

Temporary credentials are safer when execution is occasional, high impact, or tied to an approval. After the damaged-blender refund is approved, a credential broker can issue a short-lived credential restricted to the refund operation, the selected order, and the approved payload or draft identifier. The credential expires after a brief window and cannot authorize the separate address edit.

Implementations vary. An OAuth access token can carry narrow scopes and a short expiration, while a signed capability token can bind authorization to a resource and action. Some systems keep the temporary credential entirely inside the orchestrator and expose only a higher-level execution result to the model. That is preferable to placing bearer tokens in prompts, tool arguments, traces, or conversation history, where logging and replay create extra exposure.

Short-lived credentials are not free. Issuance adds a network call, expiration can interrupt a slow approval, and the broker becomes critical infrastructure that needs monitoring and a failure path. A service may also need to exchange the temporary credential for a backend-specific identity, adding more latency before execution. For frequent, low-risk reads, a narrowly scoped reusable identity may be simpler and adequate.

The cutoff is not merely whether an action writes data. A reusable token for a tightly constrained endpoint that can only append an internal case note may present less risk than temporary issuance. Refunds, order cancellations, shipment changes, and edits to identity or recovery fields deserve stronger isolation because a mistaken call changes money, fulfillment, or account control. Teams should classify the endpoint’s effect, then choose the credential lifetime.

Bind approval to the draft, not the conversation

Human review becomes weak when the approval screen shows a summary generated by the same model that proposed the action. The reviewer should see the backend-derived order identifier, current state, proposed mutation, policy result, and the exact fields that execution will send.

For the address portion of the damaged-blender run, the screen should display old and new values side by side. Approval should cover that stored patch only. If execution begins after another process has changed the account, the backend can reject the patch through version checking and send the case back for review. This costs another read and may frustrate an agent working through a queue, but it prevents stale drafts from overwriting newer data.

Automatic approval can still fit least privilege. A policy engine may approve a permitted class of low-impact refunds or order changes, provided the execute credential remains bound to the resulting draft. The model should not decide that its own case qualifies by writing an approval flag. It supplies evidence; separate code evaluates the rule.

Account edits often need a stricter path. Changing a delivery preference is not equivalent to changing an email address used for login or recovery, even if both appear in the same customer table. Split those operations at the API boundary, require stronger verification for sensitive fields, and remove fields from the agent’s schema when it has no reason to touch them.

Test denials before testing the happy path

A successful damaged-blender run proves little by itself. The useful tests ask whether the system refuses close variants: a refund credential used against another order, an approved amount replaced before execution, an expired token replayed, an address-only permission sent to an email endpoint, or a second execution attempted with the same approval.

Record each transition in an audit log with the requesting service identity, tool name, target resource, draft version, policy decision, approval source, credential identifier, and backend result. Keep model reasoning separate from authoritative evidence. Free-form reasoning can help debug a run, but it should not be the only record showing why money moved.

Also test partial failure. The refund may succeed while the account edit fails, leaving the agent tempted to rerun the entire plan. The orchestrator should persist step status, verify the completed refund through the backend, and resume only the failed address step. If state cannot be reconciled, stop execution and create a human handoff containing the draft and tool results.

Questions people ask

Can a customer-service agent issue refunds without human approval?

Yes, if a separate policy engine authorizes a defined class of refunds and the execution credential is limited to the approved draft. The agent should not grant itself that authority, and requests outside the policy should stop at the draft stage for review.

Why not give the agent one service account with limited API scopes?

A reusable service account can work for narrowly scoped, low-impact reads. It becomes risky when the same credential spans unrelated customers or mutable operations, because theft or misuse retains every granted capability until the token expires or is revoked.

What happens when a temporary credential expires during execution?

The orchestrator should check whether the backend completed the operation before requesting another credential. If completion is uncertain, it should query with the original idempotency key or hand the case to a person rather than submitting a new mutation.

What should the audit log show for an executed refund?

It should link the customer case, order, immutable refund draft, policy decision, approval record, temporary credential identifier, idempotency key, and backend result. That chain lets an operator distinguish a model proposal from the exact action the payment or order system accepted.