XSS Payload Injection in Tool Response Output
An AI agent can call external tools or skills and pass their output back to a chat window or dashboard. If that output contains script tags, event handlers, or javascript: links and the interface renders it without sanitizing it, the code executes in the user's browser just like a classic cross-site scripting attack.
How the attack works
An attacker controls or poisons a tool, plugin, or data source that an AI agent queries. The tool's response contains an XSS payload — a script tag, an onerror handler, or a javascript: URI — instead of plain data. The agent forwards that response to a web-based chat UI or dashboard as-is. Because the frontend renders the content as HTML rather than escaping it, the injected code runs in the victim's browser session.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 22f572a5-4141-4e4e-8fd1-5943c3c94f37
- Severity
- High
Why it matters
A working XSS in an agent's UI can steal session tokens, hijack the user's account, or take actions on their behalf inside the agent dashboard, using a trusted-looking tool response as the delivery mechanism.
What you can do
- →Treat all tool and skill output as untrusted input and HTML-escape or sanitize it before rendering in any web UI.
- →Use a strict content security policy that blocks inline scripts and javascript: URIs in the agent interface.
- →Render tool output as plain text or through a sanitizing markdown renderer rather than raw HTML.
- →Review any tool, plugin, or third-party data source that can inject content directly into the agent's displayed responses.
Known benign look-alikes
- Security audit reports listing XSS examples as findings (without live HTML rendering)
- Web development documentation explaining XSS in code blocks
- CTF challenge writeups containing harmless alert() demos in non-rendering contexts