A new post on DEV.to challenges the prevailing architecture of LLM tool use, arguing that raw HTTP responses from external tools must never be fed directly into the model's context window. The core thesis is stark: a tool result is not context. It is untrusted input that happens to arrive over HTTP.
The Injection Risk in Raw Responses
When developers paste the raw body of a tool response into the next model turn, they are effectively letting a third-party JSON blob pick the model's next action. This opens the door to prompt injection attacks where the external API returns malicious or misleading text that hijacks the LLM's reasoning process. The model, trained to follow instructions in its context, treats the raw bytes as authoritative rather than treating them as data to be inspected.
Schema Projection as the Solution
The proposed fix is to cap the bytes, pin the content type, and project the payload onto a schema the model is allowed to see. Instead of passing a massive, unstructured JSON object, the system should extract only the specific fields relevant to the current task. This projection step acts as a firewall, stripping away any unexpected keys or values that could confuse the model or introduce adversarial content.
Key Takeaways
- Treat all tool outputs as untrusted input, not trusted context.
- Never feed raw HTTP bodies directly into the LLM prompt.
- Cap the size of the response to prevent context window flooding.
- Pin the content type to ensure you are parsing what you expect.
- Project the payload onto a strict schema before passing it to the model.
The Bottom Line
If you are letting a third-party API decide what your model sees next, you have already lost control of the inference. Stop pasting raw JSON. Validate, project, and cap.