PIP-014
Rendered-output exfiltration
The injected instruction makes the model emit a link or image reference that leaks data to an attacker when the interface renders it.
How it works
Interfaces commonly render model output as rich text. If the model can be induced to place data into a URL, the client requests that URL on render, transmitting the data without the user clicking anything. The model never sends the data; the interface does.
Why it works
The vulnerability lives in the renderer, not the model. Automatic rendering of model-authored references turns any successful injection into a data-exfiltration channel.
What it looks like
An instruction to summarise something sensitive and include it as a parameter in a reference to an attacker-controlled host, styled to look like an ordinary citation or tracking pixel.
Described rather than reproduced. This library publishes mechanisms, not payloads: recognising a class of attack and choosing a control does not require a working copy of it.
Defences
Do not auto-load model-authored references
Architectural
Block automatic requests to arbitrary hosts from rendered output. Allow-list the origins that may be fetched on render. This closes the channel outright and is the single highest-value fix here.
Apply a content security policy to the rendering surface
Architectural
Constrain where the interface may fetch from, so a reference to an unexpected host cannot be resolved even if it is produced.
Treat model output as untrusted input
Architectural
Encode and validate model output before it reaches any renderer, exactly as you would content from any other external source.
Framework mapping
- LLM01:2025 · OWASP LLM Top 10
- LLM02:2025 · OWASP LLM Top 10
- LLM05:2025 · OWASP LLM Top 10
Mappings are asserted only where the identifier is known correct, and omitted where uncertain. Last reviewed 2026-08-03.