Insecure output handling is what happens when a model response is trusted by whatever consumes it next.
The model is not the vulnerability here, the code downstream of it is.
Think of the model as an untrusted user who can be persuaded to write absolutely anything.
Rendered as HTML without escaping, a response can carry a script that runs in your user's browser.
Concatenated into a SQL statement, it is an injection in the classic database sense.
Passed to a shell, it becomes remote code execution with your service account's permissions.
Used as a file path, it can walk out of the directory you intended with a few dot segments.
Returned as a URL and fetched by your server, it can reach internal addresses that were never meant to be public.
The pattern is always the same, and it is output crossing into a system that parses it as instructions.
The defences are the ordinary ones, applied in the ordinary places.
Escape on render, parameterise every query, and pass argument arrays rather than assembled shell strings.
Validate against an allowlist of shapes you expect instead of scanning for patterns you fear.
Parse structured output into a typed object and reject anything malformed rather than repairing it.
Give the downstream system the least privilege it can work with, so that a slip stays survivable.
Injection and insecure output handling are the same bug seen from opposite ends of the request.