MCP Server Security: How to Vet a Server in 2026

Connecting an MCP server is the fastest way to give an AI agent real capability inside your business, and it is also the fastest way to hand a stranger a live connection to your email, your CRM and your file storage. MCP server security is not a developer detail you can defer to whoever set up the integration. It is a procurement decision, and the useful version of it happens before anything is connected, not after something goes wrong.

The Model Context Protocol has matured quickly. There is now an official registry, a formal specification with a dedicated security document, and enterprise tooling to control which servers people are allowed to run. What has not arrived is anyone who checks the servers for you. That gap is the subject of this post.

What the official MCP registry actually guarantees

The official MCP Registry is the centralised metadata repository for publicly accessible MCP servers, backed by contributors including Anthropic, GitHub, PulseMCP and Microsoft. Its documentation still marks it as being in preview, with breaking changes or data resets possible before general availability. It is worth understanding precisely what it does.

It proves provenance. Server names use a reverse DNS format, and publishers must verify ownership of the namespace through GitHub, DNS or HTTP challenges. That means a server published under a company's domain namespace really was published by someone who controls that domain. This is genuinely valuable, and it is the single strongest signal available today.

It does not prove safety. The registry's own documentation states that it delegates security scanning to the underlying package registries and to downstream aggregators, and that it focuses on namespace authentication and metadata hosting. The moderation policy is blunter still: it says the registry does not make guarantees about moderation and that consumers should assume minimal-to-no moderation.

Read the removal criteria and the picture sharpens. The registry removes illegal content, malware, spam and non-functioning servers. It explicitly does not remove low-quality or buggy servers, duplicate servers, or servers with security vulnerabilities. A listing is an identity claim, not a certificate.

The registry is also not designed for host applications to consume directly. The intended path is that downstream aggregators and marketplaces pull the metadata and add their own curation, ratings and security checks. If your team is picking servers straight off a raw index, you have skipped the layer that was supposed to do the filtering.

Three failure modes that have already happened

The first is tool poisoning. Invariant Labs disclosed this pattern on 1 April 2025: malicious instructions are embedded in an MCP tool's description, where the model reads them but the user never sees them. The description field is help text to a human and an instruction channel to an agent. Their research also documented two nastier variants. A rug pull is when a server changes its tool descriptions after you approved the integration. Shadowing is when a poisoned server alters the agent's behaviour towards a different, trusted server, so a compromised tool you barely use can redirect the output of the one you rely on.

The second is straightforward supply chain compromise. In September 2025, researchers at Koi Security found a package called postmark-mcp on npm that impersonated a legitimate email connector. Early versions behaved correctly and built adoption. Version 1.0.16 added a single line that blind-copied every outgoing email to an attacker-controlled address. Snyk's write-up confirms the blind-copy line in the send tool and notes the package was subsequently removed from npm. Reporting on Koi's findings put weekly downloads at around 1,500 before takedown. Nothing about that server looked broken from the outside, which is the entire point.

The third is credential over-reach, and it is the one businesses cause themselves. A server is given a token with far more authority than the job needs, because that was the fastest way to make the demo work. The MCP security guidance addresses this directly under scope minimisation, warning against wildcard or omnibus scopes and describing the blast radius when a broad token leaks.

An MCP server security checklist worth running

Before a server touches production data, answer these in writing. It takes under an hour per server and it is the difference between a decision and a habit.

Who published it, and is the namespace verified? Prefer a server published under the vendor's own verified namespace over a community reimplementation of the same API. If a well-known SaaS product has an official server, an unofficial package with a similar name is a red flag, not a convenience.

What does it actually run? For local servers, the exact command and arguments matter. The specification's security guidance requires clients that support one-click local server configuration to show the exact command without truncation and to get explicit approval, and it warns that servers run with the same privileges as the client. If you cannot see the command, do not approve it.

Is it pinned? The postmark case turned malicious at a version bump. Pin versions, and treat an upgrade as a change that needs review rather than something that happens quietly overnight.

What credentials does it need, and can they be narrower? Ask for a token scoped to one mailbox, one folder, one CRM module. If the vendor only offers full-account access, that is a finding to record, not a footnote.

Can you see what it did? A server that gives you no execution log is a server you cannot investigate. Insist on logging on your side of the connection even when the vendor provides none.

Would you notice a change in tool descriptions? Very few teams would. At minimum, record the tool list and descriptions at approval time so a later diff is possible.

Restrict the tools, not just the server

A subtle and underused control is that you rarely need every tool a server exposes. In n8n, the MCP Client Tool node has a Tools to Include setting with options for All, Selected, and All Except, so you can hand an agent three tools from a server that offers thirty. The node also supports bearer token, header, and OAuth2 authentication.

This is the cheapest risk reduction available. An agent that cannot call the delete tool cannot be talked into calling it. When we build agent systems for clients, tool selection is deliberate rather than default, and destructive or irreversible actions sit behind a human approval step instead of inside the agent's autonomous loop.

Governance caught up in August 2026

Platform vendors have started shipping the controls that policy documents have been asking for. GitHub's changelog dated 6 August 2026 announced MCP allowlists in enterprise managed settings, giving enterprise owners two keys, `allowedMcpServers` and `deniedMcpServers`, in the Copilot managed settings file. Entries match servers by remote URL, by exact local command, or by name. A follow-up changelog dated 18 August 2026 extended enterprise managed settings to Copilot for JetBrains.

One detail in that documentation deserves attention from anyone designing a similar policy internally. GitHub notes that matching by `serverName` is a convenience rather than a security control, because users can rename servers. Match on the thing the user cannot change, which is the URL or the command.

Where the 2026-07-28 specification helps

The current specification, dated 28 July 2026, hardened several things worth knowing about. Token passthrough is explicitly forbidden: servers must not accept tokens that were not issued for them, which closes a class of confused deputy problems where a token intended for one service is quietly reused against another. The guidance also requires proxy servers to implement per-client consent and exact redirect URI matching.

The move to a stateless protocol core removed protocol-level sessions, and the security guidance now covers what replaces them. Servers that need state across requests mint an explicit handle passed as an ordinary tool argument, and the specification is direct that servers must not treat possession of such a handle as authentication, and should bind handles server-side to the authenticated user.

None of this protects you from a server that was malicious on purpose. Protocol hardening constrains what a badly implemented server can do by accident. Vetting is what constrains what a hostile one can do deliberately. You need both, and only one of them is somebody else's job.

Start with an inventory

Most teams we work with cannot answer the first question: which MCP servers are connected, by whom, holding which credentials. Spend an afternoon building that list. Add the publisher, the namespace verification status, the version, the token scope and the date of approval. Remove anything nobody can justify, narrow the credentials that are broader than the task, and put a named owner against each remaining entry.

That inventory turns MCP from an accumulating liability into a governed capability, and it makes every later decision faster. We build MCP servers and agent integrations for businesses that need this done properly, with scoped credentials, restricted tool surfaces and human approval on the actions that matter.

If you are connecting AI agents to your CRM, inbox or operations stack and want the security model designed before the integrations multiply, get in touch through the website and we can look at your setup together.