In this note
The support assistant cannot change orders. Its tool is read-only. But the order it reads contains a restricted bank reference, and a fallback sends the whole response to the model when preparing a shorter version fails. No order changed. The wrong data still left the application.
I'd inspect what the application sends before adding another instruction to the prompt. By the time a model is asked to ignore a field, it has already received it. The hypothetical request below follows one record through that boundary; it is a paper design, not an executed security test.
Follow the fields out of the source
A customer asks support why an order is delayed. In this example, an internal worker may fetch the order record, including fields needed for other support tasks. The approved model task is narrower: explain the delivery status using the order ID, promised date, and latest carrier update. The selected model destination is approved for those fields only. The bank reference and private internal note must stay out.
| Field | May this explanation send it to the model? |
|---|---|
| Order ID O-41 | Yes, for this approved request and destination. |
| Promised date and carrier update | Yes, after checking the source version and current access. |
| Restricted bank reference | No. Omit it before building model context. |
| Private internal note | No. It is outside this explanation's approved fields. |
Prefer a source query or tool that returns only the needed fields. If the worker must handle a broader record, construct a new object from an explicit list of allowed fields before returning anything to the model. Don't remove two known sensitive fields and assume every future field is safe. A source update could add another restricted value. Free-text values also need the applicable content checks; an allowed field name cannot make everything inside it safe to send.
The source service checks whether the worker may fetch the order. The application service building the outbound model request has a separate job: check which of those fields may go to this destination for this task. It needs the verified caller and customer account, not a customer chosen by a tenant_id field in the model's request. If it cannot confirm the required access and handling policy, it must stop the disclosure and send the request to the permitted support path.
Check the path taken when preparation fails
The normal path builds the small allowed object. The tempting fallback says: if preparation fails, send the original response so the model can work it out. That puts both restricted fields back into the request. The fallback needs the same field and destination checks as the normal path; an error cannot grant broader permission.
| Case | What to check before accepting the design |
|---|---|
| Normal preparation succeeds | Only the approved order fields reach the approved model destination. |
| Preparation fails and fallback returns the raw record | Software blocks the request before the model call. No restricted field leaves through the fallback. |
| The model route switches to another provider | Use it only if that exact destination is approved for the task and fields; otherwise stop. |
| The tool returns an error containing the raw record | The model-visible error and ordinary logs omit prohibited values too. |
Use a recognizable synthetic marker in a field that policy prohibits. Force the fallback, then inspect the actual outbound request and confirm no model call received the prohibited value. Check errors and retries as well. A test that inspects only the normal object's keys would miss this failure. One marker can test a known path; it does not prove a detector recognizes every kind of sensitive data.
Look at the copies made along the way
The model request is one destination. Debug logs, traces, caches, saved answers, and exports can make other copies. For each, agree who may read it, why it is retained, and when it is removed. A log can record that a field check failed without storing the rejected bank reference. Someone investigating the failure may need access to a restricted source record rather than a copy in the general dashboard.
Check the model provider's data-handling arrangement separately. Permission to send selected fields does not settle retention, training use, region, or access to stored requests. Removing names also does not automatically make the remaining record anonymous or permit reuse for another purpose. Ask the responsible privacy and security owners to approve the actual route and handling rules.
If a prohibited value has already been sent, deleting a local cache cannot establish that every recipient deleted it. Stop the affected route, preserve a minimized incident record, and follow the approved response process with the owners of the destinations involved.
Inspect one request, including its failure path
Pick one read-only tool your application uses. With permitted test records, list the fields it fetches and the fields the model may receive. Then make preparation fail and inspect the request that would leave. Name the service that blocks extra fields before disclosure and the person who handles a stopped request. Keep the test marked not run until someone performs it against the actual software.