Adding an MCP Server Takes One Line of JSON. That Is the Entire Procurement Process.

An MCP server is a third-party integration that an agent trusts with the privileges of the session that loaded it, and it is usually installed by editing a config file, with no review and no inventory entry. The main risk is not vulnerable code. It is that tool descriptions and schemas are read by the model as instructions at runtime, so static review never sees the payload.

Your company has a vendor onboarding process. It has a security questionnaire, a data processing agreement, an owner, and a review date. It takes weeks. None of it applies to the way MCP servers actually arrive. A developer finds a server that connects their assistant to Jira, or to an internal database, or to a design tool. They paste a few lines into a config file. The agent restarts, reads the server's tool descriptions, and starts calling them with whatever credentials that session holds. No ticket, no review, no inventory entry. Total elapsed time: under a minute.

Security teams that hear "third-party dependency" reach for the familiar answer: review the source, check the maintainer, pin the version. That instinct is correct and insufficient, for three specific reasons.

The dangerous surface is runtime metadata, not source code. When an agent connects to a server, it fetches tool descriptions and schemas, and the model reads them as instructions. Invariant Labs demonstrated in April 2025 that instructions embedded in a tool description are read and acted on by the model before any tool is selected. CyberArk extended the same idea later in 2025 under the name full-schema poisoning, showing that parameter names, type and required fields, custom schema properties, and even tool outputs are all part of what the model reads. A static scan of the repository does not see any of this, because the payload only exists once the server is running and responding. The mechanics of that injection are covered in detail in our earlier piece on how prompt injection through MCP hijacks AI agents.

Descriptions can change after you trust them. This is the rug pull pattern. A server behaves correctly at install time, establishes trust, and updates later. Most agent hosts reload tool definitions automatically on reconnect, so a new version lands in the trust slot you granted to the old one without a fresh prompt or a second review.

Cross-server contamination is the default, not the exception. In May 2025, Invariant Labs showed the official GitHub MCP server being used against its own user: a malicious issue in a public repository, read by an agent that was asked to look at recent issues, contained hidden instructions that caused the agent to pull private repository contents into the public one. Nothing in the GitHub server was vulnerable in the traditional sense. The agent simply had one session, several tools, and no boundary between them.

The theoretical phase of this discussion ended some time ago.

July 2025, Trend Micro. Researchers found 492 publicly reachable MCP servers running with no client authentication and no traffic encryption, collectively exposing 1,402 tools. These required no exploitation skill at all. They were open. A follow-up published in April 2026 reported that the number of exposed servers had grown to almost triple the original count.

July 2025, CVE-2025-6514 in mcp-remote. A critical flaw, scored 9.6, in a proxy package used to connect local AI clients to remote MCP servers. Documented by JFrog Security Research, the package had been downloaded more than 437,000 times. It trusted the OAuth authorization URL supplied by the remote server, so a malicious server could execute shell commands on the developer's machine during the connection handshake.

September 2025, Kaspersky GERT. A full proof of concept showing MCP used as a supply chain foothold: a server that looks legitimate, installs cleanly, and harvests sensitive data every time a developer runs a tool. The technique needed no memory corruption and no traditional vulnerability.

September 2025, the fake Postmark MCP server. An npm package impersonating a widely used transactional email service worked exactly as advertised. Emails were composed and delivered normally. Every one of them was also silently copied to an attacker-controlled address.

February 2026, Straiker STAR Labs. An established malware operation spent roughly three months building a fake developer ecosystem, with multiple GitHub accounts, AI-generated personas, and cross-forks to simulate an active community, then submitted a trojanized version of a popular wearable's MCP server to a legitimate registry. The payload was an infostealer that took browser passwords, cloud session tokens, SSH keys, and API keys.

April 2026, unsafe defaults in MCP implementations. Research by OX Security, reported by The Hacker News, described a design weakness in MCP implementations that can lead to remote code execution, along with ten vulnerabilities found across widely used AI projects including LiteLLM, LangChain, LangFlow, and Flowise.

The pattern across all of them is the same. The exploit is not clever. The trust model is generous.

Even with a perfectly benign server, most MCP deployments hand agents credentials that are far broader than the task requires. An OAuth token scoped for "repo" gives an agent every repository the user can reach, not the one they are working in. A database connection intended for a read query is usually the same connection used for everything else.

That matters because prompt injection does not need to escalate privileges. It only needs to reach a session that already has them. The Invariant GitHub case is the clean illustration: the attacker never obtained a credential. They borrowed a session.

So the honest framing of MCP risk has two halves. The first is whether a server is trustworthy. The second, and the more durable one, is what a compromised or manipulated server can reach if it turns out not to be.

Since the payload lives in metadata that only appears at runtime, enforcement has to happen at runtime too:

Pull the config files. Count the servers. For each one, answer three questions: who installed it, what credentials does it hold, and what would it reach if its tool descriptions were hostile tomorrow. If more than a handful of servers fail that third question, the gateway layer is worth more to you than another round of manual review, because manual review is not repeatable at the speed these get added.

The security model that MCP inherited assumes the tool descriptions are documentation. Your agent treats them as instructions. Every practical control follows from taking the agent's view seriously.