HTML/Script Injection in Tool Call Argument Targeting a Human-Approval Dashboard
An AI agent tool call can include a filename, command, or other text field that contains hidden HTML/JavaScript. If a human-approval dashboard displays that field without escaping it, the script runs in the reviewer's browser and can click 'Approve' on its own behalf, or send an approval message to the parent window, before any human actually reviews it.
How the attack works
An attacker crafts a tool-call argument (like a filename or command string) that contains a script tag or an HTML event handler such as onerror or onload. The approval dashboard renders this argument as raw HTML instead of treating it as plain text, so the embedded script executes in the browser of whoever is viewing the pending request. The script then calls the dashboard's own approve/decide endpoint directly, or sends a postMessage to the embedding window telling it to run the tool, effectively self-approving the dangerous action. This bypasses the human-in-the-loop check that was supposed to stop it, and it can use less obvious JavaScript patterns (like Image().src or form.submit()) to avoid keyword-based detection.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- ff093c48-c0f2-409d-807d-bc06341d86f5
- Severity
- High
Why it matters
An organization loses the safety net of human review for sensitive or destructive agent actions — a tool call that should require explicit approval gets waved through automatically, letting an attacker execute unauthorized commands or actions through the agent.
What you can do
- →Escape or sanitize all tool-call argument values before rendering them in any approval or review dashboard; never render them as raw HTML.
- →Serve the approval UI with a strict Content-Security-Policy that blocks inline scripts and event handlers.
- →Isolate the approval decision endpoint so it only accepts requests tied to an authenticated, user-initiated click, not arbitrary same-origin POSTs.
- →If the dashboard is embedded via postMessage, validate the origin and message structure strictly, and never let a message trigger tool execution without independent confirmation.
Known benign look-alikes
- Legitimate approval-dashboard UI code (server-authored, not an attacker-controlled tool argument) that itself defines the decide/approve POST handler
- Security test fixtures or unit tests for the approval dashboard that intentionally exercise XSS payloads in a controlled, non-production test suite
- Documentation or bug-report prose quoting this exact payload shape without an actual tool call carrying it