Prompt injection boundaries
Check destinations as well as the requested operation
An allowed export operation can still send the wrong data to the wrong place. Review destination resolution, redirects and payload scope together.
In this article
A valid operation is only part of the decision
An assistant is permitted to create a report. That says nothing about whether it may send the report to an address found in a supplier document. The operation, data selection and destination each need an authority rule.
Prefer application-owned destination records where the workflow allows it. The model can refer to an approved workspace identifier while the server resolves the actual endpoint. This avoids asking generated text to supply security-sensitive routing details.
Do not use a destination's friendly name as proof of identity. A label such as "finance workspace" can be copied into untrusted material. Resolve it through the authenticated organisation's configuration and verify the caller's permission to use it.
Follow the network request
If arbitrary external URLs are genuinely required, the executor needs a deliberate network policy. Validate the permitted scheme and destination, and account for redirects and address resolution. A URL that initially appears acceptable can lead somewhere else during the request.
Use established server-side request forgery controls appropriate to the runtime and network. The exact implementation needs review against the platform, especially where internal services or metadata endpoints are reachable. A text instruction telling the model to avoid private addresses is not a network boundary.
Also inspect libraries that fetch previews, images or attachments from generated output. They can create outbound requests even when no explicit export tool is present.
Limit the payload independently
A permitted destination does not justify sending every available field. Build the export from an allowlisted set of records and fields authorised for the task. Avoid forwarding the entire model context or raw tool response for convenience.
For example, a supplier-facing comparison might contain the selected supplier's own quote details but exclude internal scoring and competing proposals. The application should construct that distinction from trusted records. Asking the model to remember which fields are confidential is insufficient.
If a person approves the transfer, show the actual destination and a meaningful payload summary. Bind the approval to those values. A later generated change to the attachment list or endpoint should require a new decision.
Test the complete transfer
Use controlled destinations to exercise a permitted route, a denied route and a redirect. Verify what bytes arrive, not just whether the tool returned success. Repeat with a valid destination and an unauthorised record to ensure data scope is checked separately.
Record the destination identity, permitted payload scope and operation result without placing sensitive contents in broad logs. The review is complete when the team can explain both why the transfer was authorised and what prevents external text from changing that decision.
Primary sources
OWASP: server-side request forgery preventionOWASP: authorisation guidanceReferences checked 11 September 2026.