Prompt Injection Is Worse When Agents Can Use Tools: The MCP Execution Crisis

Introduction

Prompt injection in MCP changes the security problem because an AI agent can act on malicious instructions instead of merely producing a bad answer. Once a model can read files, query databases, send messages, execute code, or invoke APIs, poisoned context can cross the boundary between language and execution.

That makes MCP security an execution-control problem. The Model Context Protocol standardizes how models discover and call external tools, but those capabilities also give hostile instructions more ways to produce real effects. The MCP specification itself treats tools as potentially capable of arbitrary code execution and tells clients to regard tool annotations as untrusted unless they come from trusted servers.

Why prompt injection in MCP creates a different risk?

Traditional prompt injection tries to make a model ignore its intended instructions. The outcome might be an incorrect response, leaked context, or policy bypass. With an agent, the same manipulation can influence the next tool call. An indirect prompt injection hidden inside a webpage, document, issue, email, or tool response can reach the model as data. If the model interprets that data as an instruction, it may select another tool and perform an unauthorized action.

Consider an agent asked to summarize a support ticket. The ticket contains hidden text telling the model to retrieve confidential account data and include it in a later request. A text-only assistant might repeat something inappropriate. A tool-enabled agent could actually retrieve the information. This is the core AI agent security problem: model reasoning and execution authority occupy the same workflow. OWASP describes MCP tool poisoning as an indirect prompt-injection path where malicious tool output enters the model context and can influence later actions, including restricted tool calls or data exposure. citeturn855916search1

How does MCP tool poisoning reach execution?

MCP exposes tool names, descriptions, schemas, parameters, and returned content to clients. Several of those inputs can carry attacker-controlled natural language.

A malicious server can place instructions inside a tool description. This can bias tool selection before execution. Poisoned tool results can manipulate the model after a legitimate-looking call. Attackers can also target relationships between multiple connected tools.

That produces several important attack forms:

• MCP tool poisoning embeds hostile instructions in descriptions, metadata, schemas, or returned content.
• Tool shadowing uses one malicious tool to alter how the model treats another trusted tool.
• A rug pull attack changes tool behavior or definitions after the user initially approved the integration.
• Cross-tool escalation causes poisoned output from a low-trust source to trigger a higher-privilege capability.
• Data exfiltration abuses legitimate outbound tools, such as email, HTTP requests, or search parameters.

OWASP's MCP guidance identifies tool poisoning, rug pulls, tool shadowing, confused-deputy behavior, excessive permissions, and legitimate-channel exfiltration as key risks for tool-connected agents. citeturn651855search8

Recent research suggests the protocol structure can magnify these failures. A January 2026 preprint tested 847 attack scenarios and reported attack-success increases of 23 to 41 percent compared with equivalent non-MCP integrations. The authors linked the problem to capability attestation, origin authentication, and trust propagation across servers.

MCP security must control execution outside the model

Prompt filtering alone cannot solve this problem. A system prompt that says "never reveal secrets" still depends on the model following instructions correctly. Security boundaries should survive even when the model makes the wrong decision. Start with least privilege. Give each tool only the files, APIs, operations, credentials, and network destinations required for its task. A document summarizer should not inherit database-write access because another agent component needs it.

Separate read operations from writes. Treat file deletion, code execution, account changes, external transmission, and financial actions as separate permission classes. The official MCP security guidance also recommends sandboxing local MCP servers with restricted filesystem, network, and system access because those servers can otherwise operate with client privileges. citeturn855916search0

Use structured outputs where practical. Fixed schemas make it easier to reject unexpected content before it reaches another decision step. They will not eliminate semantic injection, but they reduce opportunities for arbitrary instructional text. A human-in-the-loop control should protect high-impact operations, but confirmation must show what will happen. "Allow tool?" gives the user little information. A useful approval displays the action, target, affected data, destination, and requested privilege.

Finally, record the full execution chain. Security teams need tool discovery events, description changes, model decisions, arguments, results, authorization outcomes, network destinations, and downstream actions. Without that trace, an incident may appear as a legitimate API call even though poisoned context caused it.

What security teams should detect?

Detection should focus on transitions between untrusted content and privileged actions. Watch for tool definitions changing after approval, unusual instructions inside metadata, unexpected calls following external content retrieval, sensitive data moving into unrelated tool arguments, and tools requesting resources beyond their normal scope. These signals become stronger when they appear together.

Do not trust the model's explanation of why it performed an action. Capture execution evidence directly. Research published in 2026 has also emphasized trace-based validation because agent narratives can differ from the actions recorded in the underlying workflow. The practical goal is simple: assume hostile instructions can eventually reach the model. Build MCP security so those instructions cannot automatically become privileged execution.

How Unosecur contains MCP execution risk

Unosecur's MCP Gateway sits in the request path between agents and the tools they call. Every call routes through it. Placement is the point, because a control outside the model still holds when the model is wrong. Access gets scoped first, so an agent that reads a workspace carries no permission to delete content. Each call is then inspected as it runs.

Poisoned context cannot reach what was never granted. Least-privilege policies come from observed tool usage instead of an administrator's list, so unused tools stay closed and cross-tool escalation loses its target. The gateway classifies each call's intent before execution and rejects anything that does not match the agent's job. Secrets stay in the gateway rather than the agent, so a hijacked agent holds no key.

Sensitive data is stripped in flight, outbound from call arguments and inbound from returned content, so nothing leaks into the model context or an unrelated parameter. Every decision leaves a record of parameters, classified intent, risk level, outcome, and a readable reason. Access expires on schedule, and directory changes apply on the next call, so revocation does not wait out a long session. Unosecur's MCP Auth Gateway enforces least privilege, scoped credentials, and execution-layer authorization so poisoned context never turns into a privileged action.