Securing the MCP servers your teams install

Your teams are already installing MCP connectors and agent skills from public repositories. Same move as packages in 2018: search, copy the install line, move on. The gesture is identical, the object is not. Here is what changes, and the review grid I apply before approving a server. If the protocol itself is still new to you, I explain it in MCP, the standard socket between AI and your tools.

Why isn't an MCP server just another library?

Because a library hands you code you call, when you decide, with your own arguments. An MCP server does the reverse. It declares tools, describes in plain language what they do, and the model decides when to call them. The model reads that description as an instruction, on the same footing as yours. You aren't installing a function, you're installing one more voice inside your agent's head.

The consequence is simple. Code review and pinned versions, which protect you from a malicious package, don't cover this case: the server code can be spotless and its tool description booby-trapped. What decides isn't the file your scanners inspect, it's the text the model receives before it acts. That's the ground of prompt injection, moved one level up.

What can actually go wrong, in plain terms?

Four families come up in what was documented across 2025 and 2026. None of them needs hacking skill. It is enough that a piece of text the model reads looks like an order, and that a tool is there to run it.

• Tool poisoning: the description carries a hidden instruction the model reads and follows before the tool is ever called.
• Silent redefinition: the server is honest the day you adopt it, then changes behaviour at an update, with no fresh approval.
• One tool shadowing another: an installed server influences how a neighbouring server is used, inside the same agent, without authorization.
• The lethal trifecta: private data, untrusted content and an outbound channel gathered in one agent. Taken separately, all three are mundane.

These aren't lab scenarios. In March 2026, a backdoor slipped into the LiteLLM package, widely used in AI tooling; the security advisory published on detection puts it at roughly 47,000 downloads. CVE-2025-6514, rated 9.6 on the public CVSS scale, describes remote code execution on the client side, triggered by nothing more than connecting to a malicious MCP server. The 2026 OWASP GenAI report ties prompt injection to six of the ten categories in its agentic top ten. I cite these because they are public, not to dramatize.

Why is it the number one stated blocker?

Because technical leaders say so themselves. In the State of MCP in Software 2026 industry study, run with US and UK technical leaders, security tops the list of barriers to enterprise adoption, at 64%. The same study gives the other half of the picture: close to half of software companies report production use, but only 19% at broad production scale. The blocker isn't appetite, it's scale. A pilot can be watched by hand. A hundred servers cannot.

What did the specification harden in July 2026?

The 28 July 2026 revision goes after authentication: who is talking to whom. It is the most mature piece of the subject. Three changes matter.

• Issuer validation on the token: the client checks where the authorization came from.
• Client identifiers bound to the issuer: an identifier valid with one is no longer valid with another.
• Dynamic client registration, deprecated: an unknown client no longer signs itself up mid-flight.

What this revision doesn't solve, it doesn't claim to. Authentication says who is talking, not whether what they say is honest, so a booby-trapped description still gets through on a perfectly valid token. No mandatory code signing, no mandatory sandbox, and an official registry still in preview, with a few thousand servers indexed by its own public counter. Tooling is moving elsewhere: OpenAI's Agents SDK shipped native sandbox support in April 2026, per the vendor's own announcement, with a handful of listed providers.

Do skills raise the same problem?

Yes, sometimes more bluntly. A skill is a folder of instructions and scripts the model loads and follows. Readings published in early 2026 on public registries range from one skill in four to more than one in three carrying at least one flaw, depending on the scope. I take those as an order of magnitude, not as a rate. Here too, the specification mandates neither signing nor sandboxing. The full mechanism I break down in agent skills explained.

What do you look at before approving a server or a skill?

Five points, and none of them requires reading the code line by line. The first job is refusing installation by default: a third-party component comes in through a decision, not through a command pasted into a terminal. It is the craft of reliability in production: you don't aim for infallible, you aim for containable.

• Origin and version: who publishes it, from which repository, and which exact version is pinned. An automatic update is silent redefinition, gift-wrapped.
• Tool descriptions, read as text: what the model receives word for word, not what the readme says.
• Real permission scope: what data the server reaches, read or write, and what it must never reach.
• The way out: where data can leave the agent, and whether the trifecta's three pieces end up in one place.
• Execution: where the server runs, in which sandbox, and what its logs let you reconstruct after the fact.

What should you ask your teams, without being technical?

Four questions are enough to tell whether the subject is held or endured. None of them requires knowing the protocol. What they require is a precise answer, now. Same logic as vetting an AI provider: the sharpness of the answer says more than its content.

• Who approved the MCP servers in place, and where is the list?
• Are versions pinned, or can an update change behaviour with nobody re-approving it?
• Which actions can an agent trigger alone, and which go through human sign-off?
• If a tool description were booby-trapped tomorrow, what would limit the damage?

A review doesn't prove there is no flaw. It proves a human looked, and that you already know what to cut the day it goes wrong.

The point isn't to give up on MCP servers: they save far too much time, and I keep installing them. It is knowing which ones run at your place, with which permissions, and who said yes. If you want a review of what's already wired in, a first conversation is usually enough, with no commitment: let's talk.