TL;DR: As untrusted input, because anyone who can influence the model's context can shape it. Apply the control each sink needs: context-aware encoding and safe markdown rendering for browsers, parameterised queries on a least-privilege role for databases, no shell at all (named operations with validated arguments instead), schema validation and backend authorization for tool calls, destination allowlists for URLs. Best of all, have the model produce validated data and let code build the query or command.
How to approach it
State the principle in one sentence, then go sink by sink with the vulnerability class and its control. Finish with the design move that removes most of the risk: asking the model for structured data rather than executable text.
A strong answer
Influenced context
users, documents, web
Model output
attacker-shapeable
Sinks
browser, SQL, shell, tools
Per-sink control
Encode, safe markdown
- No raw HTML, allowlisted links
Parameterised, least privilege
- Read-only role where possible
No shell at all
- Named operations, validated args
Schema + backend authz
- URLs against an allowlist
Principle. Model output depends on the user's input and on any retrieved or tool content, so it has the same trust level as the least trusted text in the context. OWASP lists the failure as Improper Output Handling (LLM10 in the 2026 list, LLM05 in 2025).
Sink by sink.
| Sink | Class | Control |
|---|---|---|
| Browser (HTML, markdown) | XSS; exfiltration via images and links | Encode for context; sanitise rendered HTML with an allowlist; strict CSP; external images blocked or proxied |
| SQL | SQL injection | Model emits parameters, code builds a parameterised query; read-only role; views scoped to the user |
Shell, eval, interpreters | Code execution | Never pass output to them; offer named operations with typed arguments; sandbox if code execution is the product |
| Template engines | Server-side template injection | Output is data in a template, never template source |
| URL fetching | SSRF | Allowlist destinations; egress proxy; block private and metadata addresses |
| File paths | Path traversal | Canonicalise and confine to a directory |
| Tool calls | Unauthorised actions | Schema validation, authorization with the user's identity, policy limits |
The structural move. Most of these risks disappear when the model never writes code. For an analytics assistant, have it produce {metric: "revenue", range: "last_quarter", group_by: "region"}, validated against an enum, and compile that into SQL yourself. For a DevOps assistant, expose restart_service(name) with an allowlist rather than a terminal.
Where to enforce. At the sink, in code that runs after the model, so that it applies however the output was produced.
What interviewers probe next
- "Can't we ask the model to only output safe HTML?" That is an instruction to a component the attacker can influence. Encode at the sink.
- "What if generated SQL is a core feature?" Validate the statement (parse, allow only SELECT on approved views), run with a read-only role scoped to the user, enforce timeouts and row limits, and log every query.
- "Which sink is most often missed?" Markdown rendering, because teams think of it as display rather than as an interpreter that makes network requests.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A developer pipes model output straight into a SQL query, an HTML page and a shell command in different features of the same product.
Start here
Why is model output untrusted even when your own prompt produced it?
What text could have steered the output?
The output is shaped by everything in the context, including user input, retrieved documents and tool results that attackers can write. A model can also simply produce wrong or malformed output. So model output is attacker-influenced data, and every interpreter it reaches (database, browser, shell) needs the same handling as user input.
Carry it forwardModel output is attacker-influenced input to the next interpreter.
Weak answerTrusting output because the developer wrote the prompt.
Constraint changes
What if the SQL feature uses parameterised queries for values the model chooses?
Which parts of a query cannot be parameters?
That stops SQL injection through those values, because the query's shape is fixed before data is bound. Check that identifiers (table and column names) are not model-chosen, since they cannot be parameterised and need an allowlist. And authorization still matters: a well-formed query can still read rows the user should not see.
Carry it forwardParameterise values, allowlist identifiers, authorize rows.
Weak answerThinking parameterisation also solves authorization.
Constraint changes
What if the shell feature quotes the model's text?
What happens if an argument begins with a dash?
Quoting is fragile: one mistake, a different shell or an argument that starts with a dash can turn data into options or commands. Avoid the shell entirely by calling programs with argument arrays, validate arguments against expected formats, and run in a sandbox with minimal privileges.
Carry it forwardAvoid shells; pass argument arrays and sandbox.
Weak answerRelying on string escaping for shell safety.
Constraint changes
What if the HTML feature renders model output as markdown?
What can markdown turn into in the browser?
Markdown renderers can emit raw HTML, links and images. Without sanitisation, output can carry script (cross-site scripting) or auto-loading images that exfiltrate data. Render with a sanitiser that strips raw HTML, restrict link and image destinations, and apply a strict content security policy.
Carry it forwardRendered markdown needs sanitisation and URL controls.
Weak answerAssuming markdown is safe because it is not HTML.
Constraint changes
What if the model returns JSON that matches the expected schema?
Can a well-formed object still be malicious?
Schema validity means the shape is right, not that the values are safe or permitted. A valid JSON tool call can still target another user's record or an attacker's URL. Validate values against business rules and authorization after parsing.
Carry it forwardValid structure is not safe content.
Weak answerTreating structured output as validated output.
Now defend it
What rule would you set for model output in this codebase?
Treat model output as untrusted input to whatever consumes it: parameterised queries with allowlisted identifiers and row-level authorization; no shells, argument arrays in a sandbox; sanitised markdown with restricted URLs and a strict content security policy; and schema validation followed by business-rule checks. Add tests that feed hostile output into each sink.
How it's scored
Weak: Suggests prompting the model to produce safe output or filtering for bad keywords.
Hire: Maps each sink to its classic vulnerability class and control.
Strong Hire: Adds markdown exfiltration and SSRF, proposes structured outputs instead of generated code, and limits blast radius at each sink with least privilege.
Common mistakes
- Treating output from "our own model" as trusted.
- Sanitising markdown syntax instead of the rendered HTML.
- Giving generated SQL a read-write role.
- Validating tool calls in the client or in the prompt.