Conventional injection flaws re-enter systems at the point where a model's output rejoins an API pipeline, because that output is treated as internal when it never was. The reader leaves with a working boundary rule: validate at every crossing, not just at the front door.
The shape of the pipeline
A request arrives at an ordinary API. Some of it — a question, a document, a support ticket — gets handed to a model. The model replies, and that reply goes on to do something: it fills a database query, it names a file, it renders into a template, it becomes an argument to a shell command.
The validation happened once, at the start, on the human's input. Nobody validated the second half of the journey, because nobody thought of it as a second half. It looked like one request, front to back, and the checks at the door were assumed to cover the whole corridor.
The output nobody named
Ask an engineer where untrusted input enters their system and they will point at the API boundary — the form, the header, the JSON body a stranger posted. Ask where the model's reply enters and most will pause, because they never drew that line.
The reply arrives over an internal connection, in the expected format, at the expected stage. Every signal says trusted. None of those signals is about content.
The model's output is a transformation of whatever it was given, and increasingly that includes material it retrieved on its own — a document, a search result, a snippet from somewhere the original requester never touched. The reply carries that material forward whether or not anyone downstream asked for it.
Old failures, new doorway
None of the specific bugs are new.
A string bound into a query without parameters is a value that can close a quote and open a clause, whether a person typed it or a model produced it. A filename a model proposes can walk up a directory tree with the same ../ a person could have typed. A template that evaluates an expression after interpolation does not care whether the expression came from a form or from a paragraph.
What changed is where the value comes from, not what it does when it lands. Injection has always exploited the gap between this text sits inside my structure and this text is under my control. A model widens that gap, because it sits between the attacker and the sink, translating intent into a shape that looks native to whatever consumes it next.
Why a schema will not save you
A type check answers one question: is this value the right shape?
It does not ask whether the value is safe in the place it is about to go. A well-formed string can still be a query fragment, a path segment or an executable expression. The schema has no opinion on any of that, because none of it is a shape violation.
This matters more here than with a form field, because a schema-conforming reply feels reviewed. It passed a check, so it must be fine. The check confirmed structure, not intent — two properties that correlate often enough to be dangerous on the occasions they do not.
What actually holds
Validate at every crossing. Apply the same suspicion you would give a form submission, at the exact point the value is about to be used, rather than once upstream as a gesture.
Parameterise instead of interpolating. A bound parameter cannot close a clause it was never allowed to open. It is the fix that closed most injection two decades ago, applied to a query built from a model's reply instead of a person's.
Constrain to an enumeration wherever the valid set is knowable. If the field is one of five statuses, check membership rather than accepting free text and hoping.
Keep model output away from anything that evaluates. No template expression, no eval-shaped function, no command built by concatenation. If a value must reach one of those, it passes an allow-list first — not a filter trying to catch the bad cases.
Treat retrieved content as a second input. A document pulled in mid-task carries the same risk as text a person typed, because from the sink's perspective the two are indistinguishable.
The honest limit
None of this catches a model persuaded to produce a value that is well formed, inside the allowed set, and simply wrong.
A status that is valid but not the one the situation called for. A path that exists but points at the wrong record. Validation checks shape and membership. It has no way to check a value against a truth it was never given.
That gap does not close with more validation. It closes partially, with review of consequential actions and with limits on what a single reply may trigger unattended — a different problem, and not one a parameter check will ever solve.
Close
Seams leak because they are where the assumptions on each side stop matching.
Draw the boundary where the output actually crosses into execution, and the old defences still work. Skip it, and you have built a longer corridor with the same unlocked door at the end.