Because the same workflow that reads external content can also trigger privileged actions. If content from Slack, email, or HTML is passed into tools that can execute code or call high-permission APIs, the agent becomes a bridge from outside data to runtime action.
Why untrusted input becomes dangerous in MCP-driven agents
Untrusted input is dangerous because in MCP-driven agents it is not just text to be displayed or summarized. It can become part of the agent’s working context, influence tool selection, and flow into actions that touch code, data, or privileged systems. That creates a direct path from outside content to execution, which is very different from ordinary content rendering.
The key security shift is that the agent may treat incoming content as instructions, evidence, or parameters at the same time. A malicious email, Slack message, page, or document can therefore shape what the agent reads next, which tools it calls, and what requests it sends. Once that boundary is crossed, the input is no longer passive.
This is why MCP changes the threat model: the protocol connects model context to tools, and tools often sit behind authenticating, authorized, or otherwise powerful actions. When untrusted content can influence a tool-enabled workflow, the attacker is no longer trying to break the model alone. The attacker is trying to steer a trusted execution path that already has access.
Where the attack boundary breaks
The dangerous point is usually not the first ingestion step. It is the moment the agent uses content from one trust zone to decide something in another. For example, content copied from external sources can be carried into prompts, retrieval results, or task instructions, then used to construct tool calls that read repositories, update tickets, send messages, or retrieve sensitive data.
That creates a classic confused-deputy style problem: the agent is operating with its own authority, but it may be acting on behalf of attacker-controlled content. In practice, the risk is highest when the agent can chain reading and acting in one loop, especially when the tool side includes code execution, secret-bearing services, or APIs with broad write permissions.
So the real boundary is not “trusted agent versus untrusted text.” It is “untrusted text versus authorized action.” If those two are allowed to meet without a control point, the input can become a command path rather than a data path.
For a deeper MCP-specific control view, the MCP Security Guide is useful because it focuses on authorization, token handling, and tool-poisoning failure modes in the protocol itself. For a broader agent-security lens, Agentic AI Security Guide maps the same risk to inputs, tools, orchestration, and identity.
Why this risk becomes worse with tools, privileges, and identity
The danger rises sharply when the agent can reach high-permission APIs or execute code. At that point, a poisoned instruction does not need to “hack” the model in the classic sense. It only needs the agent to accept the malicious content as a legitimate part of the task and then carry out the next step with valid credentials or delegated authority.
That is why untrusted input, privilege, and identity are inseparable here. If the agent can act on behalf of a user, service, or workflow, then every untrusted message has to be evaluated as a potential attempt to redirect that authority. The issue is not merely prompt injection in the abstract. It is unauthorized action through a trusted runtime.
This is also why long-lived credentials and broad-scoped tokens make the problem worse. They turn a momentary content decision into a durable access problem. If the agent can continue to use those permissions after the original task is over, the blast radius extends well beyond the content that triggered it.
For the identity and authorization side of the problem, NHI Authentication Guide is relevant because it covers how non-human actors authenticate to APIs and tools. AI Agent Authorisation Guide is equally important because it addresses least privilege, task-scoped access, and per-action policy decisions. The strongest operational lesson is to separate receipt of input from permission to act.
Risk and Threat Considerations
When untrusted content can influence an MCP agent, the main risk is that an attacker can smuggle instructions through a channel that defenders mentally classify as “just data.” That matters because the agent may then use legitimate credentials, real tool access, and approved integrations to perform harmful actions without any obvious authentication failure.
Failure mechanism: A malicious payload embedded in content is treated as context or instruction, then translated into tool use, data access, or code execution under the agent’s existing authority.
Impact: The result can be data exposure, unauthorized changes, secret leakage, lateral movement, or abuse of connected systems, often while the original source content still appears harmless.
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, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Untrusted inputs can steer agent tool calls into harmful actions. |
| ASI03 — Identity & Privilege Abuse | The risk centers on attacker-influenced use of agent authority and permissions. | |
| ASI09 — Human-Agent Trust Exploitation | Malicious content exploits trust placed in agent output and context. | |
| Recommendation — Constrain tool invocation paths and validate every action against policy before execution. Apply least privilege and per-action authorization to every agent capability. Treat external content as untrusted until policy checks clear it for action. | ||
| OWASP ASVS | V8 — Authorization | The core failure is unauthorized action driven by untrusted content. |
| Recommendation — Require explicit authorization checks before any state-changing or sensitive action. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question concerns untrusted input crossing into privileged execution paths. |
| Recommendation — Verify each request and deny implicit trust between content ingestion and tool use. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Agent tool calls can become unauthorized function use if input drives high-privilege APIs. |
| API2 — Broken Authentication | Agent workflows often depend on authenticating to tools and APIs before acting. | |
| Recommendation — Enforce function-level authorization on every tool and API operation. Validate authentication boundaries before allowing agent access to sensitive APIs. | ||
| MITRE ATT&CK | T1204 — User Execution | Malicious content aims to induce the agent or operator to run harmful actions. |
| T1059 — Command and Scripting Interpreter | The risk increases when input can drive code or command execution through tools. | |
| Recommendation — Hunt for content paths that trigger execution of attacker-influenced commands or workflows. Inspect agent toolchains that translate content into shell or script execution. | ||
Practitioner Guidance
What to verify: Check whether the agent can both ingest external content and invoke tools in the same trust boundary. If yes, require a clear control that separates untrusted read paths from privileged action paths, rather than relying on prompt wording alone.
What good looks like: External content may inform analysis, but it should not directly determine high-impact tool calls without policy enforcement, scoped permissions, and a reviewable decision trail. If the tool can change state, fetch secrets, or execute code, treat the input as potentially adversarial until proven otherwise.
Common mistake: Teams often harden the model prompt but leave the tool layer over-permissive. That protects the conversation style, not the action surface.
Practitioner takeaway: In MCP agents, the safe design goal is not “trust the input less,” it is “make sure untrusted input cannot silently become privileged action.”