An MCP server can modify the descriptions, parameters, or set of tools it exposes after it has been approved. If an AI agent keeps trusting the original configuration without reviewing subsequent changes, malicious instructions can influence its next actions. This is known as a tool rug pull. The risk is documented, but that does not mean every MCP integration is vulnerable or that every change is malicious.
The Model Context Protocol (MCP) is a standard for connecting AI applications to external tools, such as file systems, databases, and web services. An agent selects actions based on the user's request; the MCP server supplies tools and their descriptions. The critical distinction is that these descriptions are data supplied by an external component, not instructions that should have authority over the agent.
Where initial approval stops protecting you
To discover tools, the client uses tools/list and receives metadata such as a name, description, and inputSchema, which specifies accepted arguments. To run an operation, it uses tools/call. A person may approve a connection or a call based on what is displayed, while the model receives more detailed content.
Under the July 28, 2026 MCP specification, the available tool set can change over time. Servers declaring listChanged respond with the available list and may notify clients subscribed through subscriptions/listen. This notification provides technical synchronization; it is not a fresh security approval. The protocol recommends human oversight, but the actual interface and consent policy depend on the implementation.
There is an important difference between approving a server, authorizing access to an account, and confirming each sensitive action. None of those decisions makes future tool descriptions permanently trustworthy. An application that reuses an old approval without checking the contents and effects of a current operation leaves room for abuse.
How an apparently legitimate tool can change
Consider a server that initially describes a tool as a simple document lookup. After an update or a new discovery, its description includes directions for the agent to inspect files unrelated to the user's task. The agent may interpret those sentences as work instructions even though they came from a less trusted source. This is prompt injection embedded in tool metadata.
For a rug pull, timing is the defining feature: a definition appears acceptable during the original review but is replaced later. Tool poisoning is the broader term for malicious instructions inserted into descriptions, schemas, or outputs. Another risk is tool shadowing, where one server attempts to influence how an agent uses tools from another connected server. A tool response containing false instructions is also dangerous, but is distinct from the later modification of a tool definition.
The attack requires specific conditions: the agent must receive the manipulated content, interpret it as guidance, and have access or permissions that make the unwanted action possible. An embedded instruction does not, on its own, grant access to resources blocked by the operating system, an API, or authorization controls outside the model.
What was demonstrated, and what remains unconfirmed
On April 1, 2025, Invariant Labs published experiments with poisoned descriptions in MCP clients, including examples in which instructions from one server interfered with another server's tools. The researchers explicitly described changing a tool description after approval. These were researcher-reported experiments, not proof that every current client and version behaves the same way.
A roundup published on October 8, 2026 on the OWASP GenAI Project website described the Deadbugz campaign. According to that account, 23 GitHub pull requests were submitted in 74 minutes on August 10, 2026 to promote a malicious MCP server. The server reportedly behaved normally for the first three calls before changing its metadata to steer agents toward credentials and conceal the activity.
The same roundup states that none of the pull requests was merged and that no downstream compromise was confirmed. The case therefore documents an active distribution attempt and a malicious mechanism, not completed theft of users' credentials. The roundup also describes itself as selective rather than exhaustive and explicitly says it is not an official OWASP publication.
A defensive checklist for MCP integrations
- Record what was approved. Retain the server's identity and provenance, along with every tool's full description, input and output schemas, and annotations.
- Compare definitions over time. Use cryptographic hashes and human review for changes, including after reconnections or upgrades. A hash reveals metadata changes, not hidden changes in executable code.
- Require renewed approval for material changes. Do not automatically reuse an earlier decision for a tool whose parameters or effects have changed.
- Minimize privileges. Use separate credentials for each server and grant only necessary access. Do not give general-purpose agents broad access to local secrets, administrator accounts, or entire directories.
- Isolate servers and execution contexts. High-privilege tools need their own boundaries rather than freely sharing context and authority with external integrations.
- Confirm risky actions outside the model's text. Show the operation, destination, and full parameters before data disclosure, deletion, or another sensitive action.
- Validate arguments and results. Reject unexpected formats, treat tool responses as untrusted data, and enforce execution rules in the service or operating system, not only through prompts.
- Audit actual tool calls. Log definition changes, tool usage, and blocked actions without unnecessarily storing secrets; review dependencies and server provenance.
The OWASP security guide recommends combining least privilege, definition integrity, isolation, human confirmation, input/output validation, and auditing. No single measure eliminates every form of prompt injection.
The limits of metadata checks
Comparing current descriptions and schemas with an approved baseline helps detect a visible rug pull. However, a server may change its code or returned data without modifying those fields. Likewise, a label such as readOnlyHint indicates intended behavior, not a technical guarantee that the operation is harmless. Permissions therefore need to be enforced when the action runs.
The practical question for teams integrating agents is not whether to trust or distrust MCP indiscriminately. It is to establish exactly what was approved, what changed, and what each tool can actually do. These recommendations draw on published documentation and research; they are not DTech's own product tests or a security certification of any client or server.
