Model-generated Markdown can become stored XSS in chat features

At a glance

What this is: Escape shows that model-generated Markdown in customer-facing chat can become stored XSS when raw HTML is rendered without sanitization.

Why it matters: IAM and security teams need to treat AI output as untrusted content because rendered model responses can expose sessions, configs, and same-origin data through the browser.

Context

Model output becomes a browser security problem when product teams treat it as trusted formatting rather than untrusted content. In chat and support workflows, Markdown renderers, HTML passthrough, and downstream widgets can turn a harmless-looking conversation into executable page content, especially when the output is shared, replayed, or escalated across roles.

The identity angle is real even though the flaw is in the render chain: a model can emit content that affects the browser session of another user, including administrators or support staff. That makes AI-assisted chat a governance issue for application security, IAM-adjacent trust boundaries, and any programme that lets generated content cross privilege lines.

Key questions

Q: What breaks when model-generated Markdown is rendered with raw HTML enabled?

A: The renderer stops treating the model’s output as inert text and turns it into browser-executable content. That creates stored XSS when the output is saved, replayed, or shared with another user. The core failure is not the model itself. It is the missing trust boundary between generated text and active DOM construction.

Q: Why does stored XSS in AI chat matter more when privileged users read transcripts?

A: Because the payload executes in the browser of whoever opens the conversation, not only in the attacker’s browser. If that viewer is support staff or an administrator, the script can inherit a more powerful session context and reach same-origin data, configuration, or actions that the attacker could not access directly.

Q: What do security teams get wrong about sanitising model output?

A: They often sanitise too early or trust a single library to cover every downstream render step. In multi-stage rendering chains, one plugin can reintroduce active HTML after an earlier filter has already run. Teams need to validate the final DOM after all Markdown, embed, and formatting transformations have completed.

Q: How should teams govern AI chat features that render Markdown?

A: Treat them as application security features with explicit render governance, not as harmless UI polish. That means reviewing which elements and attributes are allowed, disabling raw HTML where possible, sandboxing embedded documents, and testing every place the model output is re-used across the product.

Technical breakdown

Why raw HTML inside Markdown becomes executable

Markdown is not inherently dangerous, but many renderers preserve raw HTML for features such as tables, embeds, and formatted code. When a pipeline uses a raw-HTML plugin and skips sanitization, the browser receives real elements instead of inert text. That matters because the renderer is no longer formatting content. It is constructing DOM the application later trusts. In chat systems, the payload can arrive from a model, be stored with the conversation, and be replayed to a different user. The security failure is the trust handoff between generated text and active browser markup.

Practical implication: Treat model output as untrusted input and remove raw HTML rendering unless a sanitizer is enforced after every transformation stage.

Why srcdoc and similar attributes bypass simple filtering

The article shows why tag allowlists alone are not enough. Some dangerous behaviour hides in attributes, not tags, and iframe srcdoc is especially risky because it contains an entire document, not just a URL. A filter that blocks script tags but allows an iframe with srcdoc can still hand the browser a new document that executes in the page’s origin unless sandboxing is enforced. The same issue appears with event handlers and URL-bearing attributes. Defensive review has to cover the element, the attribute, and the order in which the renderer rewrites content.

Practical implication: Review attribute-level HTML handling and force sandboxed iframes when any embedded document capability remains.

Why chat pipelines create stored XSS beyond the chat window

AI chat features are only one rendering surface in a larger product chain. The same generated content may appear in tickets, support consoles, dashboards, notification emails, export views, or collaboration tools, often with different owners and inconsistent controls. That multiplies the chance that one unsafe renderer becomes many unsafe renderers. In practice, the problem is not a single widget. It is a render graph with multiple consumers, each capable of turning model output into active content. Once any one of those consumers trusts the output, the storage layer becomes a delivery mechanism for browser compromise.

Practical implication: Inventory every place model output is rendered and apply the same sanitization and browser-control policy at each hop.

Threat narrative

Attacker objective: Trigger script execution in another user’s browser from stored model output so that the attacker can access privileged browser-resident data or actions.

1. Entry occurs when attacker-influenced content reaches the model prompt or conversation flow and is emitted as Markdown in a chat response.
2. Credential or browser-state exposure follows when the frontend renders that response with raw HTML enabled and no sanitizer, allowing active markup to execute.
3. Impact occurs when the payload runs in the next viewer’s browser and can reach same-origin data, session material, or application configuration.

Breaches seen in the wild

• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Generated text is now a first-class attack surface: When a model writes content that the browser later interprets as markup, the trust boundary shifts from user input to model output. That changes how teams should think about application security reviews, because the issue is not whether the user typed a script tag. It is whether any generated text can survive the render chain as active HTML. Practitioners should treat output rendering as part of the security model, not as presentation logic.

Render-chain governance is the named concept here: A chat feature is safe only if every transformation stage is known, ordered, and constrained from model output to DOM. Escape’s finding shows how one permissive plugin and one missing sanitizer can create a browser-execution path even when the surrounding application appears well structured. That means teams need governance over rendering pipelines, not just content filters. Practitioners should map every output hop before they assume the model is harmless.

AI chat expands the blast radius of stored XSS: The risk is not confined to the user who prompted the model. Shared transcripts, support workflows, admin consoles, and downstream exports can all replay the same payload into a more privileged browser session. That makes the business impact broader than a single vulnerable widget and ties the issue back to access control assumptions. Practitioners should assume any stored model output may be re-rendered under a different privilege context.

Identity boundaries matter because browsers carry the privilege: Once malicious markup executes in the origin of the application, the browser becomes the enforcement point for access to session state, configuration objects, and same-origin resources. That is an identity problem as much as a web security problem, because the browser session is where privilege is exercised. Practitioners should align AI feature governance with session protection and same-origin containment.

Security teams should not wait for scanners to flag these paths: The article shows that documented libraries can be combined in unsafe ways without looking obviously broken in code review. That is why render-path testing, not component inventory alone, has to become part of release gates. Practitioners should validate the final rendered DOM with malicious payloads, not just inspect package names or plugin lists.

What this signals

Render-chain governance has become a release discipline: Teams that ship AI chat, support replay, or assistant-driven workflows need to know exactly where generated content is converted into HTML. The dangerous pattern is not limited to one chat widget, because every downstream consumer can become a second renderer. Practitioners should build render-path inventories into change control and release approval.

A browser-origin XSS in AI output channels behaves like a privilege boundary failure, not just a content bug. Once the payload reaches the next viewer, the application’s own origin becomes the attacker’s execution context, which is why session protection, same-origin policy, and output sanitisation have to be governed together.

Model output surfaces need the same assurance mindset as external inputs: If a feature can store, replay, or export generated text, it needs testing against hostile markup, attribute abuse, and embedded-document tricks. Practitioners should assume that any place a model can write text may also become a place a browser can execute it.

For practitioners

• Remove raw HTML from model-rendered Markdown Disable HTML passthrough in chat and assistant output unless there is a documented business requirement that survives security review.
• Sanitize after every transformation stage Apply HTML sanitization after any Markdown, rehype, syntax-highlighting, or embed plugin that can change the tree before it reaches the browser.
• Inventory every model-output render path Map where generated text appears in chat, tickets, dashboards, emails, exports, and support tooling so you can test each renderer separately.
• Constrain iframe and attribute handling Block dangerous attributes such as srcdoc and require sandboxed iframes when embedded content cannot be removed from the product design.
• Test the final DOM with hostile payloads Verify the live application origin using payloads that target the rendered output, not just the source markdown or the component library.

Key takeaways

• Model-generated Markdown can become stored XSS when raw HTML rendering and missing sanitization turn chat output into executable browser content.
• The same issue can recur across multiple product surfaces because chat transcripts, support tools, and exports often reuse the same render chain.
• Teams should govern model output as untrusted input, disable raw HTML where possible, and test the final DOM after every transformation stage.

Key terms

• Stored Xss: Stored XSS happens when an application saves malicious script in backend content such as comments, profiles, or posts, then serves it to other users later. Because the payload persists, one successful injection can trigger repeated execution across many authenticated sessions.
• Markdown renderer: A Markdown renderer converts formatted text into HTML for display in web applications. In security terms, it is a transformation boundary that must be treated as untrusted when it processes model output, because permissive plugins can turn styling features into execution paths.
• Sanitisation: Sanitisation is the process of transforming or constraining input so it can be used safely. In application security, this usually means validating structure, escaping dangerous characters, or otherwise neutralising untrusted data before it reaches a sensitive operation. Effective sanitisation must match the context of the sink.
• Render chain: A render chain is the full sequence of parsing, transformation, and display steps that turn source text into what a user sees. Security teams need to govern the entire chain because a safe input can become unsafe again after later plugins, templates, or embeds modify it.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It helps security and identity practitioners build control thinking for emerging AI-enabled systems and the access paths they create.