NetFoundry MCP Gateway closes open ports for AI agents
NetFoundry launched MCP and LLM gateways that bind agent tool access to identity instead of public ports, VPN sprawl, and shared API keys.
- What happened: NetFoundry added Zero Trust
MCP GatewayandLLM Gatewayproducts to its AI Enclave portfolio on June 3, 2026.- The launch says OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, and private Ollama access can sit behind an OpenAI-compatible gateway.
- Developer impact: Teams get another pattern for connecting MCP servers without exposing public DNS, inbound ports, WAF rules, VPN reach, or shared secrets.
- Watch: The claimed token savings and prompt-injection filtering are vendor claims. Real results depend on model routing policy, agent-loop design, and tool scope.
NetFoundry added a Zero Trust MCP Gateway and LLM Gateway to its AI Enclave portfolio on June 3, 2026. The announcement frames the release around a practical deployment problem: AI agents, MCP servers, and LLM endpoints increasingly need access to internal systems, but teams do not want to create new public inbound ports, spread API keys across agents, or expand VPN access around every tool server. For developers, "which tools may this agent call?" is no longer the only architectural question. "Where is that tool server reachable from?" is now part of the product design.
The headline business claim is up to 50% AI token cost savings. NetFoundry ties that number to the LLM Gateway's model routing, budget enforcement, and per-identity cost tracking. The same launch describes the gateway as an OpenAI-compatible access layer for OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, and private Ollama instances. Instead of every application carrying separate SDK choices, provider keys, and endpoints, the gateway becomes the point that chooses a model according to cost, latency, data sensitivity, and policy.
The MCP Gateway message is more direct. NetFoundry says MCP-compatible clients can reach internal enterprise MCP servers without making those servers reachable by unauthorized agents or attackers. The release emphasizes structural permission filtering: denied tools are removed from the registry rather than merely rejected at runtime. In practice, that means an agent should not even see tools outside its permitted scope. That is different from showing a tool in the schema and hoping a later authorization check catches misuse.
This is AI infrastructure news because MCP is turning from a developer convenience into a production network surface. An MCP server may expose SQL, ticketing, source repositories, SIEM data, CRM records, file stores, or deployment systems to an agent. A local test can run with one developer machine and a local MCP server. An enterprise rollout has to answer whether the server lives in a private subnet, whether it is reachable over a public endpoint, and which route a cloud model provider uses to reach it. It also has to show whether the human user's identity follows the tool call.
| Area | Common MCP exposure pattern | Gateway pattern in NetFoundry's launch |
|---|---|---|
| Access path | Public DNS, reverse proxy, WAF, allowlist, or provider VPN. | An enterprise-side gateway opens outbound-only connectivity and creates service paths from identity and policy. |
| Authorization basis | Often relies on API keys, service accounts, or IP-based network rules. | Assigns cryptographic identity to agents, MCP servers, and LLM endpoints, then applies service-level authorization. |
| Model calls | The application holds provider-specific endpoints and keys directly. | An OpenAI-compatible gateway centralizes provider routing, budgets, PII policy, and prompt-injection policy. |
| Audit unit | Network logs, API logs, and application logs are split, breaking the agent-action trail. | NetFoundry says agent actions, LLM calls, and tool invocations can be tied into a single audit trail. |
NetFoundry's May 29 official blog explains the product as a generalization of the problem Anthropic addressed with Claude MCP Tunnel. Claude MCP Tunnel helps Anthropic-side agents reach internal MCP servers more safely, but enterprises rarely use only one model provider. A single team may mix Claude, GPT, Gemini, self-hosted Llama-family models, private Ollama, and cloud-provider models by workload. NetFoundry's pitch is to stop treating the LLM provider as the owner of enterprise network architecture and reduce it to an inference backend behind a controlled access plane.
The proposed architecture has two layers. The first is the AI or LLM gateway. It sits in front of a chat UI or calling application, chooses which model provider to use, handles fallback, tracks prompt budgets, enforces cost policy, applies moderation, and exposes an OpenAI-compatible API surface. The second is the MCP gateway. It lets the current agent loop, regardless of which provider runs it, reach internal MCP servers over the same identity-bound and outbound-only path. If the provider changes, the private tool server does not need to be republished or reconnected through a new VPN arrangement.
NetFoundry's AI Enclave solution brief describes this as layer 7 virtual connectivity. The document says every inbound port is closed by default and no routable service path exists until identity and policy allow it. Connection management and visibility are organized around identity rather than IP address. This is not just a security-team detail. When an agent moves across tools while consuming user authority and model budget, IP-based logs alone do not easily reconstruct which agent acted for which user and which tool call triggered the downstream system action.
The LLM Gateway feature list maps closely to the work enterprise AI platform teams already face. NetFoundry describes a three-layer semantic routing cascade made from heuristics, embeddings, and an optional LLM classifier. The gateway can classify a request as cost-sensitive, latency-sensitive, or data-sensitive, then choose a model accordingly. The product also lists PII detection, content safety filtering, topic controls, prompt-injection detection, and team or project budget enforcement. That package starts to look like a model router, AI firewall, and finance dashboard inside one control point.
The "up to 50% token cost saving" claim needs conditions attached. Cost reduction comes less from the existence of a gateway and more from whether routing policy can safely send traffic to cheaper or private models. Deterministic SQL formatting, simple classification, and internal ticket summarization may be good candidates for lower-cost models. Long-context code review, incident response reasoning, or high-risk customer communication may keep using frontier models. A gateway can enforce a cost line, but if the agent task design wastes tokens, the savings shrink.
The MCP Gateway's structural permission filtering is the more interesting engineering detail. Many agent systems place tool schemas into the model prompt. If a forbidden tool remains in the schema, the model may still attempt to call it, and prompt injection can target the tool name or argument shape. If denied tools are removed from the registry, the model's visible action space is smaller. That is closer to "the tool does not exist for this agent" than "the call fails after the model tries it."
This connects to the recent push to treat agents as first-class identities. Ping Identity announced agent discovery, lifecycle governance, and privileged access for desktop coding agents on May 27, 2026, with an emphasis on avoiding long-lived secrets inside agents. Workday Agent Passport and Microsoft Agent 365 approach related questions from the application and identity-governance layers. NetFoundry is working at the point where identity policy and network reachability meet.
The competitive field is broad. Anthropic Claude MCP Tunnel starts from one provider experience. Cloudflare Tunnel, Tailscale, and Teleport have long addressed private resource access from the networking and security side. In LLM gateways, Vercel AI Gateway, LiteLLM, Portkey, OpenRouter, and cloud-provider model routers all compete for the model-control surface. NetFoundry's differentiator is its attempt to combine an OpenZiti-based zero-trust fabric, MCP gateway, LLM gateway, and identity-first reachability into an enterprise-operated architecture.
Engineering teams can turn the announcement into three checks. First, are any internal MCP servers exposed as public endpoints? Second, does the agent directly hold provider API keys, database secrets, or broad service-account credentials? Third, can logs connect the user, agent identity, model request, MCP invocation, and downstream system action? If those pieces live in separate systems, an incident starts with route reconstruction before anyone can answer what the model did.
NetFoundry's launch does not solve every agent-security problem. An agent can still call the wrong approved tool. An approved MCP server can still contain a business-logic flaw. Prompt injection can still cause damage within an allowed tool scope. A gateway is the control plane for reachability, identity, routing, and observability. Tool semantics, approval workflows, dry runs, rollback, and human review remain application-layer responsibilities.
Public community discussion around this exact NetFoundry release is still limited. I did not find a meaningful Hacker News or GeekNews thread devoted to the announcement. GeekNews discussions in early June were instead focused on AI IPOs and the agent economy, which shows broader interest in agent infrastructure and governance without direct debate about this product. That absence is itself useful context: MCP security is still often hidden behind developer convenience until an agent begins modifying real internal systems.
The practical reading is simple. An MCP server is not merely an LLM plugin. It is a programmable door into internal systems. An LLM gateway is not merely a model selector. It decides which requests leave for which provider and model, under which budget and policy constraints. NetFoundry's release tries to put both doors inside an identity-bound fabric. Teams preparing an AI-agent rollout should draw the agent's reachable network paths and tool registry before they spend another week comparing model benchmark scores.