What breaks when an AI assistant renders untrusted responses into HTML during streaming output?

Where streaming HTML rendering becomes dangerous

When an ai assistant streams its answer into a browser and the output is inserted as HTML, the application is no longer handling inert text. It is handling content that can change the page structure while the page is still being built. That matters because HTML is not just presentation: it can introduce links, forms, image requests, script-adjacent behaviour, and unexpected DOM changes if the renderer trusts the stream too early.

The practical failure is usually a trust-boundary mistake. The assistant output is treated as if it were already safe because it came from a model or because it will be sanitized later, but streaming means the browser may see intermediate fragments first. A partial tag, malformed markup, or a deliberately crafted closing sequence can affect how the browser parses what follows. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need for explicit input validation, output encoding, and secure system processing rather than assuming later cleanup will always save the render path.

In practice, many security teams discover this only after a live chat interface has already rendered attacker-influenced markup into a real browser session.

What the browser and renderer are actually doing

Streaming output changes the security model because the renderer must decide, on each chunk, whether the content is plain text, safe markup, or something that should never reach the DOM. If the application appends raw chunks directly into the page, the browser can start interpreting structure before the full answer is complete. That is the core hazard: the model can emit content that is harmless as text but dangerous when parsed incrementally as HTML.

The breakdown often comes from one of three places. First, the application sanitizes only after the full response finishes, which leaves a window where unsafe content is already visible or actionable. Second, the application attempts to sanitize chunk by chunk, but partial tags or entity boundaries cross chunk boundaries and defeat the filter. Third, the application assumes that only obvious script tags are dangerous, while event handlers, malformed nesting, resource-loading tags, and link-based abuse still create security exposure. In a browser context, even non-script HTML can produce unwanted requests, interface tampering, or credential-phishing surfaces.

• Chunk boundaries matter because the dangerous object may only become valid when two or more fragments are combined.
• Sanitization must be aligned to the final parsed structure, not just the visible text of a single stream event.
• Escaping output as text is safer than allowing HTML unless rich formatting is strictly required.

Where this guidance breaks down is when a product genuinely needs rich assistant-generated markup and has no reliable, server-side structure enforcement before the browser receives it.

Why edge cases make streamed markup harder to secure

Tighter rendering controls often reduce interactivity and formatting flexibility, requiring teams to balance user experience against the risk of parser abuse.

One edge case is markdown-to-HTML conversion during streaming. Teams sometimes assume that because the source format is not raw HTML, it is automatically safe. That is not consensus practice. Converting partially complete markdown into HTML mid-stream can still produce unstable DOM output, especially when links, code fences, or embedded HTML are resolved before the message ends. Another edge case is a hybrid renderer that shows a “typing” preview with rich formatting and then replaces it with a finalized message. If the preview path is less protected than the final path, the weaker path becomes the exploit path.

There is also a tradeoff between real-time responsiveness and security assurance. The more eagerly the interface paints streamed content, the less time there is to validate structure and strip dangerous elements. Teams that need live updates should prefer constrained render modes, such as plaintext streaming with post-completion rendering into a safe component, rather than letting untrusted HTML shape the live page. The same principle applies when the assistant response is later copied into another system, because unsafe markup can persist beyond the original chat surface.

Practitioners should treat any streamed HTML path as a separate attack surface, not as a harmless UI detail.

Risk and Threat Considerations

Untrusted HTML in a streaming assistant creates a client-side injection and content integrity risk. The key exposure is that the browser may act on attacker-influenced markup before the application has finished validating or constraining it, which can turn a chat response into a delivery path for active content.

Failure mechanism: The control fails when partial output is appended directly to the DOM, or when sanitization is delayed until after parsing has already occurred. Chunked content can cross parser boundaries, allowing unsafe tags, attributes, or resource-loading elements to become meaningful in the browser even if the final response would have been cleaned later.

Impact: The page can be visually manipulated, external resources can be requested, user trust can be abused, and in the worst case the session can be exposed to script-capable injection paths depending on surrounding browser protections and application settings.

Practitioner Guidance

What to prioritise: Treat streamed assistant output as untrusted text until the final response has been assembled and checked. If rich formatting is required, constrain it to a rendering path that is explicitly designed for safe, allowlisted markup rather than general HTML.

What to verify: Verify that sanitization happens before any content reaches the browser parser, not after the first chunk is displayed. Also verify that chunk boundaries cannot split tags or attributes in ways that change the meaning of the rendered output.

Common mistake: The usual error is to secure the final message while leaving the streaming preview path less protected. That creates two different trust levels for the same data, and attackers naturally target the weaker one.

Practitioner takeaway: If the UI can render before the response is complete, security must be designed around the parser’s behaviour, not the model’s intent.

Related resources from NHI Mgmt Group

• What breaks when remote images are auto-fetched inside AI assistant responses?
• What breaks when an AI assistant can access private data and untrusted content at the same time?
• What breaks when an AI assistant accepts gateway settings from untrusted URL parameters?
• What breaks when an AI agent is compromised during active execution?