AI Agent Tool and Plugin Security: Tool Poisoning Guide

An AI agent is only as safe as the tools it can call, and the model decides which tool to call by reading text that the tool's author wrote. That makes tool definitions, tool outputs and plugin packages part of the agent's attack surface: a poisoned description can steer the model, a tool can change after approval, and one over-permissioned function can turn a prompt injection into data loss. This guide goes deeper than the protocol view into the tools themselves: tool poisoning, rug pulls, tool shadowing, scoped tool permissions, schema and output validation, sandboxing and plugin governance. For MCP's authorisation model and server deployment controls, see the MCP Security Guide. It is written for platform engineers building agents, security architects approving tool integrations and teams running agent marketplaces.

Key takeaways

Tool metadata is untrusted input. The MCP specification says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers"; descriptions, schemas and results deserve the same treatment.
Approval is a point in time. A tool approved today can change tomorrow. Hash each server's tool manifest, pin versions and force re-approval when definitions change.
Permissions belong outside the model. OWASP LLM06:2025 Excessive Agency calls for "complete mediation": the downstream system enforces authorisation, never the LLM's judgement.
Validate both directions. Check every tool call against a strict schema and business rules before execution, and check every result before it reaches the model.
Plugins are software supply chain. Agent plugins, skills and local tool servers run code with the user's privileges; govern them with an allowlist, a named owner and a sandbox.

How agents call tools

Function calling, also called tool calling or LLM tool calling, is the pattern underneath every agent: the application describes available functions to the model (name, description, JSON Schema for parameters), the model returns a structured request to call one, and the application executes it and feeds the result back. The model never runs anything itself; agent tool invocation is performed by code you control, so function calling security is largely application security. MITRE ATLAS tracks the attacker's use of this as AML.T0053 AI Agent Tool Invocation.

Tool model	Where the tool definition comes from	Main trust question
Native function calling in your application	Your own code	Is each function narrow, authorised and validated?
MCP servers	The server, at runtime, via tools/list	Do you trust the server, and has its tool manifest changed?
Agent plugins, extensions and skills	A marketplace or package registry	Who published it, what code runs and with what permissions?
Hosted connectors in AI platforms	The platform or a third party	Which OAuth scopes were granted and to whom?

The term LLM plugins dates from the ChatGPT plugins beta of 2023; OpenAI states that "As of April 9, 2024 conversations with plugins can no longer be continued", with GPTs replacing them. The risks did not retire with the name: they moved into GPT actions, MCP servers, IDE extensions and agent skill packages. OWASP's Excessive Agency entry calls all of these "extensions".

Tool poisoning

Tool poisoning, also called AI tool poisoning, is hiding instructions or misleading content in the material the model reads to decide how to use a tool. Because the model treats tool descriptions as guidance from the developer, text there carries unusual authority. MITRE ATLAS added AML.T0110 AI Agent Tool Poisoning, and its v2026.07 release split it into three sub-techniques that map neatly onto where defenders must look:

AML.T0110.000 Definition and Instructions: the poisoned text sits in the tool name, description, parameter descriptions or schema. This is semantic tool poisoning: the tool's code may be harmless, but its words tell the model to do something else, such as read an unrelated file and place it in a parameter, or prefer this tool over another.
AML.T0110.001 Implementation: the description is honest but the code does more than it says, for example forwarding data to a third party. The postmark-mcp malicious MCP server worked as an email tool while copying every message to an attacker.
AML.T0110.002 Runtime Response: the tool's output carries instructions the model then follows. This overlaps with indirect prompt injection; the Sentry MCP agentjacking case used fake error reports returned by a tool to hijack coding agents. See the Prompt Injection Guide.

Defences against poisoned definitions:

Review the full manifest, not the display name: users see a short title; the model sees every description and parameter. Approval screens and reviews must show the text the model will read.
Scan definitions on registration and on change: flag instruction-like language ("ignore", "before using any other tool", references to files, credentials or other tools), hidden characters, unusually long descriptions and parameters with no clear purpose. Scanning is a tripwire, not a guarantee.
Constrain what poisoning can achieve: if a weather tool's schema accepts only a city name of 64 characters, a poisoned description cannot make it carry a private key. Narrow schemas and permissions turn a successful poisoning into a failed call.
Prefer servers you build or have reviewed: for sensitive data, run internal tool servers rather than community ones.

Rug pulls and silent tool changes

A rug pull is a tool or server that behaves well when approved and changes afterwards. In MCP the mechanism is built in: a server that declared the listChanged capability sends notifications/tools/list_changed and the client fetches a new tool list, which may contain new tools or rewritten descriptions. An MCP rug pull exploits clients that silently accept the new list. ATLAS records the wider pattern as AML.T0109 AI Supply Chain Rug Pull. OWASP's Q3 2026 exploit roundup describes a malicious MCP server submitted to AI projects through 23 pull requests that behaved normally for its first three tool calls, then changed its tool metadata to steer agents towards SSH keys, cloud credentials and Kubernetes configuration; none of the pull requests was merged.

Pin and hash the tool manifest: record a hash of each server's tools/list response (names, descriptions, schemas, annotations) at approval, and compare on every connection and list_changed notification.
Re-approve on change: a changed hash suspends the affected tools until a person or policy approves the diff. Show the diff, not just "the server updated".
Pin package versions and digests: install local tool servers and plugins at a fixed version or image digest from an internal mirror, so an upstream release cannot change behaviour silently.
Watch for scope drift: the MCP security best practices list "Silent scope semantic changes without versioning" as a common mistake; ATLAS AML.M0038 AI Agent Scope Drift Detection covers detecting agents whose behaviour moves beyond the approved scope.

Tool shadowing and tool name collision

Tool shadowing is one tool's definition influencing how the model uses a different, trusted tool, typically when an agent is connected to several servers at once. A description on a low-value server can tell the model to change the recipient, add a parameter or call it first whenever the trusted tool is used. Because every connected server's definitions share one context, isolation between servers is weaker than it looks.

Tool name collision is the simpler cousin: two servers expose a tool with the same name, such as search, and the model or client picks the wrong one. The MCP tools specification says names SHOULD be unique within a server, that clients aggregating several servers SHOULD disambiguate, "such as prefixing tool names with a server identifier", and that the server's self-declared name "SHOULD NOT be relied upon for disambiguation".

Namespace every tool with a client-assigned server identifier, not the name the server chooses for itself.
Block duplicate and look-alike names across connected servers at registration.
Separate toolsets by task: do not load a general community server into the same session as tools that move money, send email or write to production. See the Multi-Agent and A2A Security Guide for splitting work across agents.
Flag cross-references: a description that mentions another server's tools by name is a strong shadowing signal.

Scoped tool permissions

Poisoning and injection decide what the model tries to do; tool permissions decide what it can do. OWASP LLM06:2025 Excessive Agency (LLM03 in the 2026 edition, released September 2026) names three root causes, "excessive functionality", "excessive permissions" and "excessive autonomy", and lists the fixes: minimise extensions, minimise extension functionality, avoid open-ended extensions, minimise extension permissions, execute extensions in the user's context, require user approval and complete mediation.

Layer	Constrained tool permissions look like	Anti-pattern
Which tools the agent sees	Tool allowlist per agent and task; MCP servers may return "only the tools the caller's granted scopes permit"	Every tool on every connected server loaded by default
What each tool does	Purpose-built functions (read_invoice, not run_sql)	Open-ended shell, SQL or URL fetch tools
Identity the tool acts as	The end user's delegated identity with minimal OAuth scopes	A shared service account with admin rights
Token scopes	MCP tool permissions in a progressive model: a minimal initial scope, then step-up via a WWW-Authenticate scope challenge	Wildcard or omnibus scopes such as *, all or full-access
Action approval	Human confirmation for destructive, financial or external-send actions (ATLAS AML.M0029)	Auto-approve everything to reduce friction
Data reach	Row and tenant filters enforced by the backend	The tool trusts an account_id supplied by the model

Tool permission scoping is an identity task. Each tool server needs its own workload identity, each delegated call should carry the user's identity, and access scoping for tool permissions should be reviewed like any other entitlement. ATLAS lists AML.M0026 Privileged AI Agent Permissions Configuration, AML.M0027 Single-User AI Agent Permissions Configuration and AML.M0028 AI Agent Tools Permissions Configuration. See the AI Agent Authorisation Guide; the Amazon Q Developer extension compromise began with an over-scoped GitHub token.

Validating tool calls and tool outputs

The MCP tools specification says servers MUST "Validate all tool inputs", "Implement proper access controls", "Rate limit tool invocations" and "Sanitize tool outputs", and that clients SHOULD show tool inputs to the user before calling the server, "Validate tool results before passing to LLM" and log tool usage. ATLAS calls this AML.M0033 Input and Output Validation for AI Agent Components.

Check	Where	What good looks like
Tool schema validation	Registration and every call	inputSchema with types, required fields, enum lists, maxLength and pattern; additionalProperties set to false (the spec recommends this for tools with no parameters)
Tool parameter validation	Server, before execution	Business rules the schema cannot express: amount limits, allowed recipients, paths inside an allowed root, IDs the caller owns
Injection-safe execution	Server	Parameterised queries, no shell string building, URL allowlists for fetch tools
Tool output validation	Client, before the model sees it	Validate structuredContent against outputSchema (the spec says servers MUST conform and clients SHOULD validate), strip markup and control characters, cap size, label as untrusted data
Sensitive output filtering	Server or gateway	Redact secrets and personal data the task does not need
Error handling	Both	Tool execution errors with isError true and no stack traces, credentials or internal hostnames

Schema validation stops malformed calls; it does not stop a well-formed harmful one, such as a valid email to an attacker's address. Business-rule validation and human approval cover that gap. Tool output deserves particular care because ATLAS AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data exists for exactly this sequence: untrusted content arrives through one tool and triggers a sensitive call through another.

Tool sandboxing

A local tool server or plugin is code running on the user's machine. The MCP security best practices say clients offering one-click setup MUST "Show the exact command that will be executed, without truncation", require explicit approval, and SHOULD "Execute MCP server commands in a sandboxed environment with minimal default privileges", with restricted file system and network access and explicit grants for anything more.

Process isolation: run tool servers in containers or OS sandboxes with a read-only file system, no access to home directories, SSH keys or cloud credential files, and a non-root user.
Egress control: allow outbound connections only to the API the tool wraps. Most exfiltration through a poisoned tool needs an unexpected destination.
Ephemeral environments: code execution tools should run in short-lived sandboxes destroyed after the task.
Remote over local: a reviewed, centrally run tool server with authorisation is easier to sandbox and monitor than hundreds of local copies. The Amazon Q MCP configuration vulnerability shows why local tool configuration from untrusted repositories is dangerous.

Agent plugins and AI plugin security

Agent plugins, AI plugins in IDEs and skill packages add tools and the code behind them in one install, so AI plugin security is mostly software supply chain security plus permission review. The pattern is already common: the ClawHub malicious skills campaign delivered credential stealers as agent skills, and the JetBrains Marketplace AI plugin campaign used fake coding assistants to steal AI API keys. OWASP ASI04 Agentic Supply Chain Vulnerabilities covers this class.

Plugin permissions for AI agents: question	Acceptable answer
Who publishes it and how is publishing protected?	Known publisher, verified account, signed releases
What permissions and OAuth scopes does it request?	Only those its stated function needs; read-only where possible
Does it run code locally, and with what access?	Sandboxed, no access to credential stores
Can it update itself?	No silent updates; versions pinned and re-reviewed
Where does data go?	Documented destinations, enforced by egress policy
Who owns it internally?	A named owner who reviews it at least annually

Tool allowlisting and governance

A tool allowlist is the register of approved servers, plugins and individual tools, each with owner, version or manifest hash, permissions, data classification and the agents allowed to use it. Tool allowlisting then means the client or gateway refuses anything not on it. Small organisations can enforce this through managed client configuration and an internal mirror; larger ones usually put an agent or MCP gateway in front of all tool traffic so allowlists, manifest hashing, policy and logging live in one place. Shadow tools appear when the approval path is slower than installing from a public registry, so publish a fast path for low-risk, read-only tools. See the Shadow AI Discovery Guide.

Implementing agent tool security

Inventory: find every MCP configuration, plugin and function definition in use, including developer machines and agent platforms, and record owner and permissions.
Classify tools by impact: read-only internal, read sensitive, write, destructive, external send, financial. Impact drives approval and validation depth.
Allowlist in monitor mode: log calls to unlisted tools for two to four weeks, review, then enforce for a pilot group before all users. Keep the previous client configuration as the rollback.
Introduce manifest hashing and re-approval: start with alerting on change, then suspend changed tools automatically once false positives are understood.
Tighten permissions: move tools to the user's delegated identity, remove wildcard scopes and add human approval for destructive and external-send tools.
Add validation and sandboxing: strict schemas, business rules and output validation on internal servers first; sandbox local servers.
Test: red team with poisoned definitions, changed manifests and malicious tool outputs in a test environment. See the Red Teaming AI Agents for Identity Abuse guide.

Detection and measurement

Log every tool call: agent, user, server, tool, manifest hash, arguments (redacted), result size, decision and approval (ATLAS AML.M0024 AI Telemetry Logging).
Alert on: tool manifest changes; tools called that were never called before; arguments containing file paths, keys or addresses outside expected patterns; a read of sensitive data followed by an external send; bursts of failed or rejected calls, which often mean an agent is being steered.
Correlate with identity logs: unusual token use by a tool server's identity is often the first sign of compromise. See the AI Agent Observability and Incident Response Guide.

Metrics:

Percentage of tools in use that are on the allowlist with an owner (target 100%).
Percentage of tool servers with manifest hashing and re-approval enabled.
Number of tools holding write or admin scopes, trending down.
Percentage of destructive or external-send tools behind human approval.
Median time from a manifest change to review decision.
Rejected tool calls per thousand, by reason (schema, business rule, policy).

Framework mapping

Risk	MITRE ATLAS	OWASP	NIST SP 800-53 Rev. 5
Tool poisoning	AML.T0110 (.000, .001, .002)	ASI02 Tool Misuse and Exploitation; ASI04	SI-10, SA-9
Rug pulls and silent changes	AML.T0109 AI Supply Chain Rug Pull; AML.M0038	ASI04 Agentic Supply Chain Vulnerabilities	CM-3, SR-3
Excessive tool permissions	AML.M0026, AML.M0027, AML.M0028	LLM06:2025 (LLM03:2026) Excessive Agency; ASI03 Identity and Privilege Abuse	AC-6, AC-3
Unvalidated calls and outputs	AML.M0033, AML.M0030	ASI02; LLM06:2025 sanitise inputs and outputs	SI-10, SI-15
Exfiltration and destruction via tools	AML.T0086, AML.T0101, AML.T0098	ASI02	AC-4, SC-7
Unapproved high-impact actions	AML.M0029 Human In-the-Loop for AI Agent Actions	LLM06:2025 require user approval	AC-3, AU-12

For governance context, NIST AI 600-1 (the Generative AI Profile of the AI RMF) frames these controls within wider generative AI risk management. See the OWASP Agentic Applications Top 10.

Common failure patterns

Approving the title, not the text: users approve "GitHub tools" without anyone reading the descriptions the model will follow.
Trusting list_changed silently: the client fetches and uses a changed tool list with no diff, hash check or re-approval.
Broad shared tokens: one powerful credential sits behind many tools or servers, so a single flaw exposes all of them, as in the Smithery.ai MCP hosting breach, where one token controlled more than 3,000 hosted MCP servers.
Open-ended tools: a run_command or execute_sql tool given to a general assistant because it was convenient in a demo.
Tool output treated as instructions: results from web, ticket or email tools passed to the model unlabelled and unvalidated.

Practitioner checklist

Keep a tool allowlist with owner, version or manifest hash, permissions and allowed agents for every tool.
Hash tool manifests at approval and suspend tools whose definitions change until re-approved.
Namespace tools by client-assigned server identifier and block duplicate names.
Show reviewers and users the full tool definitions the model reads.
Run tools in the user's delegated identity with minimal scopes; remove wildcard scopes.
Require human approval for destructive, financial and external-send tools.
Enforce strict input schemas, business-rule checks and output validation on every call.
Sandbox local tool servers and plugins with restricted file system and egress.
Log every tool call and alert on manifest changes and read-then-send sequences.

AI Agent Tool and Plugin Security Guide: Tool Poisoning