Vendor Risk Assessment for MCP Servers
There is a specific moment where the governance instinct fails, and it happens fast. A developer finds a third-party MCP server …
There is a specific moment where the governance instinct fails, and it happens fast. A developer finds a third-party MCP server that does something useful (pulls from a CRM, sends emails, queries an internal database), drops it into an agent workflow, and moves on. The whole interaction takes maybe four minutes. Nobody files a ticket. Nobody notifies procurement. The assumption doing the most damage in that moment is a subtle one: that connecting an MCP server feels like installing a browser extension, so it must carry roughly the same risk profile.
It doesn't. The gap is enormous. But what if that assumption is more structurally embedded than it appears — baked into the very instincts that normally make developers fast and effective?
What makes MCP's attack surface different from conventional software vendor risk
When an agent connects to a third-party MCP server, three things happen that don't happen when you install an extension or authorize a SaaS integration. First, the server gains the authority to define what tools the agent can call and, critically, how those tools are described in natural language. Second, the server receives OAuth tokens and credentials that span multiple connected services simultaneously. Third, the agent acts on the server's outputs, often without a human anywhere in the confirmation loop.
That is not a peripheral integration. That is a third party sitting inside the agent's reasoning process with the ability to shape what the agent believes it can do. Why exactly does this matter more than a conventional third-party dependency? Because the attack surface isn't in the code — it's in the language the agent reads and trusts.
The MCP specification is explicit about what this means from a security standpoint: the protocol deliberately does not enforce security at the protocol level, placing implementation responsibility entirely on the connecting organization. This wasn't an oversight. It was a design choice. The implication for any security team is that there is no infrastructure backstop, no platform-level guardrail catching what you miss. The risk management burden lands on you completely.
Three structural properties of MCP create an attack surface that doesn't map cleanly onto anything in conventional vendor risk methodology.
Tool metadata is natural language. Tool names and descriptions are text the LLM interprets, not code a static analyzer can inspect. That distinction matters enormously. The malicious payload in a tool poisoning attack doesn't look like shellcode. It looks like instructions embedded in a tool description, written in plain English, telling the agent to exfiltrate data or modify a record while appearing to do something benign. The MCPTox benchmark found an 84.2% attack success rate for this class of attack under auto-approval conditions. Standard code review catches none of it, because there's no code to review.
Tool definitions can change at runtime without any client notification. A server that passed your security review at installation can silently redefine its tools at the next session. This is the mechanism behind what researchers call the rug pull: establish legitimacy, acquire permissions, then alter behavior after the access relationship is set. MCP clients typically do not flag tool definition changes between sessions.
Agents act autonomously on tool outputs. There is no mandatory human confirmation layer between a malicious tool response and a consequential action. In conventional software integrations, a user clicks, reviews, approves. In agentic deployments, the agent receives a tool output and acts. The window for human intervention is narrow by design, which is what makes the protocol useful, and what makes compromised behavior so difficult to interrupt.
The attack classes that flow from these properties include tool poisoning, silent redefinition, credential and token aggregation across multiple services, supply chain compromise through typosquatting and hijacked registry listings, and cross-server cascade. On that last one: Palo Alto Networks Unit 42 measured a 78.3% attack success rate when five MCP servers were connected to a single AI agent, with a 72.4% cascade rate when multiple servers are compromised. Risk compounds with every additional server you connect.
There's also prompt injection via MCP context, which OWASP ranks as the top LLM vulnerability. In agentic deployments it doesn't arrive through user input. It arrives through content the server retrieves: emails, documents, support tickets, anything the server pulls and passes into the agent's context window.
What unites all of these vectors is that they operate in runtime behavior and natural language, rather than in source code. They are invisible to the review methods most vendor risk processes rely on.
One concrete incident illustrates the rug pull scenario with uncomfortable specificity. An unofficial Postmark MCP server with roughly 1,500 weekly downloads was modified post-install to silently BCC all outgoing emails to an attacker-controlled address. Koi Security estimated approximately 300 organizations had integrated it into real workflows before discovery. The server hadn't changed names. Its listed functionality hadn't changed. The tool description just quietly included new behavior.
The baseline security posture of the MCP server ecosystem today
Before evaluating any individual server, it helps to calibrate against the ecosystem baseline, because the default posture is worse than most security teams expect. It is also worth considering what that baseline implies about the burden of proof before any single server review even begins.
An audit of 17 popular MCP servers found an average security score of 34 out of 100, with every single server lacking permission declarations. That's the starting condition.
Authentication is the foundational gap. Astrix Security's analysis of over 5,200 open-source implementations found that 88% of MCP servers require credentials to operate, but 53% of those rely on insecure long-lived static secrets, API keys and personal access tokens, while OAuth adoption sits at just 8.5%. By early 2026, security researchers had catalogued nearly 7,000 internet-exposed MCP servers, with roughly half operating without any authentication controls at all.
Code-level vulnerabilities are pervasive, not exceptional. Equixly's research found 43% of tested servers vulnerable to command injection. Endor Labs found that 82% of 2,614 implementations use file operations prone to path traversal. Enkrypt AI scanned 1,000 servers and found critical vulnerabilities in a third of them.
The CVE velocity is accelerating. Over 30 CVEs targeting MCP servers, clients, and infrastructure were filed in a two-month window in early 2026. One of them, CVE-2025-6514 with a CVSS score of 9.6, affected the mcp-remote proxy across more than 437,000 installed environments.
Sitting alongside this supply-side problem is a governance gap on the buyer side. Only 29% of organizations report feeling prepared to secure agentic AI applications, per Cisco's 2026 State of AI Security report. Only 14.4% of agents reach production with full security approval.
The practical implication of all this: the default assumption going into a vendor risk review of an MCP server should be "not secure until demonstrated otherwise." The burden of proof runs in that direction. This isn't pessimism. It's just calibration.
Existing vendor risk frameworks cover most of the ground — with four gaps that need MCP-specific additions
Standard vendor risk evaluation is actually a reasonable starting point. Authentication and access control posture, vulnerability disclosure and patch cadence, data handling and retention practices, supply chain provenance, contractual security obligations, incident response commitments: these categories apply directly to MCP servers and should not be skipped in any assessment.
The OWASP MCP Top 10 (beta, 2025) offers the most structured public taxonomy of MCP-specific risks. Token mismanagement, excessive permissions, supply chain compromise, prompt injection and tool poisoning, context over-sharing, insufficient authentication, shadow MCP servers: these map directly onto where standard frameworks fall short.
There are four specific gaps where conventional vendor risk assessment doesn't reach.
Gap 1: Tool definition integrity. Standard assessments evaluate code. MCP risk lives in natural-language metadata that changes at runtime. No conventional audit process covers this, because no conventional audit process was designed for a world where the thing being audited is a paragraph of English text that an AI reads and acts on.
Gap 2: Post-install behavior change. Standard assessments are point-in-time. You review a vendor, you approve them, you move on. Rug pull attacks are specifically designed to exploit the absence of monitoring after initial approval. A server that passes review at install and changes behavior six weeks later will never surface in a static, one-time assessment.
Gap 3: Agent identity and permission scope. Most vendor risk frameworks ask what a vendor's system can do. They don't ask what the agent connecting to it is authorized to do on the organization's side. These are separate questions with separate answers. An overprivileged agent amplifies every vulnerability on the vendor side. If the server is compromised and the agent can write to production databases, the blast radius is determined by the agent's permissions, not just the server's behavior.
Gap 4: Cross-server blast radius. Standard assessment evaluates one vendor in isolation. MCP cascade risk means the security posture of any individual server is partly a function of what other servers are connected to the same agent. A low-risk server connected to three high-risk servers in a shared context creates compound exposure that no single-vendor review will surface.
A structured vendor risk assessment framework for MCP servers
The framework runs in five stages. The order matters; each stage gates the next.
Stage 1: Registry and provenance check
Start with the simplest questions. Is the server listed in a trusted, vetted registry, or only in an unverified directory? Who published it, and can you verify that identity? Is the package name a plausible typosquat of something well-known?
Review publish and update history: first publication date, update frequency, whether any updates were silent with no accompanying changelog. Check for CVEs against the server name, its dependencies, and its transport layer.
One important calibration here: the Smithery registry compromise, in which a path-traversal vulnerability exposed over 3,000 credentials despite those servers having passed submission screening, illustrates that marketplace provenance is one input to a trust decision, not a substitute for review. A server appearing in a registry means it cleared that registry's bar. It does not mean it cleared yours.
Stage 2: Authentication and credential handling
Does the server use OAuth 2.0 or equivalent modern authentication, or does it rely on static API keys and personal access tokens? Are credentials scoped to minimum necessary permissions, or does the server request broad scopes to accommodate every possible use case?
Where are credentials stored, and what happens to them if the server is compromised? Can they be revoked independently of the server? Does the server aggregate tokens for multiple downstream services? If so, map every service whose credentials transit that server. The credential aggregation pattern (one server holding OAuth tokens for Gmail, Drive, Calendar, and Slack simultaneously) creates a single-compromise, multi-service exposure that needs to be mapped explicitly.
Given that over half of open-source MCP implementations rely on long-lived static secrets, treat static credential reliance as a significant risk flag requiring compensating controls, not a disqualifier by itself, but something that demands documented mitigation.
Stage 3: Tool definition and permission scope review
Enumerate every tool the server exposes: names, descriptions, parameter schemas. Do the descriptions match what the server actually does? Look for unusual length, hidden Unicode characters, or instructions embedded within natural-language descriptions. The malicious content in a tool poisoning attack often looks like verbosity.
Does the server declare the permissions each tool requires, or does it request a single broad permission set for everything? Can write and delete operations be disabled independently of read operations? Given that the 17-server audit found zero servers providing permission declarations, this review will often require direct inquiry to the vendor rather than documentation review.
Map the blast radius explicitly. If this server's tools were called with the permissions being requested, and if the server behaved maliciously, what is the worst-case impact on your data and systems? Write that down. Make it concrete.
Stage 4: Vendor security posture and disclosure practices
Does the vendor publish a security policy or maintain a responsible disclosure program? What is their patch cadence for disclosed vulnerabilities, and is there a track record to evaluate? Do they provide a software bill of materials or equivalent dependency transparency?
Have they had prior incidents, and how were those incidents disclosed and remediated? The Postmark scenario's approximately 300-organization impact was partly a product of delayed, informal disclosure. How a vendor handles the first incident tells you a great deal about how they'll handle the next one.
For any server intended for production use, contractual commitments should cover notification timelines for security incidents and, specifically, notification of any material tool definition changes. That last requirement will be unusual to most vendors. That's precisely why it needs to be in writing.
Stage 5: Runtime controls and ongoing monitoring requirements
This stage is what converts a point-in-time assessment into continuous governance. It addresses the rug pull gap directly. But how does this affect our original promise of structured, repeatable review? It extends it — from a gate at entry into an ongoing obligation.
Establish a baseline of tool definitions at the time of approval. Any change to tool names, descriptions, or parameter schemas should trigger a re-review before the agent is permitted to use updated definitions. Instrument agent interactions with the server: what tools are being called, with what inputs, what outputs are being returned, what actions are being taken downstream.
Set permission boundaries at the agent level, not just the server level. Limit what the agent is authorized to act on regardless of what the server offers. Define a review trigger: if the server issues an update, who is responsible for re-running stages one through four before the update reaches production?
Assign the server a record in a central registry: owner, approval date, approved tool version, review cadence. An ungoverned server entry is an identity the organization cannot account for. In a well-run security program, that's an unacceptable condition.
How to tier MCP servers by risk level before allocating assessment effort
No security team can run all five stages on every MCP server. The ecosystem is too large, the deployment pace too fast. Over 9,400 public servers were indexed across major registries by mid-2026, with private and enterprise-internal servers estimated conservatively at three to four times that number. Tiering based on access scope is how you apply the framework without it becoming a bottleneck.
Tier 1, high risk, requires the full five-stage assessment. This tier includes any server with write or delete access to production data or systems, any server that aggregates credentials for multiple services, any server handling regulated data such as PII, financial records, or health information, and any server connected to an agent operating without a human confirmation step before consequential actions. The aggregate exposure in any of these conditions is significant enough to warrant the full review.
Tier 2, medium risk, requires stages one through three plus abbreviated versions of stages four and five. This covers servers with read-only access to internal data, servers connecting to a single downstream service with limited credential scope, and agents operating with human review before acting on tool outputs. The exposure is real but bounded; the review can be proportionally less intensive.
Tier 3, lower risk, requires stages one and two plus a registry review. This is appropriate for servers that expose only public or non-sensitive data, operate in sandboxed or development environments, and carry no credential aggregation or write permissions. The assessment is lighter, but it still happens. The temptation to skip assessment entirely for "low-risk" servers is exactly how shadow MCP proliferation begins.
Tiering isn't about reducing rigor. It's about directing rigor where the exposure is. The instinct that created the governance failure described at the start of this piece (the "click, connect, done" reflex) didn't come from laziness. It came from not having a calibrated sense of what was actually being connected. The framework above is an attempt to provide that calibration, applied proportionally based on what each server actually touches.
The ecosystem is large, moving quickly, and, by its own specification's acknowledgment, operating without protocol-level security guarantees. That context doesn't make MCP servers unusable. It makes unstructured vendor governance indefensible.
