AI agents, Without the Operational and Security Headaches

May 29, 2026

Enterprises Want the Universal 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 but simply access enterprise resources (tools, APIs, databases) but without requiring inbound site exposure or public MCP servers. Claude MCP Tunnel helps enterprises use AI but without severe operational and security headaches.

However, it only solves the AI agent problem if Claude is the AI. How can enterprises get a similar solution when they run multiple public and private LLMs, as well as AI-infused SaaS with similar challenges – a universal solution to AI agent access?

Fortunately, NetFoundry Connect provides the same architecture as Claude MCP Tunnel, but for all AI agents. In fact, NetFoundry already does it for billions of API, site-to-site and machine-to-machine sessions for thousands for enterprises.

How Claude MCP Tunnels and NetFoundry Connect Work

Claude MCP Tunnels and NetFoundry Connect 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, deployed as a container or VM in the enterprise network, opens a single, authenticated, outbound, least privilege connection towards the agents – regardless of where the agents are.

How Enterprises Use NetFoundry Connect

Enterprises are moving from copilots and simple coding assistants to agentic workflows. Agents need tools to do their jobs which means two things:

The agent needs a standard interface to the tools – hence the birth of MCP
The agent needs connectivity to the tools but they live behind firewalls and in private VPCs and VNets – hence this zero trust MCP architecture.

This makes agents be realistic to deploy to production – they help operations manage the agents and resources, while providing visibility, controls and governance.

That’s why Claude added MCP Tunnel and that’s why the outbound-only, identity-bound, no perimeter exposure pattern is becoming the default way agentic platforms reach data inside an enterprise.

When enterprises are building agentic solutions (whether on Claude, GPT, Gemini, or self-hosted models), what do those agents need to access? What are the challenges with and without NetFoundry Connect? Let’s look at three examples.

Three Agentic Use Cases – With and Without NetFoundry Connect

Customer Support Agent

Without NetFoundry:

The enterprise has 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 LLM provider’s tenant to the enterprise. Most enterprises won’t do this because the LLM provider doesn’t generally support it. However, if the provider does, or if the LLM is a private LLM in the enterprise network, then the enterprise doesn’t like the option because it flattens the 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.

With NetFoundry:

The MCP servers sit on their normal private subnets. A small gateway daemon on a hardened VM in the corporate cloud network dials out to the LLM provider (or self hosted LLM), presenting a client identity tied to the agent’s workload identity in the IdP.
The firewall is reduced to outbound rule to one well-known destination.
Per-tool authorization happens at the MCP server itself, scoped by the calling agent’s identity passed through the tunnel header.

No public DNS, no DMZ, no VPN. 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.

Security Operations Agent (SOC agent or AI-SOC)

Without NetFoundry:

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:

Running the agent on a dedicated jump host inside the network
Sticking the LLM call out to the public API and accepting that prompts and tool results leave the network, or running a smaller LLM model on-prem and accepting the capability trade-off.

Note: security teams reject the option of exposing the SIEM and EDR consoles through a public reverse proxy due to the data sensitivity.

With NetFoundry:

The large-model agent runs at the LLM provider, or in the enterprise network. The zero trust MCP tunnel terminates inside the SOC’s segmented network.
MCP servers wrap 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.

Engineering or Coding Agent

Without NetFoundry:

Two main options:

Option one replicates the relevant repositories out to a SaaS service that the LLM provider can reach. This can work but doubles surface area to synchronize and breaks for any code that can’t legally leave the network (e.g. export-controlled, regulated, classified, customer-confidential under specific clauses).
Option two deploys a reverse proxy on the DMZ with an allow-list of LLM-provider egress IPs. This can work for one repo, doesn’t scale well to ten, breaks the moment the LLM provider rotates an IP range, and is exactly the kind of bespoke perimeter exception that auditors flag at every assessment.

With NetFoundry:

The internal GitHub/GitLab/Jira instances stay where they are – not exposed to the network.
An MCP gateway runs alongside the rest of the developer-platform infrastructure. The coding agent reaches the right MCP servers through the tunnel
The tool-authorization layer makes sure the agent only sees the repos the requesting developer can already see. Code never leaves the enterprise except via the LLM’s reasoning loop. Note: that is a different policy decision the customer makes once, at the LLM-provider level, rather than per-tool, but some LLM providers do allow the reasoning loop to move to the enterprise premises.

Do Enterprises Need NetFoundry Connect for Self-hosted LLMs?

This question comes up because self-hosted LLMs can be deployed inside the enterprise’s private network – it may not have the outside-the-firewall problem.

Not needed:

For those self-hosted LLM deployments, the question is whether it is functionally an island? Are all LLM interaction at the same site? If so, NetFoundry Connect may not be needed.

Needed:

However, when the agent that wraps the model needs to reach tools across sites, business units, subsidiaries, or partners, then NetFoundry Connect to simplify operations, strengthen security and add the governance layer which can’t be provided by networking, VPNs and firewalls.

Do Enterprises Need NetFoundry Connect for Cloud AI such as Google, AWS, Azure, Oracle and Alibaba?

Most of these have ‘PrivateLink’ type options which are cloud-provider VPNs inside each region which keep the traffic off the Internet.

Not needed:

The critical question: is the cloud region an island? If all the data the AI needs for training and inference, and all the systems it needs to talk to, are in that same cloud region, then NetFoundry Connect may not be needed.

Needed:

The headache is often getting the data in and out of the cloud region – e.g. getting the data from other sites to AWS Bedrock or Google Vertex and feeding downstream systems. Some enterprises use MPLS or VPNs for this, while others use NetFoundry Connect to do it simpler.

How Does Stronger Security Make Operations Simpler?

Decrease firewall management. One firewall rule per tunnel target, outbound only. The perimeter change board’s job shrinks from approving inbound rules per MCP server to approving a single outbound TLS connection per LLM provider.
No public MCP server management. No public DNS, no NAT, no DMZ hardening overhead for the MCP server fleet. The MCP servers can live on the same internal network as the data they wrap.
No public exposure of MCP servers. The single largest attack-surface reduction the architecture delivers. The enterprise never publishes the MCP server’s hostname or IP to the internet, so the scanner population that drives most opportunistic exploitation traffic can’t see it.
No coupling to LLM-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.
No dependency on the LLM provider’s tunnel infrastructure (e.g. Claude MCP Tunnel). The enterprise now controls the connections, across all LLMs – public and private.
Certificate and identity lifecycle. NetFoundry takes care of gateway authentication, key rotation and revocation.
Data residency and sovereignty. Enterprises can self-host all NetFoundry solution aspects, or use NetFoundry’s managed services. It is based on NetFoundry’s open source, OpenZiti.
Identity, authentication, authorization. NetFoundry includes identity, authentication and authorization. Enterprises can choose to do IdP integrations but are now forced to. The gateway authenticates (mTLS0 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.
Tool access controls. Agents do not have access to any tools they are not explicitly granted access to – NetFoundry will not even enumerate them.
Audit and SIEM integration. NetFoundry tags every session with the identity and policy which enabled it. NetFoundry’s Data Connectors connect to leading SIEMs.
Change management. Adding a new MCP server is now assigning identities and attributes – not a firewall-rule decision.
No inbound firewall holes. Eliminates the class of pre-auth-RCE-in-edge-appliance breaches that produced Fortinet, Citrix Netscaler, Ivanti, and SonicWall incidents over the past three years.
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.

How Enterprises Get the Same Architecture Across Multiple LLMs

Claude MCP Tunnel is tied to…Claude. An enterprise that wants to route some workloads to Claude, some to GPT, some to a self-hosted Llama, some to Gemini needs a vendor-neutral overlay that sits between the LLM(s) and the enterprise’s MCP servers.

This is what NetFoundry Connect provides. Two layers are involved:

Layer 1 — AI gateway. Sits between the calling application (or the user’s chat UI) and whichever LLM provider is going to do the inference. Handles model routing, fallback, prompt-budget and cost control, content moderation, prompt logging, and an OpenAI-compatible API surface so applications don’t have to know which provider is on the other end.
Layer 2 — MCP gateway. Sits between whichever LLM provider’s agent loop is currently active and the enterprise’s MCP servers. The overlay’s job is to give every LLM provider exactly the same kind of identity-bound, outbound-only path into the enterprise that Anthropic’s MCP Tunnel gives Anthropic.

The combined pattern: a single enterprise-operated AI gateway terminates user requests, decides which model to call, and ships the tool-call portion of the agent loop through a single enterprise-operated overlay to the MCP servers — regardless of which LLM produced the tool call. The LLM provider is now a stateless inference backend, not the owner of the customer’s network architecture. This is the only pattern that survives the inevitable cycle of LLM-provider re-pricing, re-pricing, model deprecation, and the next vendor-of-the-year swap.

NetFoundry Connect

Because NetFoundry Connect is built on OpenZiti open source, enterprises get additional extensibility, lock-in protection and security (clear, traceable, auditable code and SBOM). This is ideal for enterprises that need to control the entire stack: open-source, customer-operated, no third-party tunnel control plane.

NetFoundry Connect extends beyond AI: it is an identity-first, outbound-only overlay (self-hosted or NetFoundry hosted) for any type of session:

Identity built in. Every endpoint (gateway, MCP server, agent caller) enrolls into the overlay with its own cryptographic identity — X.509 by default, with optional integration to SPIFFE/SPIRE or to an enterprise IdP for human-bound identities. There is no separate ‘service account in the MCP server’s environment variable’ problem to solve.
Authentication built in. Mutual TLS for every connection, no exceptions, with short-lived certs and automatic rotation. The MCP server does not need to implement its own TLS-with-client-cert authentication path; the overlay has already authenticated the caller by the time the call reaches the server.
Authorization built in (at the service level). Policy at the overlay grants identity-to-service access — agent caller X can connect to MCP service Y, full stop, no L3 connectivity exists otherwise. Per-call, per-tool authorization (which agent can call which tool with which arguments) still lives in the MCP server’s policy engine, but the network-layer authorization is solved without a separate ZTNA product.
Closed-by-default by construction. There is no L3 path from any endpoint to any other endpoint unless an authorization policy has explicitly created a service grant. This is the operational property the Section 6 ‘smaller blast radius’ line depends on, and it is delivered without a separate firewall, microsegmentation, or service-mesh product.
Audit built in. Every session — identity, service, time, bytes, success/failure — is logged at the overlay control plane. The enterprise still feeds this into its SIEM, but does not have to invent the source data.

Yes, it is full zero trust security, but the architecture means that six-month integrations of AI and other applications turn into fast deployments which don’t touch firewalls and networking.

Summary

Claude MCP Tunnel is important because it helps make it realistic for enterprises to deploy agentic AI – visibility, controls, governance.

Perfect timing – enterprises are moving from copilots to agentic workflows. Agents need tools to do their jobs which means:

The agent needs a standard interface to the tools – hence the birth of MCP
The agent needs connectivity to the tools but they live behind firewalls and in private VPCs and VNets – hence this zero trust MCP architecture.

That’s why it was important for Claude MCP Tunnels to show how a cloud-hosted AI agent can safely use private enterprise resources without creating operational and security headaches for the enterprise – without requiring inbound firewall exposure, public MCP servers, VPNs or brittle IP allowlists. Check out my previous blog on “Why Claude MCP Tunnel Matters” here.

For enterprises who need that simplification and security across all public and private LLM models, NetFoundry Connect provides the solution.