MITRE ATLAS AML.T0077 LLM Response Rendering: Detection, Mitigation and Response

When an assistant's answer contains an image or link built by an attacker, the user's own client can send private data out the moment the answer is displayed, with no click and nothing visible. MITRE ATLAS tracks this as AML.T0077 LLM Response Rendering, in the Exfiltration tactic (AML.TA0010). ATLAS describes getting an LLM to respond with private information hidden from the user when the client renders it, typically as an image hosted on an adversary-controlled server whose URL parameters carry the data, with HTML tag and markdown variants. Secure output handling in general (escaping, sinks, a baseline Content Security Policy) is covered in the OWASP LLM Top 10 LLM05 Improper Output Handling Guide, and broader controls in the LLM Security Guide. This page treats rendering as an exfiltration channel: every route the case studies show, how to close each one, how to detect use of it, and how to respond. It is for teams that build or run chat interfaces, copilots and agents, and for SOC analysts who will be asked whether data left.

Key takeaways

• The client is the exfiltration tool. The model never makes a network call; the browser, chat app or link preview service fetches the URL the model wrote.
• Allowlists are only as good as their least-controlled entry. Case studies show data leaving through an attacker-usable script on a vendor-owned domain, trusted preview services and an expired allowlisted domain.
• Every automatic fetch counts. Images, link unfurling, previews and DNS lookups for a hostname all carry data without a click; clickable links add a social engineering route.
• Close the channel deterministically. Our view, in line with Microsoft's July 2025 description of blocking markdown image exfiltration deterministically, is that rendering rules belong in code, not in the prompt.
• Proxy and DNS logs answer the incident question. Image and preview fetches to unusual hosts with long query strings or subdomains are the evidence of what left.

How the channel works

ATLAS created AML.T0077 in April 2025 and rates it as demonstrated. It usually follows indirect prompt injection (AML.T0051.001): the instructions arrive in a web page, shared document, email or record the assistant reads, and tell the model to place conversation content or retrieved data into a URL inside its answer.

What the case studies show

• Images in a consumer chat assistant (AML.CS0021): Embrace the Red showed in May 2023 that content retrieved by a ChatGPT plugin could make the model output a markdown image whose URL carried the conversation, rendered automatically. The author recommended implementing image display as a dedicated feature rather than through markdown, and isolating plugins from conversation context.
• A trusted domain in the CSP (AML.CS0029): in the Google Bard case, ATLAS records that the request was allowed by the Content Security Policy because the attacker's script was hosted as a Google Apps Script on a Google-owned domain. Google fixed the issue.
• A clickable link with a secret (AML.CS0035): in the Slack AI case, a prompt in a public channel post led the assistant to render a "click here to reauthenticate" link with a private API key encoded in the URL.
• Trusted services past link filtering: in EchoLeak, reference-style markdown images survived link redaction and Microsoft services allowed by the CSP fetched the attacker's address. Microsoft fixed it server-side.
• An expired allowlisted domain: in ForcedLeak, data was written into an image URL on a domain still on the CSP allowlist after it had expired and been re-registered. Salesforce enforced Trusted URLs and secured the domain.
• DNS and unfurling: the SalesBleed disclosure described data placed in a subdomain so the DNS lookup carried it out, and a second route through chat link unfurling. Salesforce fixed the reported issues before disclosure.

Closing the channel

Work through the routes in the table in order of how automatic they are. This is the sequence we recommend.

1. Decide whether model output may contain images at all. Many enterprise assistants do not need model-chosen images. If yours does not, strip image syntax from model output after parsing it with a proper markdown and HTML parser, including reference-style definitions.
2. If images are needed, proxy them. Fetch images server-side through an image proxy that allows only exact approved hosts, drops query strings, and never forwards conversation data. Users' browsers then fetch only from your proxy.
3. Set a strict Content Security Policy. MDN documents that img-src controls where images may load from and falls back to default-src when absent. Set img-src to your own origin and proxy, set connect-src tightly, and avoid wildcard hosts on shared platforms where other tenants can host content.
4. Audit the allowlist. Check every allowed domain for expiry, ownership and whether third parties can publish content on it, on a schedule and whenever the list changes. See the Content Security Policy Guide.
5. Turn off unfurling for AI output. Disable link previews on messages an agent posts into chat platforms, or route them through the same allowlist.
6. Treat links as untrusted. Display the real destination domain, remove query parameters on external links, and never let generated text present a sign-in or re-authentication prompt.
7. Limit what is available to leak. Retrieval permissions, sensitivity labels and short conversation context reduce the data an injected instruction can reach; Microsoft's post lists data governance as an impact mitigation.

Test each change with harmless canary strings: put a unique marker in a test document, ask the assistant to include it in an image URL, and confirm nothing reaches an external host in proxy or DNS logs. Roll out behind a feature flag so rendering can be restored quickly if a legitimate workflow breaks.

Detection and measurement

ATLAS mitigation AML.M0024 AI Telemetry Logging covers model inputs and outputs; for this technique you also need network evidence from the client side.

D3FEND D3-OTF Outbound Traffic Filtering and D3-DNSDL DNS Denylisting are the network countermeasures; CSP violation reports, sent with Content-Security-Policy-Report-Only during tuning, give early warning of blocked attempts.

Measuring it

• Rendering policy coverage: share of AI interfaces that strip or proxy model-supplied images.
• Allowlist hygiene: allowlisted domains reviewed in the last quarter, with expiry and ownership checked.
• Blocked render attempts: output filter and CSP blocks per week, investigated within a target time.
• Canary result: pass or fail of the external-fetch canary test on every release.

Response runbook

1. Confirm the channel: from completion logs, find the response with the URL; from proxy, DNS and CSP reports, confirm whether a fetch happened.
2. Decode what left: extract and decode parameters or subdomains from the logged request to determine the data exposed.
3. Block: add the host to proxy and DNS deny lists, remove it from any allowlist, and tighten the output filter.
4. Find the source: locate the document, page or record carrying the injection, quarantine it and sweep for similar items.
5. Handle exposed secrets: if credentials or API keys left, revoke and rotate them and review their use since. The Investigating Agent-Initiated Data Exfiltration guide covers evidence and scoping.
6. Notify if required: personal data exposure may trigger breach notification duties; follow the Prompt Injection Incident Response Playbook.

Common failure patterns

• Regex link filtering: inline links are removed but reference-style markdown or raw HTML survives.
• Vendor-wide allowlists: allowing a large provider's whole domain, including services where anyone can host content.
• Stale allowlists: domains left on the list after a product or campaign ends, then re-registered by someone else.
• Forgetting non-browser fetches: link unfurling, preview services and DNS lookups left out of the threat model.
• Prompt-only defence: telling the model not to output images instead of enforcing rendering rules in the client.

Framework mapping

Practitioner checklist

• Decide per interface whether model output may render images, and strip them where not needed.
• Parse markdown and HTML properly before filtering, including reference-style links.
• Proxy any allowed images server-side with exact host allowlists and no query strings.
• Set img-src and connect-src tightly and collect CSP violation reports.
• Review every allowlisted domain for expiry, ownership and third-party hosting each quarter.
• Disable link unfurling on agent-posted messages.
• Show real destination domains and strip parameters on external links.
• Run an external-fetch canary test on every release.

Standards and references

• MITRE ATLAS: LLM Response Rendering (AML.T0077)
• MITRE ATLAS: Google Bard Conversation Exfiltration (AML.CS0029)
• MITRE ATLAS: Data Exfiltration from Slack AI via Indirect Prompt Injection (AML.CS0035)
• OWASP: Top 10 for LLM Applications 2025
• MDN: Content-Security-Policy img-src
• Microsoft MSRC: How Microsoft defends against indirect prompt injection attacks
• Embrace the Red: ChatGPT plugins data exfiltration via images

Related NHI Mgmt Group resources: LLM Security Guide, OWASP LLM Top 10 LLM05 Improper Output Handling Guide, Agent Egress Control and Network Isolation Guide, MITRE ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation.