Spot the data-exfiltration vector in this assistant response

The line that looks like a friendly account-status message is hiding a data-exfiltration attack. The Markdown syntax  embeds an image whose URL points to attacker-controlled infrastructure. The query string of the URL contains the user's email and a token. When the chat UI renders the response, it issues an HTTP GET to that URL to fetch the image. That GET carries the query string. The attacker's server logs the GET and now has the user's email and token. No click happens; no attachment is uploaded; the data leaks at render time. This is almost certainly the result of indirect prompt injection: a document, tool response, or earlier message convinced the model to embed this image as part of its output. The injection payload told the model to put the user's data in the URL. The fix is on the output rail. Strip Markdown image and link tags whose target host is not on an allowlist. Strip query parameters from URLs the model emits. Refuse to render inline images at all, or render only static placeholders, in any chat surface that handles sensitive data. The key idea is that Markdown is not cosmetic; it is an outbound network channel.

The response contains a **Markdown image tag** that points to attacker-controlled infrastructure with PII and a token embedded in the query string. The vector is: ```  ``` When the chat renderer parses this Markdown, it issues an HTTP GET to attacker.example.com to fetch the image. The GET carries the entire URL including the query string, so the attacker's server logs the user's email and the token. The attack succeeds at render time with no user interaction. **Root cause.** Almost always indirect prompt injection. A retrieved document, a tool response, an earlier turn, or a malicious system-prompt component instructed the model to construct an exfiltration URL by interpolating user data into the query string. The model thought it was emitting an inline image; what it was actually doing was issuing a server-side outbound side-channel. **The output rail must do three things.** - **Allowlist image and link domains.** Only render images whose host is on a small explicit allowlist. Block all others, do not auto-rewrite. - **Strip query parameters from emitted URLs.** Even on allowlisted hosts, forbid query strings on rendered links unless they match a known-safe pattern. - **Refuse arbitrary URL emission near sensitive context.** If the model output includes PII, secrets, or session tokens anywhere, treat any URL in the same response as suspect and quarantine the response for review. **Equally important.** The same vector exists for plain Markdown links ([click here](https://...)). Image tags are worse because they auto-fetch without user click; links require a click but achieve the same exfiltration once clicked. The output rail handles both.