A question for your next technical committee meeting: how many MCP servers are configured today on your team's laptops, in which version and with which credentials? Most likely nobody can answer it. Not because nobody cared, but because there's nowhere to look.
A developer wants their assistant to read the tickets in the project tracker. They look up the matching MCP server, copy four lines into the Claude Code, Cursor or VS Code configuration file, paste their personal token into an environment variable and restart. Ten minutes. From that moment on there's a third-party program running on their machine, under their identity, connected to a company system and to a model that decides when to use it. Nobody else knows, and not through carelessness: none of the company's processes were designed to find out.
The thesis of this piece is that the mistake isn't installing MCP servers, which are useful, but treating them as an editor extension. An MCP server is an integration with credentials, and the question isn't whether it's safe, but whether it's governed like the rest of your integrations. Today it almost never is.
What those four lines install
MCP (Model Context Protocol) is the protocol an AI assistant uses to connect to external tools and data. An MCP server exposes those tools: read email, query a database, open a pull request. Many run locally, launched by the client itself with a command along the lines of npx some-mcp-package, which downloads the package from the public registry and starts it.
The specification's own security best practices put it bluntly: clients should warn that MCP servers run with the same privileges as the client and, for one-click installs, show the exact command that will be executed, without truncation. In other words, they can reach whatever the user can: their files, their SSH keys and the environment variables holding the tokens of every other server.
And those tokens tend to be the far-reaching kind. In October 2025, Astrix analysed 5,205 MCP server repositories: around 88% require credentials, 53% rely on static API keys or personal access tokens, 79% of keys are passed as plain environment variables and only 8.5% use OAuth. Translated: the normal case is an MCP server running on a long-lived personal token, stored in plain text on someone's laptop.
Why no control sees it
A mid-sized company has, whether it calls them that or not, several filters every new integration goes through. The MCP server slips past all of them, and not through anyone's bad faith: it simply comes in through a door those filters don't watch.
| Usual control | What it reviews | Why it doesn't see the MCP server |
|---|---|---|
| Code review | What goes into the repository | The configuration lives in the user's home folder, not in the repository |
| Dependency inventory | The product's lockfiles and SBOM | The package isn't a product dependency; it's often downloaded unpinned every time it starts |
| Procurement and vendors | Contracts and third-party assessments | It's free and open source: there's no invoice to trigger a review |
| Identity management | Applications connected to corporate accounts | A personal token registers no new application: the server acts as the user |
| AI usage policy | Which assistants and which data may be used | It usually approves the assistant, not what gets connected to it |
onext's own analysis
The last row is the most common. Many companies already have a policy on which AI assistants are allowed, like the one we proposed in shadow AI. But approving Claude Code or Copilot says little about what people connect to it afterwards. It's like approving a browser and never asking which extensions it has. OWASP has given it a name in its MCP-specific risk list: Shadow MCP Servers, ninth out of ten.
Four real failures, and none of them is the model's
In the piece on prompt injection we looked at how hostile text turns an over-permissioned agent into a leak. That risk is real, but it isn't the only one. The four cases below don't need the model to get anything wrong. They fail earlier: in what was installed, where it came from and who changed it.
The package that was legitimate until it wasn't. In September 2025, Koi Security found what is considered the first malicious MCP server in the wild: postmark-mcp, an npm package impersonating the integration for the Postmark email service. For fifteen versions it worked correctly. Version 1.0.16, released on 17 September, added one line that blind-copied every email sent through it to an address controlled by the attacker. According to CSO Online, the package had around 1,500 weekly downloads. Anyone who had reviewed it at version 1.0.15 would have approved it, and rightly so.
The description the user doesn't see. In April 2025, Invariant Labs described tool poisoning: instructions hidden in a tool's description, invisible to the user but visible to the model. The same write-up described two variants: the rug pull, where the server changes the description after the user has approved it, and shadowing, where a malicious server manipulates how the tools of another, trusted server are used. The MCP specification has taken the lesson on board: descriptions of tool behaviour should be considered untrusted unless they come from a trusted server.
The piece of plumbing nobody looks at. In July 2025, JFrog published CVE-2025-6514 in mcp-remote, a package that bridges local clients to remote MCP servers: connecting to an untrusted server allowed operating-system commands to run on the user's machine. A CVSS score of 9.6, and more than 437,000 downloads according to The Hacker News. Nobody chooses mcp-remote as a tool; it comes bundled in the installation instructions of many servers.
The vendor's official server. Asana launched its MCP server on 1 May 2025. On 4 June it detected a bug that could expose one customer's information to users from other organisations; it took the server offline from 5 to 17 June and notified affected customers, around a thousand according to a spokesperson speaking to BleepingComputer. It wasn't a rogue package or an attack: it was the official server, from a serious vendor, with an isolation bug.
A record card for each server
The practical consequence is to treat every MCP server like any other integration: with a record card. It isn't the same as the per-tool permissions card we proposed for designing an agent; that one decides what a system someone designed is allowed to do. This one answers an earlier question: what is installed across the company, and who owns it.
| Field | What gets recorded | Which failure it cuts off |
|---|---|---|
| Origin | Who publishes the package, and whether it's the vendor of the system it connects to | The package impersonating a brand, like postmark-mcp |
| Pinned version | A specific version, never “latest”; updates are approved | The malicious version 16 of a package with fifteen clean ones |
| Reviewed descriptions | Tool descriptions are read on approval and compared on update | Tool poisoning and the rug pull |
| Its own credential | A token issued for that server, with minimum scope and an expiry; never someone's personal token | The size of the incident when the official server fails, as with Asana |
| Where it runs | Locally, with the user's privileges, or remotely, and through which components | The intermediate pieces nobody chose, like mcp-remote |
| Owner | One person who answers for the server and decides on its updates | The security advisory that arrives and nobody knows who it affects |
Six fields per server. They fit in a spreadsheet and are maintained like any other inventory
The fourth field deserves a line of its own, because the specification already requires it for remote servers. Since the June 2025 revision, and in the current July 2026 one too, MCP authorization forbids so-called token passthrough: an MCP server must validate that the token was issued for it and must not accept or transit any other. The underlying logic is the one we apply to any integration: each piece with its own credential, so that the token's reach is the incident's reach and no more. Copying an administrator's personal token into an environment variable is exactly the opposite.
The first two fields are the same discipline we asked for with the dependencies an assistant suggests: knowing who publishes what runs, and not letting the version change on its own. The difference is that here there isn't even a lockfile to review. You have to create one.
The control lives in managed configuration, not in a PDF
A record card that only lives in a spreadsheet is documentation. It becomes a control when the client refuses to start anything that isn't on it. The main clients already support this:
- Claude Code supports a
managed-mcp.jsonfile, deployed by the administrator to a system path, with lists of allowed and denied servers and an option to allow only managed ones. - GitHub Copilot enforces allowed and denied server lists from enterprise managed settings in VS Code, the CLI and its app. It announced this as generally available on 6 August 2026; the first version, for VS Code Insiders, dated from September 2025.
- Cursor lets teams on its Enterprise plan control from the admin dashboard which MCP servers members may use.
Almost a year between first version and general availability in GitHub's case says something useful: corporate controls arrive after adoption, not before. If the team has been connecting servers since 2025, today's allowlist lands on an installed base nobody has inventoried. That's why the order matters: inventory first, then the list.
What about the official registry? The MCP Registry, launched in preview on 8 September 2025, is an open catalogue of public servers, useful for knowing what exists. But its moderation works by reporting: the community flags malicious servers and the maintainers remove them afterwards. It isn't a prior security review, and its authors say so: they expect private sub-registries in companies with strict requirements. That private sub-registry is, in practice, the list of record cards in the table above.
The uncomfortable lesson: an allowlist isn't enough
It would be convenient to stop here, with the allowlist as the answer. The cases themselves say otherwise. An allowlist would have approved postmark-mcp before version 1.0.16, and would have done nothing about the bug in Asana's official server, which would be first on any list. The list decides what gets installed. It doesn't decide which version runs tomorrow or how much it can touch when it fails.
That's why the record card has six fields and not one. The pinned version cuts off the first case; its own credential, with minimum scope, limits the second. Neither depends on guessing which server is malicious, which is exactly what nobody can do on installation day. It's the same idea that runs through the minimum required for AI governance: controls that work even when foresight fails.
And a warning in the other direction: banning MCP is not an alternative. Servers are useful, which is why people install them. If onboarding takes three months, people will keep connecting servers in another client or with a personal account, and the inventory will be empty again. The goal isn't to slow adoption down, but to make the approved path more convenient than the shortcut: a short initial list with the servers already in use, pinned versions, credentials issued for each one and onboarding that takes days. It's the same conclusion we reached when comparing Claude, Cursor and Copilot for the enterprise: the tool matters less than the system around it.
Frequently asked questions
What is an MCP server and why does it matter for company security?
An MCP (Model Context Protocol) server is a program that gives an AI assistant access to a tool or to data: email, the repository, the database, the CRM. In most cases it's installed by adding a few lines to a configuration file on a laptop, and it runs with the same permissions as the user. It's an integration with credentials, and it goes through none of the controls the company's other integrations go through.
How is an MCP server different from a code dependency?
A dependency comes in through the project's lockfile, shows up in a pull request and appears in the software inventory. An MCP server lives in each person's local configuration, outside the repository, and is often launched with a command that downloads the latest version of the package every time it starts. It carries the same supply-chain risks as a dependency, but none of the controls.
What is tool poisoning in MCP?
It's an attack described by Invariant Labs in April 2025: the server hides instructions in a tool's description, which the user doesn't see and the model does read. One variant, the rug pull, consists of changing that description after the user has approved the server. That's why the MCP specification itself asks for tool descriptions to be treated as untrusted unless they come from a trusted server.
Can the official MCP registry tell you which servers are safe?
Not on its own. The MCP Registry, launched in preview in September 2025, is an open catalogue of public servers. Its moderation relies on the community flagging malicious servers so they can be removed afterwards, not on a prior security review. Its own authors expect companies with strict requirements to run private sub-registries with their own list.
How do you limit which MCP servers the team can use?
Through each client's managed configuration, not through a policy in a document. Claude Code supports a managed-mcp.json file with lists of allowed and denied servers; GitHub Copilot offers allowlists in its enterprise settings, generally available since August 2026 for VS Code, the CLI and its app; and Cursor supports it on its Enterprise plan. The list goes together with pinned versions and a short path for requesting new servers.
Should MCP servers be banned?
No. Banning something useful only takes it out of sight: people will keep using it with their personal account or in another client. What works is an inventory, a short list of approved servers with pinned versions and their own credentials, and an onboarding process that takes days, not months. The goal is for the approved path to be more convenient than the shortcut.
Sources
- Model Context Protocol, specification revision 2026-07-28: “Authorization” and “Security Best Practices”.
- Luca Beurer-Kellner and Marc Fischer (Invariant Labs), “MCP Security Notification: Tool Poisoning Attacks”, 1 April 2025.
- Tal Skverer (Astrix Security), “State of MCP Server Security 2025”, 15 October 2025.
- Postmark, “Information regarding malicious postmark-mcp package”, 25 September 2025; Shweta Sharma, CSO Online, 26 September 2025; Ravie Lakshmanan, The Hacker News, 29 September 2025.
- JFrog Security Research, CVE-2025-6514 in mcp-remote, 9 July 2025; The Hacker News, 10 July 2025.
- Bill Toulas, “Asana warns MCP AI feature exposed customer data to other orgs”, BleepingComputer, 18 June 2025.
- OWASP, MCP Top 10 (beta, 2025) and Top 10 for Agentic Applications for 2026, 9 December 2025.
- David Soria Parra et al., “Introducing the MCP Registry”, 8 September 2025.
- Admin documentation: Claude Code, GitHub Copilot (6 August 2026) and Cursor.
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →