How Secure Is Your MCP Gateway? Lessons from a Year of Incidents

In this article, we'll look at what a year of MCP security research reveals about the structural risks of shared MCP gateway hosting, use the prominent Smithery incident as the clearest illustration of how those risks materialize, and outline what enterprise teams should evaluate in any managed MCP platform before trusting it with production data access.

A year of MCP security incidents, and what they have in common

When GitGuardian researcher Gaetan Ferry disclosed a path traversal vulnerability in Smithery.ai in June 2025, it was easy to read as a one-off: a misconfigured build parameter, a responsible disclosure, a 48-hour patch. Move on.

The months since have made it harder to read it that way. In September 2025, the first malicious MCP packages appeared in public registries — typosquatting, fake official servers, dependency injection. That same month, an unofficial Postmark MCP server with 1,500 weekly downloads was quietly modified to add a BCC field to its send_email function, silently copying every outgoing email to an attacker's address. No error. No alert. The tool worked exactly as expected — it just also worked for someone else. In July 2025, Trend Micro's scan found 492 MCP server instances running with no authentication and no traffic encryption. By early 2026, that exposure had widened to the cloud. A March 2026 analysis of over 3,000 MCP servers found that only 8.5% use OAuth. The rest rely on static, long-term API keys — credentials that don't expire, can't be easily scoped, and remain valid until someone manually rotates them.

Smithery wasn't a warning that went unheeded. It was the first clearly documented example of a risk class that has since been confirmed repeatedly across the MCP ecosystem. The question for enterprise teams is not whether to take MCP security seriously. It's whether the infrastructure you're building on was designed to handle it.

What happened at Smithery: the clearest example of the hosting model risk

Smithery.ai is an MCP server hosting registry. The model is straightforward: a developer submits a GitHub repository containing MCP server code, and Smithery builds and hosts the resulting server on shared infrastructure running on fly.io. It's a convenient way to get an MCP server running without managing your own deployment pipeline.

The vulnerability was in a build configuration parameter called dockerBuildPath, found in each server's smithery.yaml file. Smithery did not validate this parameter. That meant an attacker could point it outside the submitted repository directory — specifically to the parent directory containing the build user's home folder — and use that as the Docker build context. By combining that malicious build configuration with an attacker-controlled Dockerfile, a researcher was able to exfiltrate the build user's .docker/config.json, which contained a fly.io authentication token.

The token was significantly overprivileged. It granted not just Docker registry access but full control of fly.io's machines API, covering every server Smithery hosted — more than 3,000 applications. Had an attacker exploited this before the patch, they could have executed arbitrary code on any of those hosted servers and intercepted the API keys and auth tokens clients were transmitting through them. Smithery patched the issue within 48 hours of disclosure, and there is no confirmed evidence of malicious exploitation before the fix. GitGuardian's original disclosure is thorough and worth reading directly; their research deserves the attribution, and the facts they document are more instructive than any summary.

The structural risk the patch didn't fix

The patch resolves the specific vulnerability. What it does not change is the structural characteristic that turned a single misconfigured build parameter into a potential compromise of thousands of servers and the enterprise systems behind them. That characteristic is the centralized, shared hosting model — and the lesson applies to any platform that executes user-controlled code on shared infrastructure managed by a single operator.

In a shared hosting model, the operator's infrastructure is the foundation every tenant depends on. A single overprivileged credential at the operator level becomes, in effect, a master key. This is not a theoretical risk class; it is the same dynamic that makes supply chain attacks so persistent and difficult to defend against. The attacker's goal in a supply chain attack is not any single organization — it is the trusted shared platform those organizations depend on. Compromise the platform once and you inherit access to every downstream consumer. GitGuardian explicitly compares the Smithery incident to the Salesloft OAuth supply chain compromise, and the structural parallel holds.

MCP servers are a particularly high-value target for this attack pattern. They sit directly between AI agents and enterprise data systems — databases, CRMs, ERPs, financial platforms. An agent doesn't query your Salesforce instance directly; it calls a tool on an MCP server, which authenticates and queries on its behalf. Whoever controls the MCP server controls the data access path. The combination of centralized hosting, shared infrastructure credentials, and static downstream credentials is what makes the blast radius in the Smithery scenario so large — and what makes the broader pattern of MCP security incidents so worth taking seriously.

The deeper question for enterprise security teams is not whether any given platform has addressed any given vulnerability. Most do, eventually. The question is whether the underlying hosting model creates a class of structural risk that is acceptable for the data your AI agents will access.

What secure MCP architecture actually requires

The first question to ask of any managed MCP platform is: what does a breach of this platform actually enable? The answer is determined by architecture, not by a feature list — specifically by how broadly a single breach can propagate, how long it remains exploitable, and how visible it is once it occurs.

Those three dimensions map to three structural properties worth evaluating before you put production data behind any MCP platform.

Blast radius: how far can one compromise travel?  This is primarily a function of credential architecture. If the platform uses shared infrastructure credentials — tokens, keys, or build contexts that span multiple tenants — a single exploited vulnerability can propagate across every connection on the platform. The Smithery incident is the clearest example of how this plays out at scale: one overprivileged token, 3,000+ servers exposed. Platforms that use per-connection, per-user credentials and vendor-maintained connectors — rather than user-controlled build pipelines — limit propagation to the scope of a single compromised connection. The tradeoff is that vendor-maintained connectors create a dependency on the platform's connector roadmap. For most enterprises building production AI infrastructure, that is a reasonable constraint, but worth understanding before committing to a platform.

Exploitation window: how long does exposure last?  The March 2026 analysis finding that only 8.5% of MCP servers use OAuth isn't a coincidence — static API keys are the path of least resistance in the current ecosystem, and they remain valid until someone manually rotates them. An attacker who obtains a static key through a supply chain compromise, a poisoned tool definition, or a hosting breach has as much time as they need. Short-lived, revocable credentials — OAuth 2.0, SSO-backed sessions — reduce this window substantially. This is less about any single platform feature and more about the credential hygiene the platform makes possible or defaults to.

Visibility: how quickly can you detect and bound a breach?  Per-user access enforcement limits what an attacker can reach even after a server is compromised — but only if access policies are configured carefully upfront. A poorly scoped connection offers little real protection regardless of the architecture surrounding it. Audit logging determines how quickly you know something went wrong and what was touched. Both matter, and both require active implementation rather than passive adoption.

With those three lenses in mind, here is how CData Connect AI's architecture holds up against the structural risks the past year of MCP security research makes concrete.

Centralized gateway vs. CData Connect AI: a security architecture comparison

CData Connect AI is an enterprise-grade managed MCP platform. Its architecture addresses the structural risk class the Smithery incident makes newly visible — not by patching specific bugs as they emerge, but by avoiding the design decisions that create the largest blast radii in the first place.

On blast radius, the defense is architectural. Connect AI uses vendor-maintained connectors rather than user-submitted build pipelines. There is no dockerBuildPath equivalent in Connect AI's architecture because there is no mechanism for user-controlled code to execute on CData's shared infrastructure. The attack surface that the Smithery vulnerability occupied simply does not exist in the same form. On all tiers, Connect AI supports user-defined credentials — each user authenticates to a connection using their own service credentials rather than sharing a single set of admin credentials across the platform. There is no shared administrative token spanning all hosted connections, which is the design that made the fly.io token in the Smithery incident so consequential. For organizations that want centralized credential management with an external vault, Azure Key Vault integration is available on the Business tier, enabling credentials to be stored and rotated in the vault rather than in Connect AI directly, with an audit trail for every credential read. One practical note: Key Vault integration currently uses Shared Authentication, so it operates separately from the user-defined credentials model — the right choice depends on whether your priority is per-user isolation or centralized vault control.

On exploitation window, Connect AI's approach is to support the most secure authentication scheme available for each connected data source. Where a source supports OAuth, SSO, or similar short-lived credential models, Connect AI uses them. Where a source only supports static API keys, Connect AI doesn't introduce weaker credentials than the source already requires — but it also can't improve on what the source offers. The platform doesn't flatten everything to the lowest common denominator; it honors the best auth available for each source, which means the exploitation window is bounded by the source's credential model, not degraded by the platform itself. For identity and access to Connect AI directly, both OAuth and Basic Authentication are supported for MCP, alongside SSO integration via SAML, OpenID Connect, Microsoft Entra ID, ADFS, LDAP, Ping Federate, and Okta — enabling organizations to manage Connect AI access through the same identity infrastructure they already use for other services.

On visibility, Connect AI maintains both a Query Log and an Audit Log, capturing timestamps, query text, user identity, and status for every operation — giving security teams the ability to reconstruct what happened and what data was touched. Access permissions are configurable per user and per connection, scoped to specific operations (select, insert, update, delete, execute), so even a compromised session is bounded by what that user was authorized to do. For organizations that require real-time anomaly detection or active alerting on agent behavior, the Query Log and Audit Log are available to feed into existing SIEM tooling. All of this operates under a layered security model covering data at rest and in transit, backed by SOC 2 Type II and ISO-certified security standards.

The table below summarizes the structural differences based on documented capabilities:

What this means for enterprise AI teams

If your organization is currently using a shared MCP gateway service, the past year of MCP security research is a prompt to audit what credentials your AI agents are transmitting through it, whether those credentials are static API keys or short-lived tokens, and what your exposure would be if the gateway's operator-level infrastructure were compromised. Those questions describe scenarios that have moved from theoretical to documented.

If you are evaluating MCP platforms for production deployment, add architectural isolation, credential scoping, and build infrastructure separation to your criteria alongside connector counts and feature lists. The maturity of a platform is not measured only by how many sources it can reach — it is measured by what happens if any part of its infrastructure is compromised. Ask whether the platform executes user-controlled code on shared infrastructure. Ask how credentials are stored, scoped, and rotated. Ask what audit visibility you have into what your agents are actually doing.

Evaluate CData Connect AI for your MCP stack

It just so happens that those are exactly the questions CData Connect AI was designed to answer well. If you want to go deeper before starting a trial, the Security Kit at cdata.com/security/ includes architecture documentation, security policies, and data retention details — the kind of material that belongs in a vendor security review, not a blog post. And if you want to talk through how Connect AI fits your specific MCP deployment, the team at cdata.com/ai can connect you with a solutions architect rather than a sales cycle.