MCP tool outputs can inject instructions into the agent’s context after the user prompt has passed initial checks, which means the attack enters through delegation rather than input submission. The risk grows when the tool result is treated as trusted context instead of untrusted data. Security teams need controls that validate tool returns before reasoning continues.
How MCP tool outputs become a second attack path
MCP changes the trust boundary. The user prompt is no longer the only place where instructions can enter the agent’s reasoning loop, because a tool result can carry text that is later treated as operational context. That is why tool output handling must be designed as a security control, not just a parsing step.
With indirect prompt injection, the malicious payload often arrives through content the agent was supposed to retrieve, summarise, or act on. The agent may have already passed its initial user-input checks, so the harmful instruction is introduced after the first line of defence. The MCP authorization specification is relevant here because it formalises the boundary conditions around servers, tokens, and client access, which are the same places where trust assumptions tend to fail.
Tool outputs are especially risky when they are reused across multiple steps, because one poisoned response can influence later reasoning, tool selection, or delegated action. If the model can read the output, then use it to decide what to do next, the output is effectively participating in control flow, not merely delivering data.
Why trust assumptions break down after delegation
The core failure is over-trusting the return path. A tool result may look like a benign summary, status message, or search result, but if the agent treats that text as instructions, the attacker has gained a hidden channel into the workflow. This is a classic confusion between data and directive, and it becomes more dangerous as the agent gains more authority.
MCP also makes the problem easier to miss because tool calls feel like sanctioned actions. Security teams may focus on user authentication, session controls, or permission checks at the front door, while the real compromise happens inside the agent loop after a delegated call comes back. OWASP Agentic AI Top 10 captures this broader pattern through tool misuse, identity and privilege abuse, and prompt injection risk that arise once an agent begins chaining actions across trust boundaries.
Another reason the risk increases is that tool outputs can be contextualised by surrounding system prompts, memories, or prior observations. If the model is not forced to separate trusted instructions from untrusted retrieval content, a single malicious fragment can be amplified into a broader action sequence. That is why the control objective is not merely blocking bad words, but preserving instruction hierarchy.
What should be treated as untrusted in MCP workflows
Any tool output that can influence reasoning should be assumed untrusted until validated. That includes plain text, structured JSON, markdown, error messages, search snippets, and content that appears to come from an internal service. The format does not make it safe. A well-formed response can still carry instructions, social engineering, or references that steer the agent into unsafe follow-on actions.
The safest posture is to classify tool returns by role. Some fields may be safe for display, some may be safe for deterministic parsing, and some should never be allowed to alter policy decisions, tool selection, or execution authorisation. When the agent must use the content operationally, the return should be constrained, schema-validated, and sanitised before it reaches any reasoning step that can trigger action.
MCP Security Guide is useful here because it focuses on practical controls such as authorisation model boundaries, token handling, gateway patterns, and tool-poisoning defence. Those are the mechanisms that determine whether the agent can keep tool output in the role of data instead of letting it become covert instruction.
Risk and Threat Considerations
Indirect prompt injection matters because the attacker does not need to win at the user prompt. If they can influence a tool response, they can target the agent after its initial checks and use the agent’s own trust in delegated output against it. That makes the attack harder to spot and often more damaging than a direct malicious prompt.
Failure mechanism: The agent ingests tool output as if it were trusted context, then follows embedded instructions, hidden commands, or manipulative content during later reasoning or tool selection. Once that happens, the malicious content can trigger data exposure, unsafe actions, or privilege misuse without ever appearing as a normal user submission.
Impact: The outcome can be prompt leakage, data exfiltration, unauthorized tool use, command execution, or cascading misuse of downstream systems. In practice, the bigger the agent’s delegated authority, the larger the blast radius of one poisoned tool return.
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 API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Tool output can steer agent actions through delegated context. |
| ASI03 — Identity & Privilege Abuse | Poisoned tool output can drive actions under excessive agent authority. | |
| ASI06 — Memory & Context Poisoning | Indirect prompt injection contaminates the agent's context with untrusted instructions. | |
| Recommendation — Validate tool returns before any follow-on action or reasoning. Constrain agent privileges so tool output cannot trigger broad impact. Isolate and filter retrieved content before it reaches agent context. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | MCP tools can steer agents into unsafe downstream business actions. |
| Recommendation — Gate high-impact tool actions with explicit authorization checks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and credential handling shape trust in tool-mediated access. |
| Recommendation — Rotate and scope tokens so tool access cannot be reused broadly. | ||
Practitioner Guidance
What to verify: Verify that tool responses are never fed directly into decision-making paths that can trigger action, approval, or delegation. If the agent must read the output, it should do so through an explicit trust boundary that separates user intent, retrieved data, and executable instructions.
Decision rule: If a tool return can change what the agent does next, treat it as security-sensitive input and apply validation before the next reasoning step. If the output is only for presentation, keep it out of the action chain entirely.
What good looks like: The system can parse tool outputs, but it cannot silently promote them into instructions, policy, or authority. The agent remains able to use the tool while still resisting content that tries to redirect, override, or expand its scope.
Practitioner takeaway: The main control objective is not to trust MCP less in general, it is to ensure that every tool return is handled as data first and authority never by default.
Related resources from NHI Mgmt Group
- Why do arbitrary MCP connections increase the risk of prompt injection and tool abuse?
- Why do MCP-based AI systems increase prompt injection risk?
- Why do AI assistants with tool access increase prompt injection risk?
- Why does indirect prompt injection increase risk for AI assistants in enterprise inboxes?