Output validation for MCP tools means checking what a tool sends back before that content reaches the model's context, not just checking what the model sent to the tool in the first place. Teams naturally focus on the outbound direction of a tool call, since that's where an action actually happens. But the response coming back, a document, a search result, an email body, a database row, becomes part of the model's context for its very next decision, and if that content is malicious or sensitive, the model can't tell the difference between legitimate data and something crafted to manipulate it. Output is a genuine attack surface, and it's the one most integrations check the least.
Treat tool responses as untrusted content, not verified fact
A model has no inherent way to distinguish a tool's legitimate data from text an attacker planted specifically to be picked up by that tool. A support ticket, a web page, an email thread, any of these can contain text written to look like an instruction, and once it lands in the model's context it gets read with the same weight as a real instruction unless something upstream flags it. Validate and, where appropriate, clearly label tool output as data rather than instruction before it's added to context.
Watch for instructions embedded inside returned content
The clearest version of this risk is a document or message that contains text like an instruction aimed at the model reading it, telling it to ignore its previous guidance or take some additional action. This is indirect prompt injection delivered through the tool-response channel specifically, and it's exactly why output validation deserves its own attention separate from input validation on the way out.
Check for sensitive data that shouldn't propagate further
A tool built to answer one narrow question can sometimes return more than intended, an entire record instead of a single field, internal metadata alongside the requested content, or details from other users' data mixed into a shared result set. Validate that a tool's actual output matches its intended, narrow scope before passing it along, rather than assuming the tool's own logic already enforced that boundary correctly.
Bound the size and structure of what gets returned
An unexpectedly large or malformed response can be a sign something's wrong upstream, and passing it straight into a model's context unchecked can also just waste context space or degrade the quality of the model's next decision. Set reasonable limits on response size and structure, and treat responses that violate those limits as worth a second look rather than passing them through by default.
Log what actually came back, not just what was requested
Recording the tool call request without recording its result leaves half the picture missing during an investigation. Log the actual response content, or at least enough of it to understand what the model saw, so a later review can tell whether a bad decision downstream was caused by manipulated or unexpected tool output.
Prefer structured output formats over free-form text where possible
A tool that returns structured data, specific fields with defined types, is easier to validate and easier to reason about than one that returns a blob of free-form text a model has to interpret on its own. Structured output also makes it easier to programmatically strip or flag fields that shouldn't propagate further, whereas free-form text mixes data and potential instructions together in a way that's much harder to cleanly separate once it's already been generated.
Test with content specifically crafted to manipulate the model
Reviewing a tool's output format on clean, expected data tells you little about how it behaves against a document deliberately built to carry an injected instruction. Include adversarial content in your testing, a web page, an email, a file, written specifically to see whether the model treats it as data or mistakenly follows it as an instruction, and use those results to tighten sanitization before the tool ever handles real, unpredictable content in production.
Where TELEON fits
TELEON's audit trail can capture both sides of a tool call passing through the gateway, the request and the result, giving teams the ability to review what a model actually saw from a tool after the fact, which matters specifically for investigating indirect prompt injection delivered through tool responses.
Building the specific sanitization logic for a given tool's output format and identifying what "normal" output looks like for that tool is still work that depends on the tool owner's domain knowledge.
A short checklist
- Treat every tool response as untrusted content before it enters the model's context.
- Scan returned content for text resembling instructions aimed at the model.
- Check that a tool's actual output matches its intended, narrow scope.
- Set size and structure limits on tool responses and flag anything that exceeds them.
- Log both the request and the result of every tool call for later review.
- Test tools against documents and data crafted to carry hidden instructions.
- Review output handling whenever a tool's underlying data source changes.
Output validation gets skipped far more often than input validation, mostly because it's less obvious that data flowing back into a model's context is a security-relevant event at all. It is, every time, because that content shapes whatever the model decides to do next, and a model that reads a manipulated tool response has effectively received new instructions from a source nobody in the room actually approved.