AI agents increasingly act through tools: functions and connectors that let a model read files, call APIs, query databases, or run commands. The Model Context Protocol (MCP) has become a common way to expose these tools to an agent. This research describes a recurring weakness we observe when assessing these integrations, explains why it arises, and gives defensive guidance. It is written at a class level and intentionally contains no working exploit and no named unpatched target.
Summary
Many AI tool integrations blur the boundary between untrusted content and trusted instructions. When a tool forwards model-supplied or document-supplied text into a shell, an interpreter, a database query, or another tool call without strict validation, an attacker who can influence that text can cause unintended actions. Because the agent sits between the attacker's input and a privileged capability, the impact ranges from information disclosure to command execution on the host running the tool server.
Where the boundary breaks
1. Model output treated as a trusted command
A tool accepts a free-form field from the model and passes it into a system shell or an exec-style call. The model's output is influenced by whatever content it has read, including web pages, documents, or prior tool results. If any of that content is attacker-controlled, the attacker effectively writes part of the command.
2. Indirect prompt injection through retrieved content
An agent reads an external document, email, or record that contains instructions aimed at the model rather than the user. Those instructions can steer later tool calls, for example asking the agent to send data to an external endpoint or to invoke an administrative tool. The content, not the user, is driving the action.
3. Over-broad tool scope and implicit trust between tools
Tool servers frequently expose more capability than a task needs, and they trust the output of one tool as safe input to another. Chaining these calls lets influenced data move from a low-privilege read into a high-privilege action without ever crossing an explicit check.
Impact
- Command or code execution on the machine hosting the tool server.
- Reading or exfiltration of files, secrets, and credentials available to that process.
- Unintended writes or API actions performed under the developer's or service's identity.
- Lateral movement into connected systems the tool is authorized to reach.
Defensive guidance
- Treat all model and document content as untrusted. Never pass it directly into a shell, interpreter, or query string. Use parameterized APIs and strict allow-lists, not string concatenation.
- Give each tool the narrowest scope that works. Separate read capabilities from write and execute capabilities, and require explicit, auditable confirmation for privileged actions.
- Establish a trust boundary between tools. Do not treat one tool's output as pre-validated input to another. Re-validate at each step.
- Constrain and label retrieved content. Mark external content as data, strip or neutralize embedded instructions, and keep it out of the instruction channel.
- Run tool servers with least privilege. Dedicated service accounts, no ambient developer credentials, and network egress controls limit the blast radius if a boundary fails.
- Log and monitor tool invocations. Record parameters and outcomes so anomalous chains are detectable and reviewable.