Category: Application Security
Tool Injection
Simply put
Tool injection is an attack technique targeting AI agents and large language model (LLM) integrations, where an adversary manipulates the tools or tool descriptions available to an AI agent so that the agent executes unintended or malicious actions. This can occur when an attacker influences which tools an agent can call, or alters the metadata describing those tools, causing the agent to behave in ways its operators did not authorize.
Formal definition
Tool injection refers to an attack vector in AI-agent architectures (including those using protocols such as MCP, or Model Context Protocol) in which an adversary introduces, substitutes, or modifies tool definitions, descriptions, or registrations that an LLM-based agent consumes when deciding which tool to invoke and with what parameters. By poisoning the tool metadata or injecting unauthorized tool endpoints into the agent's available toolset, the attacker can redirect agent behavior to exfiltrate data, escalate privileges, or perform unauthorized operations. Tool injection is related to, but distinct from, prompt injection: prompt injection targets the model's instruction-following behavior via crafted input text, whereas tool injection specifically targets the tool-selection and tool-invocation layer of the agent framework. Detection of tool injection typically requires runtime inspection of tool registries and invocation chains, as static analysis of application code alone generally cannot identify manipulated tool metadata or unauthorized tool registrations that occur dynamically. Defensive approaches may include tool allowlisting, integrity verification of tool descriptions, and monitoring of tool invocation patterns, though the efficacy of these controls varies depending on the agent framework and deployment context, and practitioners should note that no single mitigation currently provides comprehensive coverage against all tool injection variants.
Why it matters
As organizations increasingly deploy AI agents that autonomously select and invoke external tools, the tool-selection layer becomes a critical trust boundary. Tool injection attacks exploit this boundary by manipulating the metadata, registrations, or descriptions that an agent relies on when deciding which tool to call and what parameters to pass. Because the agent typically treats tool definitions as authoritative, a successfully injected or modified tool definition can redirect the agent to exfiltrate sensitive data, perform unauthorized operations, or escalate privileges, all while appearing to operate normally from the agent's perspective. The consequences can be severe in environments where agents have broad permissions or access to sensitive resources.
Who it's relevant to
AI/ML Engineers and Agent Framework Developers
Engineers building or maintaining AI-agent systems that dynamically discover and invoke tools need to understand tool injection as a distinct attack vector. Designing secure tool-registration workflows, implementing integrity verification for tool metadata, and enforcing allowlists are responsibilities that fall directly within this role.
Application Security Engineers
Security practitioners responsible for threat modeling and securing AI-integrated applications should account for tool injection when evaluating agent architectures. Because static analysis alone typically cannot detect this class of attack, runtime monitoring and dynamic trust evaluation of tool registries become necessary components of a defense-in-depth strategy.
Platform and Infrastructure Security Teams
Teams managing the infrastructure on which AI agents and tool registries are deployed need to ensure that tool endpoints and registry services are protected against unauthorized modification. Access controls, network segmentation, and audit logging for tool registry changes are relevant infrastructure-level mitigations.
Security Architects and Threat Modelers
Architects designing systems that incorporate LLM-based agents should model tool injection as a threat distinct from prompt injection. Understanding the trust boundaries between the agent, the tool registry, and individual tool endpoints is essential for identifying where integrity checks and monitoring controls should be placed.
Red Team and Penetration Testing Practitioners
Offensive security professionals assessing AI-agent deployments should include tool injection scenarios in their testing scope. This includes attempting to register unauthorized tools, modify existing tool descriptions, and observe whether the agent can be redirected to invoke attacker-controlled endpoints.
Inside Tool Injection
Malicious Tool Definition Manipulation
An attack technique in which an adversary crafts or modifies the metadata, descriptions, or schemas of tools exposed to an AI agent (such as through the Model Context Protocol or similar agent-tool interfaces) so that the agent is induced to invoke tools in unintended, harmful ways. This typically exploits the agent's reliance on tool descriptions to decide which tool to call and with what parameters.
Prompt-Level Tool Redirection
A component of tool injection where hidden or misleading instructions are embedded within tool descriptions or tool-returned data. These instructions may cause the AI agent to override user intent, exfiltrate data to attacker-controlled endpoints, or invoke a different tool than the user expected. Detection of such embedded instructions is difficult without runtime inspection of the actual tool metadata consumed by the agent.
Tool Registry Compromise
An attack surface in which the registry or catalog that enumerates available tools for an AI agent is tampered with, either by introducing a new malicious tool definition or by altering an existing one. This may occur through supply chain compromise of a shared tool repository or through insufficient integrity verification of tool manifests.
Agent Trust Boundary Violation
The core security principle exploited by tool injection: AI agents that treat tool descriptions and tool outputs as trusted input without validation cross a trust boundary. Tool injection attacks succeed when agents lack mechanisms to verify that tool metadata has not been altered, or when agents do not enforce scoped permissions on which tools may be invoked in a given context.
Common questions
Answers to the questions practitioners most commonly ask about Tool Injection.
Is tool injection the same as traditional injection attacks like SQL injection or command injection?
No. While traditional injection attacks exploit insufficient input validation in deterministic code paths, tool injection targets AI agent systems by manipulating tool descriptions, metadata, or schemas that an LLM processes when selecting and invoking tools. The attack surface is the model's interpretation of tool definitions rather than a conventional parser or interpreter. The term shares the 'injection' label because untrusted content influences execution flow, but the mechanism, the LLM's reasoning over natural-language or semi-structured tool metadata, is fundamentally different from classic injection categories.
Are tool injection and MCP tool poisoning the same thing?
They are related but not synonymous. Tool injection is a broader category describing any attack that manipulates tool definitions, descriptions, or metadata to influence an AI agent's tool selection or invocation behavior. MCP tool poisoning is a specific variant that targets the Model Context Protocol (MCP) ecosystem, where a malicious or compromised MCP server provides poisoned tool descriptions to a connected agent. MCP tool poisoning is one concrete instantiation of tool injection, but tool injection can also occur in non-MCP agent frameworks wherever an LLM consumes tool metadata from untrusted or partially trusted sources.
How can organizations detect tool injection attempts in their AI agent deployments?
Detection typically requires a combination of approaches. Static analysis of tool manifests or schemas can flag suspicious patterns in tool descriptions, such as embedded instructions or unusual metadata fields, though this is prone to false negatives because adversarial descriptions may be semantically subtle and evade pattern matching. Runtime monitoring of agent behavior can detect anomalies like unexpected tool selection sequences or tool calls that deviate from expected workflows. However, distinguishing legitimate novel tool usage from injected behavior at runtime is inherently difficult, and both false positives (flagging valid but unusual tool use) and false negatives (missing well-crafted injections that appear contextually plausible) remain significant challenges. No single detection method currently provides reliable coverage across all tool injection variants.
What defensive controls can reduce the risk of tool injection in agent architectures?
Practical defenses include restricting tool registration to trusted and verified sources, enforcing allowlists of permitted tools per agent context, applying least-privilege scoping so tools can only access resources necessary for their defined purpose, and validating tool metadata integrity through signing or pinning mechanisms. Human-in-the-loop confirmation for sensitive tool invocations adds a layer of defense. These controls reduce attack surface but do not eliminate risk entirely. An agent may still be influenced by subtly poisoned metadata from an otherwise trusted source, and overly restrictive allowlists may create operational friction that leads to workarounds. Defensive efficacy depends heavily on the specific agent framework and how tool metadata flows through the system.
Does sandboxing tool execution prevent tool injection?
Sandboxing tool execution limits the blast radius if a malicious tool is invoked, but it does not prevent the injection itself. Tool injection operates at the selection and invocation layer, influencing which tool the agent chooses and what parameters it provides, before execution occurs. A sandboxed tool that exfiltrates data through its permitted network access, or a legitimate tool called with attacker-influenced parameters, can still cause harm within sandbox boundaries. Sandboxing is a valuable defense-in-depth measure for containing consequences, but it should not be treated as a primary control against the injection vector itself.
Which AI agent frameworks are susceptible to tool injection, and are some more resistant than others?
In principle, any agent framework that allows an LLM to select or parameterize tool calls based on tool descriptions or metadata from sources outside the direct control of the deploying organization is susceptible. This includes frameworks using MCP, LangChain tool definitions, OpenAI function calling with dynamically registered tools, and similar architectures. Some frameworks offer built-in controls such as tool approval workflows, schema validation, or restricted tool registries that may reduce exposure. However, susceptibility depends more on how the deployment is configured (whether untrusted tool sources are permitted, whether tool metadata is validated, whether invocation requires confirmation) than on the framework alone. No major agent framework currently provides built-in defenses that comprehensively address all known tool injection techniques without additional configuration and operational controls.
Common misconceptions
Tool injection is the same thing as MCP tool poisoning.
While MCP tool poisoning is a specific instance of tool injection that targets the Model Context Protocol's tool description mechanism, tool injection is a broader category. It encompasses any technique where an attacker manipulates tool definitions, metadata, or responses to subvert AI agent behavior, regardless of the specific protocol or framework involved. MCP tool poisoning is one notable attack surface within this broader class.
Standard input validation and prompt injection defenses are sufficient to prevent tool injection.
Conventional prompt injection defenses typically focus on sanitizing user-supplied text inputs to the language model. Tool injection operates at a different layer, targeting the tool metadata and tool output channels that the agent consumes to make decisions. Defending against tool injection typically requires additional controls such as tool definition integrity verification, runtime tool call auditing, and scoped permission models, none of which are addressed by standard prompt-level input filtering alone.
Tool injection can be fully detected through static analysis of agent code or tool definitions before deployment.
Static analysis may identify some categories of suspicious patterns in tool definitions, such as embedded instructions or anomalous parameter schemas. However, many tool injection attacks depend on runtime context, including dynamically fetched tool descriptions, tool responses that change based on agent state, or multi-step attack chains that only manifest during execution. Static analysis alone has significant false negative exposure for these dynamic attack patterns, and may produce false positives on benign but complex tool descriptions.
Best practices
Implement cryptographic integrity checks (such as signed tool manifests) for all tool definitions consumed by AI agents, and verify signatures at load time and periodically at runtime to detect tampering.
Enforce least-privilege scoping on tool invocations, ensuring that each agent session or task context has access only to the specific tools required, reducing the blast radius if a tool definition is compromised.
Deploy runtime monitoring that logs and audits every tool call made by the agent, including the tool name, parameters, and returned data, to enable detection of anomalous invocation patterns that may indicate tool injection. Acknowledge that such monitoring may generate false positives in complex multi-tool workflows and should be tuned iteratively.
Treat all tool descriptions and tool-returned data as untrusted input within the agent's decision-making pipeline. Apply output validation and content filtering on tool responses before they influence subsequent agent actions.
Maintain a curated allowlist of approved tool definitions and sources, and reject or quarantine tools from unverified registries. Recognize that allowlist-based approaches may introduce false negatives if an approved tool's definition is later modified through a supply chain compromise.
Conduct periodic adversarial testing of AI agent deployments specifically targeting tool injection vectors, including crafted tool descriptions with embedded redirect instructions, to evaluate the effectiveness of existing controls under realistic attack conditions.