AI providers need their version of Claude MCP Tunnel
Claude MCP Tunnel was announced in May 2026 to solve one of the most important problems in agentic AI: how AI agents can securely access enterprise resources (tools, APIs, databases) without requiring inbound site exposure or public MCP servers.
However, it only solves the AI agent problem if Claude is the AI, leaving behind three important questions:
- How can enterprises deploy agents from other (public and private) AI model providers?
- How can enterprises deploy AI-infused SaaS?
- How can enterprises deploy AI-native solutions?
Quite simply, most enterprise buyers will not deploy an agent that requires inbound firewall changes or public exposure of internal systems. A provider without an outbound-only, zero trust option is locked out, especially now that providers like Claude are offering solutions.
In effect, every other LLM provider, every traditional SaaS adding agentic features, and every AI-native company selling into enterprise will be measured against this Claude Tunnel bar by buyers. The ones which can’t solve it quickly will be forced to try to explain why their reverse proxy and IP allow-list are ‘good enough’ while their competitor hands the enterprise an easy button solution.
Fortunately, NetFoundry Connect is built for providers to solve this problem. NetFoundry Connect provides the same architecture as Claude MCP Tunnel, but NetFoundry already does it for billions of API, site-to-site and machine-to-machine sessions for thousands of enterprises, including two of the largest five companies in the world. It leads to deployments in days.
“NetFoundry enables Rhapsody to securely connect different types of sites and workloads, including AI agents, APIs and humans.”
— Kevin Day, CTO, Rhapsody Health
NetFoundry Connect is available to AI providers as an instant-on turnkey solution or as an integrated, white-label option.
How NetFoundry Connect Works
NetFoundry Connect (and Claude MCP Tunnels) enable zero trust connections between AI agents and MCP servers inside the enterprise’s network without the enterprise exposing their perimeter.
Instead, a NetFoundry MCP Gateway opens a single, authenticated, outbound, least privilege connection towards the agents – regardless of where the agents are. The gateway can be built into the AI provider’s software (via NetFoundry’s SDKs), or deployed as a separate sidecar, container or VM.
Is this important for SaaS, ISV and software providers as they add agentic capabilities?
For 20 years, public SaaS had one dominant model: the customer’s browser or thick client called the SaaS; the SaaS never needed to reach into the customer’s network.
The directionality made the perimeter security model easy for the enterprise customer: the customer’s firewall only had to allow outbound HTTPS.
Agentic AI breaks that model. An agent on the SaaS provider’s cloud that helps the customer do their work is constantly reaching for context that lives in systems the SaaS provider doesn’t host. Many are in the customer’s own network: the data warehouse, the ERP, the EHR, the CMDB, the source-of-record file shares, the on-prem identity system.
As soon as the SaaS provider’s agent needs to call those, the SaaS provider has the inbound-reach problem the LLM providers like Claude have. These providers are in three main groups:
- The giant vendors who needed inbound access to their customer networks shipped zero trust before they had the internal firepower to build and manage architectures similar to NetFoundry Customer Connect. SAP Connect and ServiceNow MID are good examples. They are in decent shape to deliver AI.
- Other vendors who required pre-AI inbound access to their customer’s enterprise networks use solutions like NetFoundry, and so simply extend their Customer Connect solution to AI. Rhapsody Health (case study) is an excellent example.
- In other cases, it is AI which is causing the need. The initial response from many of these SaaS, ISV and software vendors is to try to get the customer to send the necessary data to the vendor cloud. This can work for some agentic use cases, but otherwise the vendor needs to use a solution like NetFoundry Customer Connect, or build and manage their own solution.
Two agentic use cases: with and without NetFoundry Connect
AI providers, including LLMs, small models, AI-infused SaaS and native AI applications, will sell more, close enterprise deals quicker and deploy more easily by using NetFoundry Connect as their version of the Claude MCP Tunnel solution. Let’s look at two specific examples:
Use case #1: customer support agent
Provider trying to sell without NetFoundry Connect:
This provider gives the potential enterprise customer two main options:
- Publish an MCP server on a public DNS name behind load balancers, CDN and/or WAF. The cost: a new public attack surface to add to the patching and pen-test cadence of any other internet-facing service; a constantly-rotating allowlist of LLM-provider egress IPs; the risk that the agent flows melt the WAF and rate-limiters.
- Option two is to stand up a site-to-site VPN from the provider’s tenant to the enterprise. However, this flattens the enterprise network in a direction the security team has spent a decade undoing and makes the LLM provider’s cloud part of the enterprise’s PCI/ISO/SOC2 scope.
Provider trying to sell while enabled by NetFoundry Connect:
- The MCP servers sit on their normal private subnets. A small gateway daemon on a hardened VM in the corporate cloud network, or embedded in the provider’s software, dials out to the AI provider, presenting a client identity tied to the agent’s workload identity.
- The firewall is reduced to outbound rule to one well-known destination via private, zero trust overlay.
No public DNS, no DMZ, no VPN. No compensating controls. No multi-week audit. The blast radius if the agent is compromised is exactly the tools the agent is authorized to call because there is no network path to anything else.
Use case #2: Security operations agent (SOC agent or AI-SOC agent)
Provider trying to sell without NetFoundry Connect:
Exposing a SOC agent on the network means a successful attacker gains the same tooling and information the defenders have so most SOC teams that have tried to wire up an agent have ended up with two bad choices:
- Run the agent on a dedicated jump host inside the network
- Stick the LLM call out to the public API and accep that prompts and tool results leave the network
- Run a smaller LLM model on-prem and accepting the capability trade-off.
Note: most security teams reject the option of exposing the SIEM and EDR consoles through a public reverse proxy due to the data sensitivity so the largest AI-SOC providers are building custom versions of NetFoundry Connect.
Provider trying to sell while enabled by NetFoundry Connect:
- The large-model agent runs at the AI provider or in the enterprise network while the zero trust MCP tunnel terminates inside the SOC’s segmented network.
- NetFoundry’s zero trust MCP gateway wraps the SIEM, SOAR, EDR, CMDB, and ticketing systems. The agent never sees a public hostname for any of those systems; the LLM provider’s infrastructure never has a route to them.
- Tool authorization is per-call at the MCP server, with the analyst’s identity passed through.
This enables a SOC or AI-SOC to adopt a frontier model without exposing the agent or exporting sensitive telemetry to the public internet.
How do AI providers use NetFoundry Connect to sell more of their products?
Most enterprise buyers will not deploy an agent that requires inbound firewall changes or public exposure of internal systems. An AI provider without an outbound-only, zero trust option is locked out, especially now that providers like Claude have raised the bar on what the enterprise demands. On the other hand, the AI providers which use NetFoundry Connect enable their enterprise customers to get the security, simplicity and operational posture they need:
- Decrease firewall management. One firewall rule, outbound only, to the AI provider’s private, zero trust overlay (managed by NetFoundry or self-hosted by the AI provider).
- No public MCP server management. No public DNS, no NAT, no DMZ hardening for the MCP server fleet. The MCP servers can live on the same internal network as the data they wrap. The single largest attack-surface reduction the architecture delivers – the scanner population that drives most exploitation traffic can’t see it.
- No coupling to AI-provider egress IP ranges. Reverse-proxy and ACL-based patterns break every time the provider rotates IPs.
- Gain visibility and per-call observability. Because all agent-to-MCP traffic flows through a known gateway, the enterprise gets clean logs at the gateway.
- Identity, authentication, authorization. NetFoundry includes identity, authentication and authorization. Enterprises can choose to do IdP integrations but are now forced to. The gateway authenticates (mTLS) to NetFoundry’s control plane and MCP servers authenticate to the gateway. NetFoundry includes per-tool, per-call authorization.
- Secret and credential management. NetFoundry means the agents don’t have access to API keys, shared secrets or service accounts.
- Audit and SIEM integration. NetFoundry tags ever session with the identity and policy which enabled it. NetFoundry’s Data Connectors connect to leading SIEMs.
- Strong, identity-bound transport. The tunnel typically presents a client X.509 to the provider control plane and another to the MCP server — mTLS at both ends, which is what most regulatory frameworks (PCI-DSS 4.0.1 control 4.2, FFIEC authentication guidance, HHS HIPAA Security Rule §164.312) now prefer for system-to-system auth.
- Smaller blast radius. Agents can only call MCP servers the agent was authorized to call — they cannot pivot to anything else on the enterprise network, because there is no inbound network path.
Summary
Claude MCP Tunnel is important because it helps make it realistic for enterprises to deploy agentic AI – visibility, controls, governance. However, there are AI solutions outside of Claude. Those providers use NetFoundry Connect to meet their enterprise customers’ needs for simplicity and security in a similar way as Anthropic is.
Synthesis
Claude MCP Tunnel is important because it is the first time the largest single AI lab has put a name and a public product around the network architecture that agentic computing has obviously needed since the moment agents started reaching for tools. The architecture itself is not novel — Microsoft’s data gateway, Salesforce’s Private Connect, ServiceNow’s MID Server, OpenAI’s tunnel-client, and the zero-trust-overlay world have all been variations on the same theme. What is novel is the concession from Anthropic, the frontier-model leader, that the right place for the model to live and the right place for the customer’s data to live are different places, and that the bridge between them has to be outbound-only, identity-bound, and operated by software that the customer trusts.
Every other LLM provider, every traditional SaaS adding agentic features, and every AI-native company selling into enterprise will be measured against this bar by buyers within the next twelve months. The ones that already have an architecture in this shape (Microsoft, Salesforce, OpenAI, ServiceNow, IBM, Glean, Writer, Moveworks-via-ServiceNow) will close enterprise deals faster. The ones that don’t will spend the next year explaining why their reverse proxy and IP allow-list are ‘really the same thing.’ They are not.
For the enterprise reading this paper: the right posture is to assume the tunnel pattern is the floor, not the ceiling. Pick or build the overlay that is yours, not your LLM provider’s; put it in front of every LLM you might ever use; and treat the LLM as the replaceable component that it now is. The connectivity, identity, and authorization architecture you stand up this year will outlast three generations of frontier models.
