Output Injection Vulnerability

Issue

An agent constructs a downstream command, query, or markup document by directly interpolating its own generated text (or text derived from user/tool input the agent passed through) into a SQL statement, shell command, or HTML page without parameterization or escaping. Because the interpolated content can contain characters with special meaning in the target language, it can alter the structure of the command rather than being treated as inert data — the classic injection pattern, but with the agent’s own generated or relayed text as the injection vector instead of a raw user form field.

Frequency: Occasional

Symptoms

• SQL queries failing or returning unexpected result sets when a generated value happens to contain a quote or semicolon
• Shell commands executing unintended operations when generated arguments contain shell metacharacters (;, |, `, $())
• HTML pages rendering broken markup or executing unintended scripts when generated text containing <script>-like content is inserted unescaped
• Security scanning or penetration testing flags injection vulnerabilities specifically in code paths that use agent-generated content as a query/command argument
• Behavior that varies with the content of what the agent generates, not just its presence — the same code path is safe for most generations and unsafe for others

Root Cause

Agents frequently generate the final piece of a downstream command themselves — a WHERE clause value, a filename, a snippet of HTML — and because that content originates from the agent’s own reasoning rather than a raw external form field, it’s easy to treat it as inherently more trustworthy than user input and skip the parameterization/escaping discipline that would normally be applied. But the agent’s generated content can still contain arbitrary characters, either because it faithfully echoes attacker-controlled upstream content (a prompt-injected instruction embedded in a document the agent summarized, then interpolated into a query) or simply because natural business data legitimately contains special characters. When that content is joined into a command string via concatenation or an f-string rather than passed through a parameterized API, the target interpreter cannot distinguish “data” from “syntax,” and whatever the string happens to contain becomes part of the executed structure.

Example

A support agent looks up account details by generating a SQL query from
a customer's chat message, building it directly:

    ticket_ref = extract_ticket_reference(customer_message)
    query = f"SELECT * FROM tickets WHERE ref = '{ticket_ref}'"
    db.execute(query)

The agent's extraction step is asked to pull the reference number from
free text. A customer's message contains, buried in a copy-pasted email
thread, a line an earlier automated system had inserted:
"ref: ABC-1' OR '1'='1". The extraction step -- reasonably, given no
special handling for this case -- returns that full string as the
"ticket reference" it found.

The generated query becomes:

    SELECT * FROM tickets WHERE ref = 'ABC-1' OR '1'='1'

which returns every ticket in the table, not just one customer's. The
agent, having no additional validation, includes fields from all
returned tickets -- including other customers' ticket contents -- in its
next response, when it (following its instructions to "summarize the
found ticket") describes the first several results from the full-table
result set.

Statistics

Mitigations

1. Always use parameterized queries and structured command APIs: Never interpolate agent-generated or relayed text directly into a SQL string, shell command, or markup document; use parameterized query APIs, subprocess argument arrays (not shell strings), and templating engines with auto-escaping enabled.
2. Treat agent-generated content as untrusted as any user input: Apply the same escaping/parameterization discipline to text the agent itself produced or extracted as to raw external input, since the agent’s generation process can be influenced by untrusted upstream content (prompt injection) or simply reflect messy real-world data.
3. Least-privilege execution context: Run any database or shell operations the agent triggers under credentials scoped to the minimum necessary permissions, limiting blast radius even if an injection succeeds.
4. Output-context-aware escaping: When agent-generated text must be embedded in HTML, JSON, or another structured format, escape it specifically for that target context (HTML-entity escaping for HTML, JSON string escaping for JSON) rather than assuming plain-text-safe content is safe everywhere.
5. Static and dynamic scanning for interpolation patterns: Include automated detection (linting rules, SAST scanning) for string concatenation/f-string patterns feeding into query or command execution APIs, specifically in code paths that touch agent-generated content.

Production Signals

Key Metrics

Alerts

Related Patterns

• Output Sanitization Bypass - a related failure where a sanitization step exists but can be defeated, versus this pattern’s frequent absence of sanitization entirely
• Output Quote Escaping Failure - unescaped quotes are a common concrete mechanism by which injection succeeds
• Input Validation Bypass - both stem from an interpreter-boundary trust failure, one at the input gate and one at the output/execution boundary