At A Glance
- MCP adoption is moving at developer speed, but security architecture review is failing to keep pace.
- The two most common ways teams expose MCP servers today (public hostname or internal jump host) both violate Zero Trust principles, and neither gives you the visibility or containment a compromised agent session requires.
- The fix is architectural, not another control bolted onto the perimeter: outbound-only connections, cryptographically bound agent identity, and full session observability.
When REST APIs became the dominant integration pattern in the early 2010s, enterprises spent nearly a decade retrofitting security controls around them: API gateways, OAuth, web application firewalls (WAFs), and eventually dedicated API security platforms to catch what WAFs couldn’t. The market caught up eventually. But the attack surface existed for years before it did.
MCP is following the same curve, compressed from years into months. And if you’re the one responsible for the network architecture, that compression is the problem you’re actually being asked to solve.
Developers are connecting AI agents to CRMs, ERPs, internal APIs, and proprietary data stores because MCP makes it easy. What almost never gets asked, and what your team may have no visibility into once a server is live, is whether the connectivity model those developers chose creates risk. 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 the agent itself cannot directly reach.
The problem is how most teams expose that server to the agent. As an architect, you’ve likely already seen one of these two patterns show up on a diagram you didn’t design:
- 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 flaw: the server is reachable by anyone on the internet who can enumerate the endpoint or intercept a credential. It has to 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, and your segmentation model just inherited a blast radius it wasn’t built to contain.
Neither pattern reflects Zero Trust principles. Both create exposure that firewalls, WAFs, and network segmentation weren’t designed to address at the agent-to-tool level.
Why MCP Security Isn’t an API Gateway Problem
Your team learned to manage REST API risk because the model was relatively stable: a human-built client called a human-designed endpoint, tokens had defined scopes, and traffic patterns were predictable enough to baseline and monitor.
MCP changes three things that matter for how you architect around it.
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 you 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 can reach, across every session.
The session context carries risk
MCP servers receive the agent’s reasoning context alongside tool requests. If an attacker injects content into that context (prompt injection in a document the agent reads, a poisoned tool result from an earlier call, 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 that influence travels through, which means your logging has to capture more than source IP and destination port.
The inventory is invisible
Most security teams have no systematic way to discover which MCP servers their developers have deployed, which agents connect to them, what tools those servers expose, or whether those tools touch 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 than the last one did.
Secure MCP Server Connectivity: Zero Trust Requirements for AI
The architectural principle that resolves this isn’t new. It’s the same outbound-only, identity-bound, least-privilege model Zero Trust networking has always demanded. What’s new is applying it specifically to the agent-to-MCP-server connection, a segment where none of your existing controls currently 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 rather than filtering traffic to it.
The agent’s identity should be cryptographically bound to the connection
Not an API key or 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, that identity binding limits the blast radius to exactly the tools it’s authorized to call, because there’s 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 your team in real time. Governance that exists only in policy documents isn’t governance.
How to Secure MCP Servers Before the Window Closes
The MCP ecosystem is moving fast. Anthropic’s Claude MCP Tunnel, shipped as a research preview 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. If your organization runs multiple LLMs, private models, or AI-infused SaaS applications, you need this architecture applied universally, across every agent and MCP server, regardless of which model sits behind it. That’s the gap NetFoundry’s MCP Gateway is built to close: outbound-only connections, cryptographically bound workload identities, and full session observability, without requiring you to expose your perimeter or restructure internal networks.
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 every subsequent agent deployment follows. If you engage now, while the MCP footprint is still small and the architecture decisions are still fluid, you can set the right patterns before they’re locked in. Wait for an incident to force the conversation, and you’ll be retrofitting controls onto infrastructure that was never designed to accommodate them.
The API security industry spent ten years learning that lesson. MCP doesn’t have ten years.
See how NetFoundry secures MCP deployments →
Frequently Asked Questions
What is an MCP server and why does it create security risk?
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. NetFoundry’s 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?
It 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 anyone who finds it can use, but with a credential mathematically tied to that specific agent. Third, every session should be fully logged: which agent, which tool, what it did, and when. NetFoundry’s MCP Gateway delivers all three without requiring you to restructure your network or change firewall rules.
What is the difference between MCP security and traditional API security?
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 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. NetFoundry’s 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 defend.
What is a workload identity and why does it matter for MCP deployments?
A workload identity gives 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 cryptographically tied to a specific agent process, so it can’t be copied and used elsewhere. NetFoundry’s 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?
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 there’s no door on the outside at all. NetFoundry’s MCP Gateway has the server reach out through a private tunnel to meet authorized agents, initiating the connection from the inside out rather than 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.
