TL;DR: Prompt injection in production agent systems survives model-focused defences because the real attack surface is the tool call chain, where browser results, retrieved documents, and MCP responses re-enter reasoning as trusted context, according to Jozu. The security boundary has to sit before untrusted content reaches the model, because once it is inside the inference loop, alignment and output guardrails are too late.
At a glance
What this is: This is an analysis of why prompt injection in agent systems is primarily a tool-boundary problem, not a model-alignment problem.
Why it matters: It matters because IAM and security teams governing AI agents need to protect the point where external content re-enters reasoning, not just tune prompts or model outputs.
Context
Prompt injection succeeds when an agent treats external content as trusted context instead of untrusted input. In agentic workflows, browser results, retrieved documents, and MCP tool responses can re-enter reasoning with the same influence as first-party instructions, which means the trust boundary is no longer the model alone.
The practical governance question is where enforcement happens before attacker-controlled content can shape the next action. For agent systems, that is a runtime boundary problem, not a prompt-writing problem, because the decision point sits between external content and the agent's next tool call. Prompt Injection Guide
Key questions
Q: How should security teams handle prompt injection across multiple agent input surfaces?
A: Treat prompt, retrieval, tool output, agent handoff, and memory as separate ingress controls, then apply one shared runtime containment model after the context window. That approach prevents teams from overfitting to the user prompt and missing the surfaces that produce the most difficult indirect attacks. The goal is not just filtering text, but limiting what the agent can do once the text is accepted.
Q: Why do model guardrails fail against prompt injection?
A: Guardrails fail because they evaluate model behaviour after the model has already reasoned over attacker-controlled content. By the time the output is filtered, the risky decision may already have happened inside the tool call chain, so the control point must move earlier in the runtime path.
Q: What are the signs that an AI agent may be vulnerable to prompt injection?
A: Look for mismatches between the prompt a system received and the actions it attempted, especially unexpected data retrieval, unusual API calls, or tool use that does not match the user's request. Those are strong indicators that input steering is affecting execution.
Q: What is the difference between prompt injection and tool poisoning?
A: Prompt injection targets the model's instructions, while tool poisoning targets the metadata the agent uses to reason about tools. Both can alter behaviour, but tool poisoning is especially dangerous when the agent trusts external tool descriptions or schemas. Teams should defend both layers because either one can lead to unauthorized actions.
Technical breakdown
Why model-level defences do not stop prompt injection
Alignment, stronger system prompts, and output guardrails all operate after external content has already entered the model's reasoning context. They can reduce the chance that a model follows a malicious instruction, but they do not preserve the boundary between trusted and untrusted content. Once a browser result or retrieved document becomes part of the same inference pass, the model no longer knows which tokens were attacker-controlled. That is why fine tuning and prompt engineering improve behaviour without solving the underlying enforcement problem. See the Agentic AI Security Guide.
Practical implication: Move the control point to content inspection before tool results and retrieved text re-enter the agent loop.
How tool-result inspection changes the trust boundary
Tool-result inspection treats browser output, document retrieval, and MCP responses as security-relevant inputs, not inert context. The enforcement point sits before those results are folded back into reasoning, so injected instructions never become eligible to influence the next tool call. That is different from filtering model output after the fact. It is also different from trying to infer intent from the model's final response, because the risky decision may already have happened inside the reasoning loop. The architectural shift is from post-generation review to pre-context admission control. See the Prompt Injection Guide.
Practical implication: Inspect tool responses before context injection so malicious instructions never become part of the next inference step.
Why runtime policy must be independent of the model
A runtime policy boundary separates what the model proposes from what the system allows. That matters because an agent can generate a tool invocation that looks plausible while still being unsafe, especially when attacker-controlled content has influenced its reasoning. Independent policy evaluation can block the invocation, require human elicitation for high-risk actions, and create an audit record of the decision. The key security property is that the model cannot overrule the policy through its own reasoning. That breaks the assumption that the model should be the final arbiter of trust.
Practical implication: Enforce tool and artifact policies outside the model so approval decisions remain immune to prompt manipulation.
Threat narrative
Attacker objective: The attacker wants to use untrusted content to steer the agent into executing an unsafe action or exposing sensitive data through its connected tools.
- Entry occurs when attacker-controlled text arrives through a browser result, retrieved document, or MCP tool response and is treated as context.
- Escalation occurs when the injected instruction influences the next inference pass and steers the agent toward a sensitive tool call or data access path.
- Impact occurs when the agent executes the influenced action, such as credential retrieval, external exfiltration, or unsafe tool invocation, before any later guardrail can intervene.
Breaches seen in the wild
- EchoLeak (Microsoft 365 Copilot) 2025: A crafted email could make Microsoft 365 Copilot leak data from its context with no click, a zero-click prompt injection fixed as CVE-2025-32711.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Prompt injection is a boundary enforcement problem, not a model-hardening problem. The article is right to move the control discussion away from alignment and prompt engineering, because those measures operate after untrusted content has already entered the reasoning loop. The decisive issue is whether the architecture preserves a trust boundary before external content becomes part of the agent's next decision. Practitioners should treat the tool call chain as the security perimeter.
The trust assumption that external content can be reasoned over safely was designed for chat-style interaction. That assumption fails when the actor is an agent that browses, retrieves, and chains tool calls because attacker-controlled content can re-enter the loop and influence subsequent actions. The implication is not merely better filtering; it is rethinking where trust is granted in the runtime path. Agentic AI Security Guide
Tool boundaries are the new security boundaries for agent systems. Once browser output, retrieved documents, or MCP responses are allowed to re-enter context without inspection, the model is no longer acting on clean instructions but on mixed-trust input. That creates a governance gap that classic model safety language does not name accurately. Practitioners should frame this as admission control for context, not content moderation after generation.
Runtime policy must be able to veto the model. The article's strongest architectural point is that the model can propose an action while a separate policy layer decides whether that action is allowed. That separation is what makes incident evidence, approval flows, and tamper-evident logging meaningful in practice. Security teams should design for policy independence, not policy advice embedded inside the model.
Read next: Agentic AI Security Guide
What this signals
Prompt injection governance now starts at admission time. The practical shift for programme owners is that a secure agent stack needs inspection before context injection, not just policy after generation. Browser results, retrieved documents, and MCP responses should be treated as untrusted inputs that can change the next action, which makes runtime gating a core design requirement for agent deployments.
Context trust debt: This article sharpens the idea that every external input admitted into an agent creates trust debt until it is verified. For teams operating agentic workflows, that means tool boundaries, not model prompts, become the durable place to enforce identity and action control.
As agents take on more browser use, retrieval, and tool chaining, teams should expect more pressure to prove where trust is established and where it is denied. The architecture that matters is the one that can stop a malicious instruction before it becomes an authorised action.
For practitioners
- Inspect tool results before context injection Treat browser output, retrieved documents, and MCP responses as untrusted until a policy layer checks for injected instructions and other anomalies.
- Separate proposal from enforcement Ensure the model can suggest an action but cannot decide whether sensitive tool calls execute, so policy remains outside the inference loop.
- Apply admission control to MCP tools and packages Evaluate digests, signatures, attestations, and scan results before an agent loads tools or server artifacts into its runtime.
- Log policy decisions at the runtime boundary Record the evaluated request, the policy that fired, and the outcome so investigations can reconstruct where the agent was stopped.
Key takeaways
- Prompt injection in agent systems is fundamentally a boundary problem, because untrusted content can be reintroduced into reasoning as if it were trusted context.
- The article shows that browser results, retrieved documents, and MCP responses are the practical entry points that matter most for enforcement.
- Security teams need a control point before context injection, plus independent policy enforcement and logging, if they want to contain prompt-driven abuse.
Related NHI Mgmt Group resources: Agentic AI Security Guide · OWASP Agentic Applications Top 10 · Prompt Injection Guide · EchoLeak (Microsoft 365 Copilot) 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centres on malicious tool calls triggered through injected context. |
| ASI03 — Identity & Privilege Abuse | Injected content aims to steer the agent into abusing connected access and credentials. | |
| Recommendation — Treat tool invocation as a policy-controlled action and block unsafe requests before execution. Constrain agent privileges so prompt influence cannot expand into unsafe access or credential use. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article treats runtime trust and boundary enforcement as part of how non-human identities are validated. |
| NHI-10 — Human Use of NHI | Human-visible prompts can indirectly drive non-human action through injected instructions and delegated tools. | |
| Recommendation — Verify tool and artifact trust before allowing non-human identities to act on external inputs. Separate human intent from agent action so external text cannot dictate non-human execution. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing which agent actions are authorised at runtime. |
| Recommendation — Enforce authorisation at the boundary where agent actions are evaluated and approved. | ||
Key terms
- Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
- Tool Call Chain: The tool call chain is the sequence of external requests, responses, and follow-on actions an agent uses to complete a task. It becomes a security boundary when content from one tool can shape the next decision, so every hop needs trust evaluation before reuse.
- Runtime boundary: The point at which an identity's permissions, execution context, and observable behaviour are contained for policy purposes. In agentic systems, runtime boundaries matter because they determine whether the organisation can explain, audit, and limit what the agent did after execution begins.
- Context Injection: A failure mode where malicious or misleading content enters an agent's decision path and affects what it does next. In MCP environments, the injected context can alter tool selection, broaden data exposure, or trigger unsafe follow-on actions across multiple systems.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org