A security disclosure in 2026 identified as many as 200,000 exposed Model Context Protocol instances across IDEs, internal tools and cloud services. Not vulnerable in some theoretical sense — reachable. That number is the natural consequence of a protocol that went from roughly 100,000 monthly SDK downloads at launch to 97 million by March 2026, a 970-fold increase in eighteen months, with adoption running well ahead of governance.
MCP won, which is exactly why it is now a risk surface
The argument about whether MCP would become the integration layer for agentic AI is over. It is natively supported by Anthropic, OpenAI, Google and Microsoft. Fortune 500 implementation reached roughly 28% within eighteen months of launch, and CData estimates 30% of enterprise application vendors will ship an MCP server during 2026.
Standardisation is genuinely valuable here: one protocol instead of N bespoke integrations is the whole reason this took off. But it also means a single class of misconfiguration now applies uniformly across your estate. The blast radius of “we got MCP wrong” is not one connector. It is every connector.
The four attack classes worth understanding
Tool poisoning
An MCP server advertises its tools to the agent through descriptions and schemas. Those descriptions are read by the model as instructions. An attacker who controls a server can embed directives in tool metadata that the model obeys and the user never sees — exfiltrate a file while ostensibly formatting a date. This is prompt injection relocated to the supply chain, and it is the dominant risk in practice.
Rug pulls
A server is reviewed and approved while benign, then silently redefines a tool’s behaviour after installation. Approval was a point-in-time event; the tool definition is a moving target. Any governance model that reviews once and trusts forever fails here.
Tool shadowing and cross-server interference
When an agent has several servers connected, one server’s tool description can influence how the model uses another server’s tools. A low-privilege server can therefore manipulate the use of a high-privilege one. Servers you evaluated in isolation behave differently in composition.
Confused deputy and OAuth weaknesses
The server holds credentials with broader scope than the requesting user, and the agent becomes a route to privileges the user does not have. Classic, well-understood, and reintroduced wholesale by teams shipping MCP servers at speed.
The control that does most of the work: a gateway
Beyond a handful of servers, point-to-point client-to-server connections stop being governable. A centralised MCP gateway puts controls at the trust boundary — the point where a client decides which server to invoke — and gives you the four things you cannot retrofit later.
- An inventory. Which servers exist, who registered them, what they claim to do. You cannot govern a list you do not have.
- Tool-level authorisation. Not “user X may use server Y” but “user X may invoke tool Z on server Y”. Server-level permission is almost always too coarse.
- Change detection. Hash the tool definitions at approval and alert on drift. This is the specific control that defeats rug pulls, and it is cheap.
- An audit trail. Every invocation, with arguments, identity and result. This is also your observability substrate, so the cost is shared.
For any deployment past a few servers, centralisation typically lowers total cost while improving coverage — you are implementing one policy engine instead of a policy per client.
Treat agents as privileged identities
The single most useful reframe: an agent with tool access is not a feature, it is a privileged account. It authenticates, it acts, it accumulates capability, and it does so faster and at higher volume than any human admin. Apply the controls you already apply to admin accounts.
- Named identity per agent, never a shared service account.
- Least privilege by default, with capability granted per task rather than per role.
- Time-boxed credentials. An agent that ran a quarterly reconciliation should not hold live credentials in week seven.
- Action-level approval for sensitive operations — file modification, outbound API calls, anything with an external side effect. This is the practical form of human-in-the-loop approval.
- Periodic access review, same cadence as your human privileged access review.
A staged rollout that does not stall
- Inventory and quarantine. Find every MCP server already running — including the ones developers installed in their IDEs, which is where the exposure numbers come from. Nothing reaches production data until it is registered.
- Gateway in front of everything. No direct client-to-server paths. This is easier to mandate early than to retrofit.
- Classify servers by data reach. Read-only public, read-only internal, write internal, write external. Approval rigour scales with class; a read-only docs server should not need the review a payments server needs, and if it does, teams will route around you.
- Instrument before you scale. Traces on every invocation from day one — see agent observability for what to capture.
- Re-verify on a schedule. Tool definition hashes, credential scope, and actual usage against granted capability. Most agents use a fraction of what they were granted, and that delta is free risk reduction.
What this buys you beyond security
Teams resist gateway architectures because they read as friction. In practice the inventory and the audit trail are what make agent programmes governable enough to expand. The organisations stuck at pilot are rarely stuck on model quality; they are stuck because nobody can answer what the agent is allowed to touch and what it did last Tuesday. A gateway answers both, which is why it tends to accelerate rollout rather than slow it.
Frequently asked questions
Is MCP inherently insecure?
No. The protocol standardises how tools are described and invoked; it does not mandate a trust model. The observed problems come from deployments that grant broad credentials, skip an inventory and treat approval as a one-time event. Those are governance gaps, not protocol defects.
What is tool poisoning?
An attack where malicious instructions are hidden in an MCP server’s tool metadata — descriptions and schemas that the model reads as instructions but the user never sees. It is prompt injection moved into the integration supply chain.
Do we need an MCP gateway for three servers?
Probably not for security alone, but the inventory and audit trail are worth having from the start, and retrofitting a gateway after twenty servers are wired point-to-point is materially harder than mandating it at three.
How do we stop a rug pull?
Hash tool definitions at approval time and alert on any change. Re-approval on drift is the control. It is inexpensive and it addresses the one attack class that periodic manual review cannot catch.