MCP Server Ecosystem for Enterprise Teams
Sixteen months after launch, the MCP SDK was pulling 97 million monthly downloads. Sit with that number for a second. This is not a niche developer tool that a few forward-thinking teams are piloting in a sandbox. It is infrastructure, already at scale, already inside organizations that haven't formally decided to adopt it.
The adoption timeline is worth tracing because the speed is genuinely unusual. Anthropic released the original specification in November 2024. OpenAI adopted it in March 2025. Google DeepMind followed in April 2025. Named enterprise deployments include Block, Bloomberg, and Amazon, alongside hundreds of Fortune 500 companies that are quieter about it. When three of the largest AI labs in the world converge on a single protocol within six months of its release, the protocol has won. The debate about whether MCP becomes the standard is already over.
Governance followed, as it does when a technology reaches this kind of inflection point. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation. The Steering Committee now includes Anthropic, OpenAI, Microsoft, Google, and Amazon. That configuration is not accidental. It mirrors the pattern that produced HTTP and OAuth: a technology that starts as someone's proprietary invention becomes common infrastructure once the industry decides that competition should happen above the protocol layer, not at it. Nobody competes on HTTP. They compete on what they build with it.
What this means practically for enterprise teams is uncomfortable but clear. They are not deciding whether to engage with MCP. They are deciding how to govern something that is already spreading inside their organizations. Gartner projects that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024, with at least 15% of day-to-day work decisions made autonomously by that same year (Gartner, "Predicts 2025: Agents and AI Models," 2024). The governance question is not coming. It is here.
For anyone still orienting: MCP is to AI agents what OpenAPI is to REST APIs. A common protocol for how agents discover tools, invoke them, read files, and handle contextual prompts. The architecture has three components. Hosts are the AI applications — Claude, Copilot, a custom agent runtime. Clients are the connection managers brokering communication between the host and whatever tools it needs. Servers are the programs that expose those tools and data sources to the agent. Once MCP is in place, an agent can pull customer records from a CRM, update tickets in a project management system, trigger automated workflows across departments, and generate and distribute financial reports. The agent stops producing answers and starts taking actions.
One design decision from the original specification deserves to be named explicitly before going further. MCP was built to make agents capable, not to enforce security. The original spec shipped without a mandatory authentication framework, and the protocol explicitly does not enforce security at the protocol level, placing that responsibility on deployers. That choice shaped everything that followed.
How the server landscape is actually structured: registries, categories, and quality variance
There is no single official registry for MCP servers. They are distributed across GitHub, npm, PyPI, vendor-hosted endpoints, and community aggregators. The major aggregators are MCP.so, Glama, and Smithery. Anthropic maintains a curated list in its official repository, but it was never designed to be exhaustive and does not function as a quality gate.
The functional categories that matter most to enterprise teams are predictable: productivity and communication tools like Slack, Google Workspace, Microsoft 365, and Notion; developer tooling across GitHub, GitLab, Jira, and Linear; data and analytics connections to databases, BI tools, and warehouses; CRM and customer operations via Salesforce, HubSpot, and Zendesk; finance and compliance tooling; and internal or custom servers built for proprietary systems. The category list is not surprising. What is surprising, if you haven't spent time in this ecosystem, is the quality spread within each category.
The ecosystem spans from official vendor-built servers — Cloudflare, Stripe, and Notion all publish and maintain their own implementations — down to individual developer repositories with no ongoing maintenance and no owner monitoring for vulnerabilities. Astrix Research's 2025 analysis of over 5,000 open-source MCP server implementations found that 53% use insecure hardcoded credentials, and approximately 88% of those servers require credentials at all (Astrix Research, "MCP Security Analysis," 2025). This means the majority of servers in the wild are both credential-dependent and insecure by default.
That is the modal condition of the current ecosystem. Not an edge case, not a worst-case scenario used to make a point. The typical server.
The constraint for enterprise teams is not server availability. Thousands of servers exist, and the count grows weekly. The constraint is discernment: the ability to evaluate server quality and provenance before any of them touch production systems. The servers are there. The frameworks for vetting them are not.
What makes a specific MCP server safe to run in an enterprise environment
Credential handling is where most assessments should start, because it is almost always the most revealing signal about how seriously a server was built. The safe pattern is short-lived tokens, credentials issued by an external identity provider, just-in-time provisioning scoped to the specific task. The unsafe pattern is hardcoded API keys or long-lived secrets sitting in static configuration files. Datadog security research uncovered more than 12,000 exposed API keys and passwords through insecure MCP credential handling (Datadog Security Research, 2025). Common paths like ~/.cursor/mcp.json are specific, documented targets for tool poisoning attacks designed to exfiltrate credentials. The path is known. The files are being looked for.
Scope and permission surface is closely related and frequently underweighted. The question is not just whether a server requests the permissions it actually needs, but whether it aggregates broad access across multiple services in ways that create confused deputy problems. If the MCP server holds elevated permissions and acts on a user's behalf without enforcing that user's actual access level, a lower-privileged user can reach resources they should not see. Asana's MCP integration demonstrated this in production: a flaw in authentication and session management allowed one customer's AI agent to access another customer's data. Not a theoretical risk; a production incident.
Provenance and update behavior introduce a wrinkle that credential hygiene alone cannot address. A server that passed review at install time can be updated with malicious instructions post-install. The rug pull risk is distinct from evaluating the server at the moment of initial deployment, and it is easy to overlook because most security reviews happen once. Tool name collision is a related problem: a malicious server registers tools with names similar to legitimate ones, and the agent selects the wrong one because it is reading tool descriptions, not verifying provenance. The first confirmed malicious MCP package appeared in the npm ecosystem in September 2025, operated undetected for two weeks, and exfiltrated email data the entire time.
Tool description integrity is the filter that connects most directly to the injection problem. Agents read tool descriptions to decide which tool to call. Tool poisoning embeds malicious instructions inside those descriptions. MCPTox benchmark testing found that o1-mini showed a 72.8% attack success rate against tool poisoning (MCPTox benchmark, 2025). More capable models are more susceptible, not less, because better reasoning makes them more likely to follow sophisticated embedded instructions. The smarter the agent, the more effectively you can manipulate it by abusing the trust it places in tool descriptions.
Even vendor-built servers are not immune, which is a point worth dwelling on. Figma's MCP server, catalogued as CVE-2025-53967, allowed remote code execution through command injection. Figma is not an obscure project. If official vendor implementations carry critical vulnerabilities, no server should be trusted without scrutiny, regardless of who built it or how prominent the logo on the documentation page.
Why prompt injection through MCP is a distinct problem from standard LLM prompt injection
Standard prompt injection places malicious instructions directly in user input, and the model receives them. That vector is well understood, and most security teams have at least a mental model for it. MCP-enabled prompt injection is structurally different and considerably harder to catch in practice.
In the agentic context, the agent fetches external content through an MCP server: a document, a web page, a support ticket, a database record. That content carries embedded instructions. The attack surface is no longer just what the user types; it is every data source the agent is authorized to read. Which, depending on the deployment, is often quite a lot.
Context poisoning is one variant: a legitimate MCP server fetches an external document containing embedded malicious instructions, and the agent executes them. Cross-tool attacks extend this further, where malicious instructions embedded in one server's output influence the agent's behavior toward other connected servers. The agent is connecting multiple tool calls into a coherent workflow, and the injected instruction travels with it across the chain.
Prompt injection appeared in 73% of production AI deployments studied in 2025 and holds the top spot on the OWASP Top 10 for LLM Applications (OWASP, "Top 10 for LLM Applications," 2025). The Supabase Cursor agent incident in June 2025 is a useful illustration of how this plays out in practice: a privileged agent processing user-supplied support tickets was tricked into leaking integration tokens through prompt injection. An internal tool, processing external content, triggered a credential exfiltration. The injection came from the content, not from a user with malicious intent.
Three factors make agentic injection harder to catch than traditional injection. The agent acts before a human reviews the output. The injected instruction is invisible in the document a human would read — formatted in white text, hidden in metadata, or buried in a footnote. And the blast radius extends to every tool the agent can call, not just the response it generates. Traditional injection affects an answer. Agentic injection can affect a cascade of actions across multiple systems.
Content that flows through MCP servers, not just user prompts, has to be treated as a potential injection vector. That is a materially different perimeter than most security teams are currently monitoring.
How shadow MCP usage creates governance gaps that are already inside most enterprises
The term shadow MCP was introduced by Mend.io in 2025 to describe a problem that was already well underway before anyone named it. Employees install MCP servers in their local development environments — Cursor, VS Code, Claude Desktop — without IT or security visibility. Research from 2025 found that 82% of enterprises already have AI agents or workflows their security teams did not know existed, and 68% of employees use unapproved AI tools (Mend.io, "Shadow AI in the Enterprise," 2025). Shadow AI costs enterprises an average of $412,000 per year, and MCP makes the problem easier to scale and harder to detect.
Installing a new MCP server is a one-line configuration change. There is no IT approval workflow, no app store review, no procurement process. The server connects to production data systems using the employee's own credentials, or worse, hardcoded shared credentials. An employee connects a personal OAuth account to a work tool and creates a data pathway that exists entirely outside any enterprise boundary, often without fully understanding that they've done it.
CVE-2025-6514 illustrates the exposure surface: malicious servers exploiting the mcp-remote OAuth proxy compromised over 437,000 developer environments. That is the scale of unmanaged MCP usage. It is not a projection.
The policy problem has two parts, and you have to solve both. Most enterprises lack the visibility to detect shadow MCP in the first place. And most enterprises also lack an approved-server catalog that would give employees a governed alternative, which means restriction alone doesn't solve anything. Employees who install unapproved servers are, in almost every case, trying to be productive. They found a tool that makes their work faster. The governance response has to be a faster, less obstructive path, not a dead end. If the approved path is slower than the workaround, people will take the workaround, and you'll have shadow usage anyway, just with more paperwork around it.
What Enterprise-Managed Authorization actually changes about how MCP access works
The original MCP authorization model was built for individual users, not organizations. A security team could not enforce consistent access policy, maintain a single audit trail, or centrally revoke access across the environment. Every user was managing their own server connections, which meant authorization was distributed, opaque, and impossible to audit at scale. For a personal productivity tool, that is fine. For enterprise infrastructure, it is not.
The Enterprise-Managed Authorization extension, which became stable on June 18, 2026, as part of the official MCP specification under the Linux Foundation, changes the architecture of that decision in a meaningful way.
Under EMA, the organization's identity provider becomes the authoritative decision-maker for MCP server access. Administrators define access policy once. Users authenticate with existing enterprise credentials and receive provisioned server access on first login, without a per-app OAuth flow for each individual user. Access decisions can incorporate group membership, role, and conditional access rules already defined in the IdP. Organizations that have already built role-based access into their identity infrastructure can extend that model directly into MCP without rebuilding it.
Centralized revocation is the most operationally significant change, and it is the one that tends to land hardest when you explain it to an IT team that has been managing offboarding manually. Revoking an employee's access to MCP servers happens at the IdP level and takes effect immediately across all MCP clients. No per-client, per-server revocation process. When an employee offboards or changes roles, the access change propagates. That is the behavior you expect from mature enterprise infrastructure.
The underlying mechanism is the Identity Assertion JWT Authorization Grant, now an IETF draft. Okta's implementation, branded as Cross App Access, is the first to ship support. Anthropic, Microsoft, and Okta are among the early adopters.
EMA is meaningful progress, and it is also explicitly limited — worth saying clearly. It governs who can access which servers. It does not govern what those servers do once accessed, which tools they call, or whether their behavior is auditable. That requires a layer above the protocol, and the protocol was never going to provide it.
The governance controls enterprises need on top of the protocol itself
Least privilege at the tool level is the starting point, and the distinction that matters here is between server-level and tool-level access control. Policies should restrict not just which servers an agent can connect to, but which tools within a server it can invoke. A finance agent that needs read access to a data warehouse should not inherit the server's write permissions simply because the server has them. Confused deputy problems occur precisely because the MCP server holds broader permissions than the user initiating the action, and policy enforcement that operates only at server connection time will miss this entirely. Tool-call-level enforcement is where the gap actually lives.
Credential lifecycle is the next control, and it follows naturally from the credential problems in the server landscape. Just-in-time credentials, scoped to the specific task and revoked on completion, are the standard to hold to. Long-lived secrets in configuration files are not acceptable in production enterprise deployments. OAuth 2.1 with PKCE is the baseline for any remote server accessed by human users or interactive agents, and treating it as optional is how you end up with 12,000 exposed API keys.
Every tool call should be logged: the identity that initiated it, the server it went to, the tool called, the result returned. Tamper-proof audit logs are not optional in SOC 2, HIPAA, or GDPR contexts. Beyond raw logging, OpenTelemetry tracing gives platform teams the ability to reconstruct the full chain of agent actions across multiple tool calls, which is the only way to understand what actually happened when something goes wrong. And something will go wrong. The question is whether you'll be able to reconstruct it.
Runtime detection addresses the limit of everything that precedes it. Prompt injection and tool poisoning cannot be fully prevented at configuration time; they emerge from content and behavior, not from how the system was set up. Runtime detection of intent drift, unexpected tool call patterns, and exfiltration behavior is required. CVE-2025-49596, rated CVSS 9.4, allowed unauthenticated MCP Inspector instances to execute arbitrary commands. Configuration-time controls don't catch that. Runtime monitoring — watching for anomalous behavior as it happens — does.
The approved-server catalog is the control that addresses shadow MCP directly, and it is the one that most governance frameworks skip because it requires ongoing operational work rather than a one-time policy decision. A catalog of vetted, approved servers gives employees a governed path that is actually faster than hunting through community aggregators and installing something unvetted. Without it, you are in the position of restricting something without providing an alternative, which produces shadow usage rather than preventing it. The catalog has to be maintained, it has to be kept current, and it has to be easier to use than the alternative. That is the bar.
MCP is real infrastructure now, and it behaves like infrastructure: it spreads, it connects to things, and the cost of retrofitting governance after the fact is significantly higher than building it in from the start. The teams who treat this as an identity and access management problem, not an IT curiosity, will be in a fundamentally different position when the first serious incident happens. And the teams who don't will spend a lot of time explaining what a configuration file is and why it was sitting on someone's laptop with a production API key in it.
