Evaluating MCP Servers for Enterprise Approval and Distribution

Model Context Protocol went from launch to roughly 8 million downloads in about five months. No enterprise security team moves that fast, so most of the servers running in production right now got there without anyone actually checking them. This piece lays out what checking them should look like: security vetting, identity and access control, observability, and a distribution layer that enforces all three at runtime instead of sitting in a policy doc nobody opens twice.

The numbers keep climbing. The ecosystem now counts more than 5,800 MCP servers and 300-plus MCP clients, with SDK downloads pushing toward 97 million a month by early 2026. Forty-one percent of technical leaders in software say their org already runs MCP in limited or broad production. Agentic AI's share of GenAI-driven automation jumped from 4% to 27% in a single year, and Industry projections expect 40% of enterprise apps to carry task-specific AI agents by the end of 2026, up from under 5% in 2025.

And yet: 81% of enterprises have no documented governance for machine-to-machine interactions, and only 9% have anything close to formal agentic access management. Adoption ran ahead. Governance is still finding its shoes. What follows is the framework for closing that gap.

What an MCP server actually touches inside an enterprise

An MCP server carries an agent's own credentials, its own tool-calling rights, and, in a lot of deployments, standing access to production databases, file systems, internal APIs, and whatever SaaS tool someone wired up on a Tuesday afternoon without asking. Snowflake personal access tokens, Jira tokens, SharePoint secrets: these live inside or pass through the server. A traditionally built system keeps those credentials behind tight scoping and an audit trail. A lot of MCP deployments just don't bother.

Call it the N-by-M integration problem, same shape, new coat of paint. Without a shared, governed layer, every AI project stands up its own servers with its own ad hoc credentials, tokens scattered across notebooks, API gateways skipped because nobody thought to route through one. It's the shadow IT pattern that made unmanaged SaaS a headache a decade ago, except this time the shadow tool has direct API reach into production.

Trend Micro found 492 MCP servers sitting exposed on the open internet, no wall, no gate. Prompt injection attacks have demonstrated how an agent can be redirected to access and exfiltrate data it was never meant to touch, exploiting servers that hold access to multiple systems with no tool-level boundary between them. Published CVEs against MCP packages have included missing authentication layers and OAuth proxy flaws enabling OS command injection and remote code execution on the host machine.

None of this needed a nation-state actor. A public GitHub issue and a server that trusted its own inputs a little too much did the job fine.

Shadow MCP ties it together: employees standing up servers without telling IT, handing agents production access nobody signed off on. Recent industry research found 76% of respondents flagging shadow AI as a problem, up from 61% the year before, and autonomous agents now account for more than 12% of reported AI breaches according to recent threat reporting. The pattern is old. The blast radius has grown.

The threat classes specific to MCP that a generic security review will miss

Run a normal API threat model against an MCP server and you'll miss most of what makes it dangerous. The attack surface is new enough that 2025 had to invent its own words for it.

Start with tool poisoning. A malicious tool description manipulates the model's behavior before any human sees what got invoked; the attack sits in the text the model reads, not in a payload a person would inspect. Worse is the rug pull, sometimes called tool shadowing, where a tool's behavior gets silently redefined after approval. The version your team vetted and the version running in production quietly stop being the same thing.

Cross-server cascade attacks multiply the damage. Compromise one server in a connected cluster and the attacker pivots to the rest; researchers have clocked a 72.4% cascade rate once multiple servers are in play. Confused-deputy problems and OAuth weaknesses round it out. The on-behalf-of identity propagation flow is where MCP's OAuth 2.1 implementations most often drift from spec, and that drift is exactly where privilege escalation lives. Stack prompt injection on top, what some researchers call toxic agent flows, where a document or webpage or issue redirects agent behavior mid-session, and the threat model barely overlaps with a standard API review checklist anymore. HackerOne logged a 540% jump in prompt-injection reports.

The scan data backs this up. Offensive-security assessments found 43% of tested MCP servers vulnerable to command injection. A survey of more than 2,600 MCP implementations found 82% use file operations prone to path traversal. A scan of over 7,000 servers found 36.7% vulnerable to server-side request forgery. A scan of 1,000 servers found a third carrying critical vulnerabilities. Pull a server off a public registry, deploy it unvetted, and you're flipping a coin, and not a fair one.

Even servers published by well-known vendors have turned up serious vulnerabilities on review. Trusting the publisher's name isn't the same as reading the code, even when the publisher wrote the protocol. Industry research for 2026 found only 29% of organizations feel prepared to secure agentic AI at all. The threat landscape got there first, and it's not waiting around.

A structured security vetting checklist for MCP server candidates

Vetting isn't a gate you clear once and forget. Given the rug-pull risk above, it has to keep going past intake, because the server approved in March is under no obligation to be the server running in June.

Source and provenance come first. Is the publisher known, with a record of disclosing security issues rather than quietly patching and moving on? Is the code open enough to actually audit, or are you taking it on faith? Does the publisher keep a real changelog, letting you pin a deployment to a specific version instead of floating on "latest"? And has anyone actually read the tool description, the text the model consumes, checking for language crafted to steer agent behavior rather than just describe what the tool does?

Permissions and credentials come next. Does the server ask for only what its job requires, or does it want admin access "just in case"? Broad scope with no documented reason should be an automatic no. Does it expect someone to paste a token into a config file, or does it support credential brokering through a gateway? Can it run at least-privilege, or does it only work with full access to the target system?

Then authentication. Does the server implement OAuth 2.1 per the MCP spec's March 2025 revision? Does it support on-behalf-of identity propagation, tested rather than assumed to work? Can it plug into an identity provider already in place, Okta, Entra ID, SAML or OIDC, instead of forcing its own credential store on you?

Finally, run the scans: static analysis for command injection, path traversal, and SSRF, the three classes with documented rates across the ecosystem, plus a dependency audit on the server's own supply chain and a check against public CVE listings and MCP-specific disclosure feeds.

This should feel like granting an IAM role or provisioning a service account, given the level of access involved. A lightweight SaaS procurement form doesn't carry that weight, and pretending otherwise is how servers slip through. None of this scales as a manual review past a handful of servers, either, so policy-as-code enforcement in CI/CD, blocking deployments with overprivileged configs or banned credential patterns before they reach production, is the only thing that holds up once the count climbs into the hundreds.

Identity, access control, and what "approved for whom" actually means at scale

Approving a server for the org is not the same as approving it for every team, role, and dataset that server can touch. Treating "approved" as one binary state is the mistake almost everyone makes first, and it's the one that breaks the whole process later, quietly, long after anyone remembers making the call.

Fine-grained, role-based access has to be the actual unit you govern. Which teams can invoke which tools inside a given server? Does a developer really need the same access to a Snowflake MCP tool as a finance analyst, just because both teams' servers got approved on the same afternoon? Permissions need scoping at the tool level, not the server level. A server bundling ten tools of wildly different risk under one approval isn't a decision. It's a shrug wearing a checkbox.

Tying access to existing enterprise identity stops being optional past the pilot stage. Manual, per-user credential management works fine for five users and falls apart almost immediately after that. Wiring MCP access through Okta, Entra ID, or SAML/OIDC means access inherits the org's joiner-mover-leaver process automatically, so a departed employee's MCP access disappears the same day their email does. Machine identity needs its own line item here, too: agents and automated workflows need identities that can be scoped, audited, and revoked independently of whatever human happens to be sitting nearby.

An "approved MCP server" label, done right, answers three separate questions: approved for which tools inside that server, approved for which data classification (a server touching PII carries different risk than one reading public docs), and approved under which conditions, read-only or write, human-in-the-loop or fully autonomous. Skip one of those three and you've approved something you can't describe if anyone asks. Between 47% and 53% of organizations report an AI agent exceeding its intended permissions or causing an incident. That's what happens when the server, not the individual tool call, is the thing you thought you were controlling.

Observability requirements that make an approval decision defensible over time

An approval nobody watches starts decaying the day it's signed. Tool descriptions change, usage patterns drift, costs climb, and none of it shows up unless something is actually logging it.

The baseline is audit logging done right: every tool call recorded with caller identity, a timestamp, and the parameters passed, secrets stripped before the log gets written. Those logs need to be immutable and exportable into whatever SIEM the security team already runs, not locked inside a vendor dashboard nobody opens. Layer anomaly detection on top of that. A service account that normally runs 9-to-5 and suddenly fires at 3am is a signal worth investigating.

PII and secrets detection has to sit at the MCP layer itself, scanning tool inputs and outputs in real time before anything crosses the enterprise boundary. This needs to live between agent and server from day one, since reviewing logs after the fact comes too late to catch data already out the door.

Cost and usage telemetry does double duty as governance. Which teams use which tools, at what volume, at what cost? Research projects 40% of agentic AI projects will fail by 2027 over runaway costs, unclear value, and thin governance, and usage telemetry is the only way to see that curve coming before it turns into a write-off. Chargeback and attribution, mapping server usage back to cost centers, should be a default output of the system, not a special request finance has to file every quarter.

Set concrete re-approval triggers. "Approved" with no expiration date just means "approved forever," and nobody can defend that stance in a post-incident review. A published CVE against the server or its dependencies should trigger a fresh look. So should a tool description change in a new release, a jump in requested permissions, or a usage spike that doesn't match the pattern from initial approval.

The governed distribution layer that makes approval operational, not theoretical

A checklist and an access policy document carry limited weight without an enforcement layer sitting between the agent and the server the moment a tool call happens. Paper policy struggles to stop a compromised tool description at 2am; a runtime system can.

This is why the MCP gateway showed up as its own category in 2025, built by the ecosystem rather than specified in the protocol itself. MCP's spec doesn't define this role, yet enterprises needed it anyway, so vendors built it and the market sorted out the rest.

At runtime, a gateway earns its keep four ways. It authenticates the caller before any tool gets invoked. It checks policy per tool, not just "is this server approved" but "is this specific caller allowed to call this specific tool with these specific parameters." It brokers credentials, so the gateway holds the Snowflake token and the Jira token and the SharePoint secret, and neither the user nor the model ever sees them in clear text. And it logs every call at the gateway itself, before the request reaches the server, catching threat signals in real time: prompt injection patterns, PII in transit, secrets surfacing somewhere in a tool's parameters.

Industry projections put 70% of software engineering teams building multimodal applications using AI gateways by 2028, up from 25% in 2025. Three years, and it goes from early-adopter curiosity to expected infrastructure. The official 2026 MCP roadmap admits the gaps outright: audit trails, SSO-integrated auth, and gateway behavior are all still open questions at the spec level. The gateway layer fills those gaps in production today, ahead of whatever future protocol revision addresses them at the spec level.

The field has real options with different strengths. AWS's Bedrock AgentCore Gateway, generally available as of late 2025, uses Cedar for per-tool authorization policies that are versioned and reviewable like any other policy artifact, a strong fit if the org already lives inside AWS. Cloudflare's approach is strongest where the network edge is already the control plane, though moving off Cloudflare One, Workers, and Access later costs something real. IBM's ContextForge is built around federation, aimed at large organizations running MCP estates across multiple environments, regions, or business units.

These tools complement rather than replace the vetting checklist and the access model. Their contribution is to turn the checklist from a document into an enforced default: the difference between a policy that exists on paper and one that actually holds when somebody tests it.