MCP Security: Tool Poisoning and the Risk in AI Agents

MCP security has moved from a niche integration concern to a board-level question, because the Model Context Protocol has rapidly become a near-universal standard for wiring AI assistants into external tools and data sources. That convenience carries a cost: the protocol introduces significant security risk, and most of it lands on the client side, where an agent decides which tools to call and trusts what those tools advertise about themselves. For any team plugging an LLM into production systems, the trust boundary has quietly moved into a place that traditional application security never had to defend.

What the Model Context Protocol actually exposes

MCP standardises how an AI host application, the model itself, and remote servers exchange capabilities and data. Researchers modelling Model Context Protocol security typically decompose the architecture into six components — the MCP host, the MCP client, the LLM, the MCP server, external data stores, and the authorization server — and apply the STRIDE and DREAD frameworks across each. That framing matters because the attack surface is not a single endpoint. It is a chain of trust relationships, and a weakness in any one of them (a poisoned server description, an over-broad token at the authorization server, an untrusted external store) can propagate into the model’s decision-making.

The reason this is hard to reason about is that the model is an active participant. Unlike a conventional API client that follows fixed code paths, an LLM reads tool descriptions in natural language and decides, at runtime, what to invoke and with what arguments. The metadata a server presents is not inert documentation — it is, effectively, instructions the model may act on. That is the seam attackers are working.

Tool poisoning: the most impactful client-side flaw

Tool poisoning — malicious instructions embedded in a tool’s metadata or description — is described in the research as the most prevalent and impactful client-side MCP vulnerability. The mechanism is deceptively simple. A server publishes a tool whose description looks benign to a human skimming a list, but contains directives aimed at the model: instructions to exfiltrate data, to call another tool with attacker-chosen parameters, or to ignore the user’s stated intent. Because the model treats descriptions as trustworthy context, the payload executes inside the agent’s reasoning before any human reviews the result.

An empirical evaluation of seven major MCP clients reportedly found significant issues in most of them, attributed to insufficient static validation of tool metadata and limited parameter visibility — meaning the client often could not show a user precisely what a tool call would do before it ran. This is the same root cause that makes prompt injection (OWASP LLM01) so durable: untrusted text reaches a model that cannot reliably distinguish data from instruction. Tool poisoning is, in practice, prompt injection delivered through the supply chain rather than through user input, which is why teams should treat the two as a single defensive problem rather than separate ones. RingSafe’s AI Security Center tracks both under the same threat model.

The supply chain is now part of MCP security

Researchers report that the first malicious MCP package hit public registries in September 2025, which marked the point at which MCP security stopped being a theoretical model and became an operational supply-chain problem. The familiar package-ecosystem abuses transfer cleanly: typosquatting a popular server name, dependency injection through a server’s own requirements, and fake “official” servers that impersonate a trusted vendor to win an install. None of these require breaking the protocol. They exploit the fact that an agent operator searching a registry has limited signal about who actually authored a given server and what its tools really do.

The practical consequence is that installing an MCP server should be governed with the same rigour an organisation already applies — or should apply — to third-party libraries: provenance checks, pinning, and review before anything reaches an environment where the agent has real privileges or real data.

What this means for Indian teams shipping AI agents

For Indian engineering teams, the timing is awkward. Agentic AI is being adopted into production workflows at the same moment that compliance expectations are tightening. A poisoned tool that quietly exfiltrates customer records is not just an engineering failure — under the DPDP Act it would likely constitute a personal-data breach, with the obligations that follow. Teams operating under sectoral regimes face additional scrutiny on how automated systems handle regulated data, which is precisely the surface MCP exposes. RingSafe maps these obligations in its guidance on AI compliance for India across DPDP, RBI, and the EU AI Act.

The signal worth internalising is that “we use a well-known agent framework” is not a control. The framework is the host; the risk is in the servers it trusts and the metadata it ingests. An agent connected to five MCP servers has, in effect, accepted five external authors into its decision loop.

Defences that hold up

The US National Security Agency has published a Cybersecurity Information Sheet on MCP security, and the research converges on a consistent set of controls. None is a silver bullet; layered together they raise the cost of a successful tool-poisoning attack considerably:

• Static metadata analysis. Inspect tool descriptions and parameter schemas before they reach the model, flagging embedded directives, suspicious instructions, and mismatches between a tool’s stated and actual behaviour.
• Model decision-path tracking. Record why the agent chose a given tool and which arguments it derived, so a poisoned description that steered the decision is visible after the fact.
• Behavioural anomaly detection. Baseline normal tool-call patterns and alert on deviations — an unusual data egress, an unexpected tool chain, a call no user action explains.
• Explicit user approval and transparency. Surface exactly what a tool call will do, with full parameter visibility, and require human confirmation for sensitive actions rather than auto-executing.
• Pinning trusted servers. Restrict the agent to a vetted allow-list of servers at known versions instead of resolving from open registries at runtime.
• Vetting packages before install. Treat MCP server installation like any dependency: verify provenance, watch for typosquats and fake “official” servers, and review the tools a package registers before granting it access.

These map directly onto the agentic-AI threats catalogued in the OWASP Top 10 for Agentic AI, and treating tool poisoning and prompt injection as one defensive surface keeps the controls coherent rather than bolted on per attack.

The takeaway

MCP delivers genuine value, but it relocates the trust boundary into a layer most security programmes have not yet instrumented. Tool poisoning is the clearest expression of that gap: a natural-language description, trusted by the model and under-validated by the client, becomes an execution channel. The supply-chain dimension — reported once the first malicious package appeared in public registries — means the defence cannot stop at the prompt. It has to cover provenance, approval, and observability across all six components researchers model. Treat agent integrations as you would any untrusted third party, and the protocol’s risk becomes manageable rather than unbounded.

If your team is wiring AI agents into production and wants the tool surface assessed before it ships, RingSafe runs adversarial testing against agent and MCP integrations as part of its penetration testing engagements. Book a scoping call to map your agent’s trust boundaries and harden them.