Treat model output like input from an anonymous user. Each place it lands, called a sink, has its own control: parameterised queries for SQL, context-aware encoding for HTML, no shell evaluation at all, and path validation for files. OWASP calls the failure to do this Improper Output Handling.
Why output needs the same care as input
Prompts can steer what a model writes. So anyone who can influence the prompt, directly or through content the model reads, can influence what reaches your database, browser or operating system. OWASP says this is similar to giving users indirect access to extra functionality.
The risk grows when the model holds more privileges than the end user should, when the app is open to indirect prompt injection, and when third-party extensions do not validate their inputs.
Sink by sink
OWASP's examples map cleanly to controls:
- Shell, exec or eval: what goes wrong Remote code execution; control Do not pass model output to them
- Browser: what goes wrong XSS from generated JavaScript or Markdown; control Context-aware HTML encoding, strict CSP
- SQL: what goes wrong Injection or destructive queries; control Parameterised queries, prepared statements
- File paths: what goes wrong Path traversal; control Validate and canonicalise, allowlist directories
- Email templates: what goes wrong Phishing or script content; control Escape output for the template context
The first four rows are drawn from OWASP's list. The path allowlist wording is general engineering practice rather than OWASP text.
Design rules that apply to every sink
- Prefer structured output that code validates against a schema over free text that code interprets.
- Give the model narrow, specific tools instead of one open ended command runner.
- Run generated code, if you run it at all, in a sandbox without network or credentials.
- Log outputs and watch for unusual patterns.
The destructive SQL scenario deserves a note. If a user asks for a query that deletes tables and it runs unchecked, the failure is not that the model complied. The failure is that the application executed it. A read-only database account would have limited the damage.
Generated code is output too
OWASP also notes that generated code can introduce SQL injection or reference hallucinated packages that may be malicious. Code review and package verification apply, the same as for any other contribution.
Safeguard's dependency scanning and SBOM tooling covers the package side of that, and its fix PRs are off by default with every category on Manual.
Common mistakes. Teams often validate for the sink they thought of first. A model that writes a report for a web page also ends up in a log viewer, an email and a spreadsheet export, and each has its own injection form. List every consumer of model output, not just the main one. Another frequent gap is trusting output because it came from your own model. The model is not the author of that text in any meaningful security sense. Whoever shaped the prompt is.
Quick check
Is escaping model output enough?
Only if the escaping matches the context. HTML encoding does not protect a SQL query, and the reverse is also true.
Should the model ever write directly to the shell?
Avoid it. If a task truly needs it, sandbox the execution and require approval.
Sources
Last reviewed: 19 October 2026.
