The browser treats attacker-controlled markup as trusted HTML, which can turn a chat transcript into stored XSS. That means scripts, iframes, and attribute-based payloads may execute in another user’s session, especially when the content is replayed in support tools or admin views. The failure is in the render path, not the model output itself.
Why This Matters for Security Teams
Un-sanitized AI-generated Markdown fails at the boundary between content and code. Once a renderer upgrades attacker-controlled text into trusted HTML, the application stops treating the transcript as data and starts executing it as page content. That creates a straightforward path to stored XSS, but the practical impact is broader: session theft, privilege abuse in admin consoles, poisoned support records, and persistence across shared views.
This risk is especially relevant for chat exports, ticketing workflows, and knowledge bases that replay model output for multiple users. Guidance from the NIST Cybersecurity Framework 2.0 still applies here, but the control failure is specific: the render path needs its own trust boundary. NHI Management Group has highlighted how sensitive content can be reproduced and amplified once systems start reusing unsafe output, and the State of Secrets in AppSec research shows how quickly security assumptions erode when content pipelines are fragmented. In practice, many security teams discover the issue only after a seemingly harmless transcript has already been opened in a privileged interface.
How It Works in Practice
Markdown is not inherently safe. Many renderers support raw HTML, embedded links, images, tables, or extension syntax that can be abused if the application fails to sanitize output before it reaches the browser. The problem becomes acute when the system renders assistant messages, pasted prompts, or imported transcripts inside authenticated workflows such as support desks, moderation queues, and internal admin tools.
A safe implementation usually needs several layers:
- Sanitize or strip raw HTML before rendering, rather than trusting the model to avoid dangerous markup.
- Use a renderer that disables script-capable features by default and applies a strict allowlist for tags and attributes.
- Escape content on output, then render only the minimum formatting that the use case requires.
- Apply a restrictive Content Security Policy so even accidental HTML does less damage.
- Treat links, images, and embedded objects as untrusted inputs and validate them separately.
For implementation guidance, compare your pipeline against the browser-facing trust boundaries implied by OWASP Top 10 and align runtime controls with NIST Cybersecurity Framework 2.0. The lesson from DeepSeek breach is not that Markdown is dangerous by itself, but that unreviewed content paths can expose far more than the original message intended. These controls tend to break down when multiple services re-render the same content with different parsers, because one weak link can reintroduce executable markup.
Common Variations and Edge Cases
Tighter sanitization often increases development and product overhead, requiring organisations to balance richer formatting against lower execution risk. That tradeoff becomes visible when teams want mentions, embeds, or custom Markdown extensions that improve usability but also expand the attack surface.
Best practice is evolving for AI-specific rendering pipelines, and there is no universal standard for this yet. A conservative approach is to separate trusted system content from model-generated text, then render untrusted output in a constrained container with no raw HTML support. This matters even more in environments where the same transcript is replayed across roles, because a payload that is harmless to one user can become executable for another with broader permissions.
Edge cases include pasted content from rich-text editors, cached chat logs, and automated summaries that merge multiple sources into a single page. Those flows often bypass the original sanitization step or reintroduce unsafe fragments during export. The practical pattern is simple: if the content can be edited, forwarded, or re-rendered, it should be treated as hostile until the final browser response has been sanitized and escaped.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers unsafe agent output and downstream execution in rendered content. | |
| OWASP Non-Human Identity Top 10 | NHI-08 | Highlights insecure handling of non-human produced content and tokenized outputs. |
| NIST CSF 2.0 | PR.DS-2 | Addresses data integrity and safe handling of content before display. |
| NIST AI RMF | Supports governing AI outputs across the lifecycle and limiting harmful downstream effects. | |
| CSA MAESTRO | Applies to controlling agent output risk in multi-component AI workflows. |
Sanitize all model-generated markup before browser rendering and restrict executable content by default.
Related resources from NHI Mgmt Group
- What breaks when AI-generated code is reviewed without security gates?
- What breaks when AI-generated code reaches authentication and authorisation logic without stronger verification?
- What breaks when analysts rely on AI-generated detections without structured testing?
- What breaks when AI-generated mobile apps are shipped without security review?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
