When REST APIs became the dominant integration pattern in the early 2010s, enterprises spent nearly a decade retrofitting security controls around them — building API gateways, layering on OAuth, deploying web application firewalls (WAFs), and eventually standing up dedicated API security platforms to handle discovery and threat detection problems that WAFs couldn’t touch. The market caught up. But the attack surface existed for years before it did.
MCP is following the same curve, compressed from years into months.
Teams are connecting AI agents to CRMs, ERPs, internal APIs, and proprietary data stores because MCP makes it easy. What those teams are almost never asking — and what their security organizations rarely have visibility into — is whether the connectivity model they’re using creates risks. .In nearly every deployment we see at NetFoundry, it does.
How MCP Servers Expand Your Enterprise Attack Surface
An MCP server is an endpoint. It receives requests from an AI agent, executes operations against the resources it’s connected to, and returns results. In a well-designed deployment, the MCP server sits inside the enterprise network with access to internal systems that the agent itself cannot directly reach.
The problem is how most teams expose that MCP server to the agent. The two most common patterns are:
- Publish the MCP server on a public hostname, put a load balancer in front of it, and rely on API keys or OAuth tokens to authenticate the agent. This is the same pattern enterprises used for REST APIs in 2012, and it carries the same fundamental flaw — the server is reachable by anyone on the internet who can enumerate the endpoint or intercept a credential. It must be reachable, because the agent needs to find it.
- Run the agent inside the enterprise network on a jump host or dedicated VM, keeping everything internal. This avoids public exposure but creates a different problem: the agent — which may be calling an external LLM API, ingesting user-supplied prompts, and taking actions across multiple connected tools — now sits on a trusted internal segment with network-level access to systems far beyond what it needs. A single compromised agent session becomes a pivot point.
Neither pattern reflects Zero Trust principles. Both create exposure that traditional security controls — firewalls, WAFs, network segmentation — weren’t designed to address at the agent-to-tool level.
Why MCP Security Isn’t an API Gateway Problem
Enterprise security teams learned to manage REST API risk because the model was relatively stable: a human-built client called a human-designed endpoint, authentication tokens had defined scopes, and traffic patterns were predictable enough to baseline and monitor.
MCP changes three things that matter for security:
- The client is autonomous. An AI agent doesn’t just call an endpoint — it decides which endpoints to call, in what sequence, with what parameters, based on reasoning that the enterprise cannot fully predict or constrain in advance. The attack surface isn’t just the MCP server; it’s the full action space of every tool the agent has access to, across every session.
- The session context carries risk. MCP servers receive the agent’s reasoning context alongside tool requests. If an attacker can inject content into that context — through prompt injection in a document the agent reads, a poisoned tool result from an earlier call, or a malicious MCP server the agent was directed to — they can influence subsequent tool calls within the same session. The MCP connection is the channel through which that influence travels.
- The inventory is invisible. Most enterprises have no systematic way to discover which MCP servers their teams have deployed, which agents are connected to them, what tools those servers expose, or whether those tools carry access to sensitive systems. The shadow API problem from a decade ago — unsanctioned endpoints, forgotten test servers, undocumented integrations — is re-emerging as a shadow MCP problem, and it’s building up faster.
Secure MCP Server Connectivity: Zero Trust Requirements for AI
The architectural principle that resolves these problems isn’t new — it’s the same outbound-only, identity-bound, least-privilege model that Zero Trust networking has always demanded. What’s new is applying it specifically to the agent-to-MCP-server connection, where none of the existing controls operate.
The MCP server should not be reachable from the internet. It should live on a private subnet with no inbound connectivity. Instead of the agent reaching in to find the server, the server dials out to meet the agent through an authenticated, encrypted, outbound-only tunnel — eliminating the public attack surface entirely.
The agent’s identity should be cryptographically bound to the connection. Not an API key or an OAuth token that can be stolen and replayed. The agent should present a cryptographically secured workload identity that the tunnel validates before any MCP traffic flows. If the agent is compromised, the identity binding limits the blast radius to exactly the tools that identity is authorized to call — because there is no network path to anything else.
Every MCP session should be governed and observable. Which agent, not which IP address, called which tool, at what time, with what parameters, producing what result — that record needs to exist, be tamper-resistant, and be accessible to the security team in real time. Governance that exists only in policy documents isn’t governance.
Why the MCP Security Window is Closing, and What to Do
The MCP ecosystem is moving fast. Anthropic’s Claude MCP Tunnel, announced in May 2026, validated the outbound-only, identity-first architecture as the right model for enterprise AI agent connectivity, but it addresses only Claude-based deployments. Enterprises running multiple LLMs, private models, or AI-infused SaaS applications need this architecture applied universally, across every agent and MCP server, regardless of which model is behind them. That’s the gap NetFoundry’s MCP Gateway is built to close.
The teams deploying agents today are making architectural decisions that will be expensive to unwind. A developer who wires an MCP server to a production CRM through a public hostname isn’t making a temporary choice — they’re establishing a pattern that every subsequent agent deployment follows. Security teams that engage now, while the MCP footprint is still small and the architecture decisions are still fluid, can establish the right patterns before they’re locked in. Teams that wait for an incident to force the conversation will find they’re retrofitting controls onto an infrastructure that was never designed to accommodate them.
The API security industry spent ten years learning that lesson. MCP doesn’t have ten years.
Frequently Asked Questions
What is an MCP server and why does it create security risk?
NetFoundry builds security infrastructure around a simple observation: MCP servers are the connective tissue between AI agents and the enterprise systems they act on — databases, CRMs, internal tools, workflows. The security problem is where those servers live. Most teams either put them on the public internet (protected only by a password or token that can be stolen) or deep inside the corporate network (where a hijacked AI agent can roam freely once it’s in). Neither is safe. Our MCP Gateway solves this by making MCP servers invisible to the internet entirely — the server reaches out to meet the agent through a private, encrypted tunnel, rather than sitting exposed waiting for connections.
How do you secure AI agents and MCP servers with Zero Trust?
NetFoundry’s approach comes down to three principles. First, the MCP server should never be reachable from the internet — no open ports, no public address, nothing for an attacker to find. Second, every AI agent should prove its identity cryptographically before it’s allowed to connect — not with a password or API key that anyone who finds it can use, but with a credential that’s mathematically tied to that specific agent. Third, every session should be fully logged: which agent, which tool, what it did, and when. Our MCP Gateway delivers all three without requiring enterprises to restructure their networks or change their firewall rules.
What is the difference between MCP security and traditional API security?
NetFoundry’s position is that the tools enterprises already use to secure APIs — firewalls, traffic filters, login tokens — were designed for a world where humans built the software making requests and those requests followed predictable patterns. AI agents break all three assumptions. They decide for themselves what to call and in what order. They can be manipulated into taking harmful actions if an attacker slips malicious instructions into something the agent reads. And they multiply fast — most security teams have no idea how many MCP servers their developers have already spun up or what those servers can access. Our MCP Gateway addresses the root problem rather than patching around it: if the MCP server has no reachable address, there’s nothing for traditional security tools to need to defend.
What is a workload identity and why does it matter for MCP deployments?
NetFoundry uses the term “workload identity” to describe something straightforward: giving software its own verifiable ID, the same way an employee badge identifies a person. Most AI agent deployments today rely on API keys — essentially shared passwords that get copied into configuration files, passed between systems, and occasionally leaked. A workload identity is different. It’s cryptographically tied to a specific agent process, so it can’t be copied and used somewhere else. Our MCP Gateway enforces this at the connection level — before an agent can reach any tool, it has to present its identity, and if it can’t, the connection never happens.
What does “no open ports” mean for MCP server security?
NetFoundry’s “no open ports” model is easiest to understand by contrast. In a traditional setup, an MCP server sits on the network waiting for incoming connections, like a store with its door open. Anyone who finds the address can try the door. “No open ports” means the store has no door on the outside at all. Instead, our MCP Gateway has the server reach out through a private tunnel to meet authorized agents — the connection is initiated from the inside out, not the outside in. There’s no address to find, no port to probe, no surface to attack. The MCP server is effectively invisible to anyone who isn’t already authorized to use it.
NetFoundry’s MCP Gateway was built specifically for this architecture: outbound-only connections, cryptographically bound workload identities, and full session observability – without requiring enterprises to expose their perimeter or restructure internal networks. If your teams are deploying AI agents today, the architectural decisions they make now will be expensive to untangle later.
See how NetFoundry secures MCP deployments →
