Approving MCP Servers Like Software Suppliers: Governing the Connectors Your AI Assistants Use

Security insightsNovember 12, 2026

New malware entries for MCP packages this week are a reminder that AI assistant connectors are part of your supply chain. Here is how to approve, pin, narrow and monitor them, with a checklist for this week.

Abstract navy illustration of a central layered hub linked to surrounding teal and blue nodes, each link passing through a small square gate, some open and some closed, representing approved and blocked connectors

AI assistants and coding agents become far more useful once they can act: send an email, query a ticketing system, read a repository. The Model Context Protocol (MCP) has become a common way to wire up those actions, and installing a new MCP server often takes a single line of configuration. That convenience is the problem. Each server is code that runs with the assistant's access, and its tool descriptions are text the model reads and may follow.

This week shows why it matters now. On 9 and 10 November 2026, the OSV database published malware entries for two npm packages with MCP in their names, @bestcoolman/dev-mcp and mcp-contract-tester. Both entries say any computer that installed them should be considered fully compromised, with secrets rotated from a different machine. MCP servers are now part of your software supply chain, and they deserve the same governance as any other supplier.

Why MCP servers are a different kind of dependency

A conventional library does what its code says. An MCP server does that too, but it also supplies the model with tool names and descriptions, and its outputs flow back into the model's context. That creates three distinct risks.

Malicious or hijacked code. The best-known case remains the fake postmark-mcp package. According to The Register, its author published 15 versions before version 1.0.16 added one line that blind-copied every outgoing email to an outside address. Security firm Koi, which found it, estimated thousands of emails a day were diverted.
Poisoned tool descriptions. Invariant Labs described how hidden instructions in a tool description, which users rarely see, can steer the model into reading sensitive files or misusing another server's tools. They also described the "rug pull": a server changes its descriptions after you approved it.
Over-broad access. A server that holds a token with every scope turns any compromise, of the server or of the model's judgement, into broad access to the systems behind it.

The NSA's information sheet on MCP security, released in May 2026, makes the same point at a higher level: organisations should apply heightened scrutiny in production, and the risks cannot be patched at isolated endpoints; they have to be addressed across the whole MCP environment.

Treat each server as a supplier

The practical answer is not a new discipline but an old one applied consistently. Before a server is allowed, someone should be able to answer four questions.

Who publishes it? Prefer servers published by the vendor of the system they connect to, from the vendor's own repository or registry namespace. In the postmark-mcp case, the official server was published on GitHub rather than npm, which left room for a lookalike there.
What exactly will run? Pin a specific version and record its checksum. Avoid configurations that fetch "latest" at every launch, since a later release can change behaviour without anyone noticing.
What can it reach? List the credentials it receives, the files and network destinations it needs, and the actions its tools can take, especially anything that sends, deletes or pays.
Who owns it? Name a person or team responsible for updates, review and removal, just as you would for any integration.

Keep the answers in a simple register. An allowlist of approved servers, with versions, is the single most useful control, because it turns "anyone can add anything" into a decision someone made.

Narrow what each server can do

The MCP security best practices document gives clear guidance for operators and implementers. Several points translate directly into policy.

Minimal scopes. The specification recommends a progressive, least-privilege scope model and lists wildcard or omnibus scopes as a common mistake. Ask whether a server can work read-only, and grant write access only to the tools that need it.
No token passthrough. MCP servers must not accept tokens that were not issued for them. A server that forwards whatever token it receives breaks audience checks and muddies your audit trail. Ask vendors how they validate tokens.
Sandboxed local servers. Local servers run with the same privileges as the client. The guidance recommends running them with restricted file system and network access, and showing users the exact command before a new server is configured.
Controlled egress. For server-side deployments, the document recommends an egress proxy that blocks internal destinations. More generally, a server that only needs one API should not be able to reach the whole internet.

Human approval for consequential actions is the other half. Configure clients so that tools which send messages, change records or move money require confirmation, and keep those confirmations meaningful by not asking for them on every read.

Watch for change, not just for installation

Approval at install time is necessary but not sufficient, because both code and descriptions can change later. Build in a few ongoing checks.

Detect description drift. Invariant Labs recommends verifying tool descriptions against a stored hash so unauthorised changes are noticed. If your client or gateway supports this, turn it on; if not, review descriptions when you update a pinned version.
Log tool calls. Record which server and tool was called, by which user or agent identity, with what outcome. The MCP guidance notes that poor scope design and token passthrough both obscure audit trails, so clean identities pay off here.
Subscribe to malware feeds. Check your register against sources such as OSV and GitHub's malware advisories.
Plan the bad day. If an approved server turns out to be malicious, you will need to know which machines ran it and which credentials it held, and rotate them from a clean device, as the OSV entries advise.

A checklist for this week

Inventory the MCP servers configured in your developer tools and AI assistants, including local ones on laptops.
Compare the list against the OSV and GitHub malware advisories, and remove anything you cannot attribute to a known publisher.
Pin versions and record checksums for every server you keep.
For each server, write down its credentials and scopes, and remove write or admin scopes it does not need.
Require user confirmation for tools that send, delete or pay.
Publish a short allowlist and a request process, so people have a sanctioned route instead of a workaround.
Assign an owner to each approved server and set a review date.

Conclusion

MCP makes it easy to give an assistant real capabilities, which is exactly why each connection deserves the scrutiny you would give any supplier with access to your systems. Know what runs, pin it, limit what it holds, and watch it for change. None of this requires new tools; it requires treating AI connectors as part of the supply chain rather than as personal preferences.

Identity is a recurring thread here: approvals, scopes and audit trails all depend on knowing which user or agent is acting. A shared identity layer such as OXU Identity can help keep those decisions consistent across connected systems, but the governance steps above apply whatever stack you use.