For the past two years, the conversation around prompt injection has centred on the model. Better alignment, stronger system prompts, safer fine tuning, and output guardrails have all aimed to make language models more resistant to malicious instructions. Those improvements have made a real difference, yet prompt injection remains one of the most persistent security risks in production agent systems.
The attack begins when your agent treats external content as context instead of untrusted input. Browser results, retrieved documents, and MCP tool responses all flow back into the model's reasoning, giving attacker controlled content the same opportunity to influence the next tool call as any other information in the context window.
That points to a different conclusion. In agent systems, the primary attack surface isn't the model. It's the tool call chain that allows untrusted content to re-enter your agent's reasoning.
In this article, you'll see why model level defences fall short, where the real enforcement point sits, and how treating tool boundaries as security boundaries gives you a more effective way to defend against prompt injection.
How the industry has been framing the problem
Prompt injection has remained the top risk in the OWASP Top 10 for LLM Applications since the project launched in 2023. Even so, much of the conversation has focused on making the model itself more resistant through alignment, stronger system prompts, fine tuning, and output guardrails. The latest OWASP LLM01:2025 guidance notes that techniques such as RAG and fine tuning do not fully mitigate prompt injection, suggesting the problem extends beyond model behaviour.
That focus is reflected in the research. A recent systematic review of prompt injection defences found that many proposed mitigations centre on model focused techniques such as adversarial training, prompt engineering, and preference optimisation. The underlying assumption is simple: if your model is better trained, your system prompt is stronger, or your guardrails are more effective, the attack should stop there.
That assumption made sense when your application was little more than a chat interface. A user sent a prompt, the model generated a response, and the interaction ended. Once your agent starts browsing the web, retrieving documents, or calling MCP tools, that assumption no longer holds because your model is no longer reasoning over user input alone.
Security guidance is beginning to reflect that shift. The OWASP MCP Top 10 now includes risks such as Tool Poisoning and Prompt Injection via Contextual Payloads, recognising that the attack surface extends beyond the model and into the systems supplying it with information. To understand why, you first need to follow how prompt injection moves through an agent.
The Actual Attack Surface
Imagine you ask your agent to summarise the latest Kubernetes security guidance from a documentation site. To complete the task, the agent calls an MCP browser tool, fetches the page, and feeds the result back into the model before deciding what to do next.
Now that page contains hidden text instructing the agent to ignore its previous instructions, retrieve credentials from another connected tool, and send them to an external server. Those instructions did not come from you. They arrived as part of the tool response.
The diagram below shows how that untrusted content flows back into your agent's reasoning loop.
This is where the threat model changes. The model does not receive the tool result separately from the rest of its context. It reasons over your instructions, conversation history, retrieved content, and tool responses in the same inference pass. Unless something inspects that tool result before it reaches the model, the injected instructions become part of the context used to decide the next action.
That distinction matters because the attack does not begin with the model. It begins when attacker-controlled content crosses the boundary between the external world and your agent's reasoning loop. By the time the model sees the injected instruction, your system has already treated that content as trusted context. That is the boundary you need to protect.
Why model layer fixes do not hold
Once you follow the attack path, the limitations of model layer defences become easier to see. Fine-tuning, system prompts, and output guardrails all improve different parts of an agent, but none of them changes how untrusted content enters the reasoning loop. They operate after the architecture has already treated external content as trusted context.
Take fine-tuning. You can train a model to resist malicious instructions and improve its ability to recognise unsafe requests, but you cannot train it to recover information that no longer exists. By the time a browser result or MCP tool response reaches the model, the trust boundary has already disappeared. The model receives tokens, not metadata explaining which ones came from your system and which ones came from an attacker.
System prompts have a similar limitation. They influence the model's behaviour, but they are not an enforcement boundary. Your instructions, conversation history, retrieved documents, and tool results all become part of the same inference context. As discussed in our article on Claude Managed Agents, a stronger system prompt cannot prevent untrusted content from entering the reasoning loop because it lives inside that same loop.
Output guardrails arrive even later. They inspect what the model produces after it has already reasoned over the injected content and decided which tools to call. If a malicious tool response influences your agent to retrieve sensitive data or invoke another system, blocking the final response does not undo the action. The attack has already moved beyond the point where an output filter can stop it.
Where the enforcement point actually is
If your model cannot reliably distinguish trusted context from attacker-controlled content, the enforcement cannot live inside the inference loop. It has to sit at the boundary where browser results, retrieved documents, and MCP tool responses enter your agent. That is the last point where you can inspect untrusted content before it becomes part of the model's reasoning.
This is the approach behind Jozu Agent Guard. The simplified GuardrailPolicy below illustrates the idea.
apiVersion: jozu.com/v1
kind: GuardrailPolicy
metadata:
name: tool-result-inspection
spec:
rules:
- name: flag-injected-instructions
scope: tool_result
checks:
- type: semantic_anomaly
sensitivity: high
action: block
- type: instruction_injection
patterns:
- "ignore previous instructions"
- "disregard your system prompt"
- "your new task is"
action: block
onBlock:
log: true
notifyHuman: trueThe key detail is scope: tool_result. Instead of inspecting the model's output after it has already reasoned over external content, the policy evaluates the tool response before it re-enters the context window. The injected instruction never becomes part of the next inference pass.
That architectural boundary is what matters. While building Agent Guard, Jozu team found that an autonomous coding agent could identify and work around controls that lived inside its execution path.** That experience led to a zero trust runtime architecture where policy enforcement operates independently of the model. The same separation matters for prompt injection: if attacker-controlled content never reaches the model, the model cannot reason its way into following it.
What happens when the policy blocks an action
Once the policy sits at the runtime boundary, the next question is what happens when an action violates it. For a tool invocation, ToolPolicy evaluates the request before execution, so an injected instruction cannot simply convince the model to call a sensitive MCP tool with unexpected arguments. High-risk actions can also trigger MCP elicitation for human approval before execution.
The policy decision is written to Agent Guard's tamper-evident audit log, giving you a record of the tool invocation, the policy that evaluated it, and the resulting decision. That matters during an incident because you can trace what the agent attempted and where policy enforcement stopped it instead of relying on the model to explain what happened.
The important part is that policy evaluation happens outside the inference loop. The model can generate an MCP tool invocation, but it does not control whether that invocation is allowed to execute. Agent Guard evaluates the request at the runtime boundary and enforces the policy independently of the model. That gives you an enforcement point the agent cannot change through its own reasoning.
The same boundary applies to npm packages
Prompt injection through tool results is one entry point. Another is what happens when your agent installs or invokes a tool that is already compromised at the package level. In May 2026, the Mini Shai-Hulud campaign compromised 42 TanStack packages and 84 malicious versions, with the affected TanStack package versions carrying valid SLSA provenance.
An agent that pulls an npm-based MCP server from a public registry and loads it without verification is exposed to this class of supply-chain attack. The malicious behavior does not arrive through a tool result. It is already inside the artifact before your agent invokes it. Agent Guard addresses this at the admission layer through ArtifactPolicy, which evaluates an artifact's digest, signatures, attestations and scan results before the artifact loads. An artifact that fails the policy is not admitted into the runtime.
This is why the enforcement boundary has to exist before execution, not only around the model. GuardrailPolicy protects the inference path, ToolPolicy governs MCP invocations and ArtifactPolicy controls which agents, models and MCP servers are allowed into the runtime in the first place. You are establishing trust before the agent gets the opportunity to execute untrusted code.
Conclusion
Prompt injection is not just a model alignment problem. In agent systems, it is a boundary enforcement problem. Once untrusted content enters your agent's reasoning loop, the model has already been asked to make security decisions using attacker-controlled context. Better alignment, stronger system prompts, and output guardrails can all improve an agent's behaviour, but they do not change where the attack begins.
As agents become more capable, they will rely on more tools, retrieve more external information, and make more autonomous decisions. That makes the boundary between your agent and the outside world one of the most important places to enforce trust. Treating tool results as untrusted by default and inspecting them before they re-enter the inference loop shifts prompt injection from a model problem to the architectural problem it has been all along.