Identity-First Reachability™
Contents
Discover why Identity-First Reachability™ is reshaping how enterprises secure and connect AI agents, MCP servers, LLMs, APIs, and OT/IoT infrastructure. As AI deployments multiply the reachable attack surface, traditional connectivity — VPNs, firewall rules, IP allowlists, and exposed APIs — falls short. Identity-First Reachability eliminates that surface entirely. Workloads receive sovereign cryptographic identities, all connections are initiated outbound, inbound ports stay closed, and authorization happens at the service level — not the network level.
What is Identity-First Reachability?
Identity-First Reachability™ is a connectivity and security model in which every workload — AI agent, MCP server, LLM endpoint, API, service, or device — receives its own cryptographic identity and is only reachable after that identity is authenticated and authorized against policy. Connections are initiated outbound from each endpoint, remain end-to-end encrypted, and are continuously re-evaluated against identity and policy for the lifetime of the session. From the network’s perspective, the protected workloads are invisible by default. Inbound ports remain closed, with no exceptions.
This is a fundamentally different posture than the one most enterprises operate today. In a traditional architecture, services are reachable on the network first and authenticated second. That ordering — reachable, then authenticated — is the structural source of most modern breaches. Identity-First Reachability inverts it: nothing is reachable until identity has been proven and policy has authorized the interaction.
What Traditional Approaches Get Wrong
Most enterprise connectivity still rests on a stack of controls designed for a different era: VPNs that grant broad network access once a user is in, firewalls and IP allowlists that gate traffic by address rather than identity, secrets and API keys distributed across teams and tools, and APIs intentionally exposed to “the right networks” so they can be consumed.
Each of these controls solves a narrow problem, but together they create the same structural condition: services are reachable on the network before any identity decision is made. An attacker who reaches the endpoint can probe it, exploit it, and pivot from it. A misconfigured rule, a leaked credential, or an unpatched CVE becomes a path to lateral movement because the reachability was there first.
This model also imposes operational drag. Every new AI agent, partner integration, or edge device triggers firewall changes, VPN provisioning, IP allowlist updates, and security reviews — the very work that slows enterprises down precisely when AI is forcing them to move faster.
What Problem Does Identity-First Reachability Solve?
The fundamental security problem of the AI era is reachability. Every API, AI agent, MCP server, and LLM endpoint that is exposed to the network is a potential entry point — and attackers are now able to exploit reachable endpoints faster than defenders can patch, restrict, or detect.
For AI systems, the reachability problem is compounded. AI agents discover and interact with tools dynamically. MCP servers and APIs are broadly reachable by design. Secrets and API keys proliferate across teams. Employees adopt unauthorized AI tools when official rollouts move too slowly. And every change to the underlying infrastructure — a firewall rule, a VPN configuration, a routing policy — slows AI deployment at exactly the moment the business is under the most pressure to execute.
Identity-First Reachability addresses this directly. By eliminating the reachable surface, it removes the attack vector. By using identity rather than network position to authorize access, it lets platform teams roll out agents, gateways, and services at software speed — without firewall changes, VPN provisioning, or new exposed endpoints.
Why is Identity-First Reachability Valuable?
The shift to Identity-First Reachability is being driven by two forces that have arrived simultaneously: a new dominant breach vector and an explosion of AI-driven attack surface.
#1
Vulnerability exploitation is the #1 breach vector.
68%
68% of employees are using unauthorized AI tools.
Vulnerability exploitation is now the #1 breach vector, surpassing phishing and credential abuse combined. Attackers go after what they can reach, and reachable endpoints are the consistent through-line across breaches.
Shadow AI compounds the exposure. Roughly 68% of employees are already using unauthorized AI tools they brought in themselves, because official rollouts moved too slowly. Each of those tools represents an unmanaged identity, an unmanaged endpoint, and unmanaged data flow.
Why is Identity-First Reachability the Right Solution?
Identity-First Reachability is the right solution because it removes the structural condition that makes modern breaches possible — reachability before authentication — and replaces it with a model that aligns with how AI, APIs, and distributed workloads actually communicate today.
It is built for outbound-initiated, service-to-service interaction, the dominant pattern in agentic AI and microservice architectures. It scales without firewall changes, VPN tunnels, or IP allowlists, so deployment speed matches the speed of the software teams deploying it. And it provides a unified identity and policy plane across cloud, on-prem, hybrid, and air-gapped environments, so the same model applies whether the workload is a Fortune 10 financial transaction or a sovereign agent calling a private LLM.
The result is a model that is faster to deploy than the incumbent stack and meaningfully more secure — because the attack surface that incumbents try to defend has been removed entirely.
The 5 Principles of Identity-First Reachability
Identity-First Reachability is implemented through five reinforcing principles. Together they define how a workload — whether an AI agent, an MCP server, an LLM endpoint, an API, or an OT device — is connected and protected.
Principle 1 — Cryptographic Identity for Every Workload
Every endpoint inside an Identity-First Reachability enclave is issued its own sovereign cryptographic identity. Agents, services, and devices do not share API keys, service accounts, or bearer secrets. Identity is bound to the workload itself, not to a network location or a shared credential, which means there is no secret to leak, rotate, or exfiltrate.
Principle 2 — Outbound-Only Connectivity
No workload listens for inbound connections on the network. All sessions are initiated outbound from each side of the conversation, meeting inside the enclave only after both identities have been authenticated and authorized. From the outside, the protected services are invisible. There are no ports to scan, no endpoints to enumerate, and no perimeter to breach.
Principle 3 — Service-Level Authorization
Authorization decisions happen at the service level, not the network level. A given identity is granted access to a specific service, tool, or endpoint — not to a network segment, subnet, or IP range. This eliminates the lateral movement that follows network-level access and shrinks the blast radius of any compromise to a single service.
Principle 4 — Continuous Authentication and Authorization Against Policy
Authentication and authorization is not a one-time gate at session start. Each session is continuously re-evaluated against current identity and policy state. If a policy changes, an identity is revoked, or context shifts mid-session, the change takes effect immediately. Access can be granted just-in-time and revoked in the same way, without waiting for a tunnel to drop or a credential to expire.
Principle 5 — End-to-End Encryption with Unified Observability
Every session is end-to-end encrypted by default, with no plaintext intermediary. Because every flow is tied to an identity rather than an IP address, observability is meaningful: platform teams can trace a request from an agent through an LLM call to a tool invocation in a single audit trail. Cost, behavior, policy violations, and risk roll up against identities — not addresses — so the data is usable for governance, billing, and incident response without correlation engineering.
How Does Identity-First Reachability Compare to Traditional Network Security Tools?
Identity-First Reachability vs. VPNs
Virtual Private Networks were designed to give remote users access to internal networks. Once a user authenticates, the VPN places them onto a network segment — and any service reachable on that segment becomes reachable to them. VPNs treat the network as the unit of access.
This model is poorly matched to AI workloads and service-to-service traffic. AI agents do not need a network — they need a specific tool, model, or API. Granting an agent VPN-level access to reach one MCP server gives it incidental reachability to every other service on that segment.
Identity-First Reachability replaces VPN-level network access with identity-bound, service-level access. There is no network segment, no tunnel, no broad allowlist. Each agent reaches exactly the services its identity is authorized to reach — and nothing else.
Identity-First Reachability vs. Firewalls & IP Allowlists
Firewalls and IP allowlists gate traffic by address. They assume that an attacker cannot easily appear at an allowed IP and that the set of “trusted” addresses is small and stable. Neither assumption holds in modern environments where workloads are ephemeral, addresses shift, and cloud egress IPs are shared across tenants.
Operationally, firewalls and allowlists also create drag. Every new AI agent, partner integration, or model endpoint becomes a change request, a review, and a deploy. The slower the firewall pipeline moves, the more shadow IT and shadow AI fill the gap.
Identity-First Reachability removes both problems. Address is no longer the unit of trust — identity is. New workloads come online by being issued an identity, not by punching a hole in a firewall. And because all connectivity is outbound, the firewall does not need to be reconfigured each time a new service is added.
Identity-First Reachability vs. SASE
Secure Access Service Edge (SASE) unifies networking and security at the cloud edge, primarily to secure user traffic to SaaS and internet destinations. It is a strong model for the workload it was designed for: human users browsing the web from anywhere.
It is a weaker fit for AI infrastructure. SASE architectures often struggle with AI applicability because servers aren’t directly connected to the SASE fabric and AI applications frequently use direct API calls that bypass traditional SASE control points. AI traffic is service-to-service, often east-west, often inside a customer’s cloud or data center — exactly the topology SASE was not built for.
Identity-First Reachability complements SASE rather than competing with it on the user-edge use case, but it is the right model for the service-to-service, agent-to-tool, and AI-infrastructure traffic that SASE cannot natively reach.
Identity-First Reachability vs. SD-WAN
SD-WAN optimizes WAN connectivity across branches, clouds, and data centers, typically using signature-based traffic steering and policy applied at network appliances. It excels at routing predictable traffic over the right link.
AI traffic is not predictable. Model selection, agent behavior, retrieval patterns, and tool calls produce highly variable flows that defeat signature-based steering and that bypass appliance-level control when calls go directly to API endpoints. SD-WAN does not provide workload identity, does not authorize at the service level, and does not eliminate reachable endpoints.
Identity-First Reachability operates a layer above the WAN. It does not replace the underlying transport — it makes the transport irrelevant to security. The same identity, policy, and authorization apply whether the traffic crosses MPLS, internet, or a private cloud interconnect.
Identity-First Reachability vs. Traditional ZTNA
Traditional Zero Trust Network Access focuses on user-to-application access, typically by brokering connections from authenticated users to private applications via a cloud-hosted proxy. It is an important step beyond VPNs for human workforce use cases.
But traditional ZTNA is still oriented around users and applications. It does not natively model machine-to-machine identity at the workload level, does not eliminate inbound listening on the protected services, and does not extend cleanly to AI agents, MCP servers, or OT/IoT devices that need to talk to each other at scale.
Identity-First Reachability extends the Zero Trust principle from the user edge to the workload itself. Every workload — human-driven or autonomous — is an identity. Every service is invisible until that identity is authorized. There is no inbound listener, no exposed application, and no broker that becomes a single point of compromise.
Identity-First Reachability vs. Secrets & API Key Management
Most AI deployments today rely on distributing API keys and service account credentials to the agents and services that need them. Secret managers help rotate and inject those credentials, but they do not eliminate the underlying problem: the secret is what authenticates, and any holder of the secret can act.
Leaked keys, over-permissioned service accounts, and shared bearer tokens remain the dominant pattern in AI agent compromise. Token theft does not require a network exploit — it just requires reaching a place where a secret is stored, logged, or transmitted.
Identity-First Reachability reduces the need for shared secrets and API keys, and eliminates the ability of attackers to reach them. Workloads authenticate with their cryptographic identity, not with a shared key. For access to the secure enclave, there is no API key to steal, leak, or exfiltrate. Per-identity policy, per-identity cost tracking, and per-identity audit replace the secret-based model with something both more secure and more accountable.
Does Identity-First Reachability Cover Cloud, On-Prem, Edge, and Air-Gapped Environments?
Most enterprises operate across cloud, on-prem, hybrid, edge, and — increasingly — air-gapped environments. AI workloads in particular tend to span all of them: a model hosted in one cloud, an agent running on-prem, a tool in a partner environment, and an inference workload that must stay inside an air-gapped enclave for regulatory or sovereignty reasons.
Identity-First Reachability is designed for this full landscape. The same identity, policy, and authorization model applies in every environment, and because connectivity is outbound-initiated and identity-bound, the underlying network topology does not need to change to add a new site, cloud, or air-gapped enclave. NetFoundry’s MCP and LLM Gateways are available across self-hosted and public LLMs and are supported in on-prem (including air-gapped), hybrid, and cloud deployments.
The result is a single connectivity and security model that follows the workload — not the network it happens to be running on.
Identity-First Reachability for AI: Zero Trust AI Enclaves
The fastest-growing application of Identity-First Reachability is securing agentic AI. AI agents, MCP servers, and LLM endpoints expand exactly the kind of reachable attack surface that attackers know how to exploit. NetFoundry’s Zero Trust AI Enclave applies Identity-First Reachability to that environment end-to-end.
Inside a Zero Trust AI Enclave, every AI agent, MCP server, and LLM endpoint receives its own cryptographic identity. Authorization happens at the service level. All connections are initiated outbound, remain end-to-end encrypted, and are continuously authenticated against identity and policy. From the network’s perspective, the AI infrastructure is invisible until identity and policy authorize the interaction. Inbound ports remain closed.
The MCP Gateway
The MCP Gateway delivers Zero Trust access to MCP servers from any MCP-compatible client without exposing those servers to the network. It supports multi-backend aggregation, tool namespacing, structural permission filtering, per-client session isolation, centralized multi-user management, role-based access control, and a full enterprise UI for platform teams. Denied tools are removed from the registry entirely — not checked at runtime, but gone from the schema before a client ever sees it.
The LLM Gateway
Governed, OpenAI-compatible access to LLM providers including OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, and private Ollama instances — without distributing API keys or opening ports to inference infrastructure. A three-layer semantic routing cascade (heuristics, embeddings, and an optional LLM classifier) intelligently routes requests to the right model for cost, latency, or data sensitivity. Built-in guardrails include PII detection, content safety filtering, topic controls, and prompt injection detection. Per-identity cost tracking and budget enforcement give platform teams and finance leaders full visibility into AI spend by team and project.
Together, the gateways share a unified identity model, correlated observability, and coordinated governance, enabling platform teams to trace a request from agent through LLM call to tool invocation in a single audit trail.
| AI Connectivity Challenge | Identity-First Reachability Outcome |
|---|---|
| Deployments slowed by network change requirements | Outbound-only connectivity removes the need for VPN, firewall, or routing changes — agents and gateways come online at software speed. |
| Expanded attack surface from exposed agents, MCP servers, and LLM endpoints | The AI Enclave is invisible from the outside. Every connection is authenticated before it is established, and every flow is governed by policy. |
| Poor visibility into AI activity across networks | All traffic is tied to a workload identity, not an IP address — making cost, behavior, and policy compliance directly observable per agent, model, and team. |
| Secret sprawl from distributed API keys | Workloads authenticate with cryptographic identity, eliminating shared secrets entirely. |
| Shadow AI from slow official rollouts | Platform teams can stand up governed, identity-first AI access in hours, removing the incentive for employees to bring in unauthorized tools. |
For organizations preparing for the next wave of AI infrastructure, the NetFoundry Accelerator Program offers early access to capabilities including the Agent2Agent (A2A) network — a zero-trust fabric for governed, identity-based agent-to-agent communication.
Why Should I Choose NetFoundry for Identity-First Reachability?
NetFoundry is the leader in Identity-First Reachability™ and was founded by the inventors and maintainers of OpenZiti, the world’s most widely used open source Zero Trust platform. That heritage matters: the model is proven at scale, the protocol is open, and the platform is the commercial-grade implementation of a battle-tested foundation.
NetFoundry secures billions of sessions for critical infrastructure across three continents and supports Fortune 10 companies across regulated industries including healthcare, financial services, and energy. The product set spans the full Identity-First Reachability stack: NetFoundry’s AI Enclave brings Identity-First Reachability to agentic AI infrastructure, with the MCP Gateway and LLM Gateway as the first commercial products purpose-built to apply this model to AI workloads. The same fabric extends to APIs, OT/IoT infrastructure, partner integrations, and human access — one identity-first model, one policy plane, one audit trail.
“NetFoundry enables Rhapsody to securely connect different types of sites and workloads, including AI agents, APIs and humans.”
Kevin Day, CTO, Rhapsody Health
“Vulnerability exploitation is the #1 breach vector today, surpassing phishing and credential abuse combined, because attackers go after what they can reach. With AI agents, MCP servers, and LLMs, enterprises are rapidly expanding exactly the kind of reachable attack surface that attackers know how to exploit. Identity-First Reachability™ eliminates that surface. Our commercial MCP and LLM Gateways make AI infrastructure invisible by default — so enterprises can deploy at software speed without handing attackers a larger target.”
Galeal Zino, CEO and Founder, NetFoundry
See Identity-First Reachability in Action
Talk to NetFoundry about securing your AI agents, MCP servers, LLMs, APIs, and OT/IoT infrastructure with no open inbound ports, no VPNs, and no firewall changes.
Frequently Asked Questions
NetFoundry’s Identity-First Reachability™ is a connectivity and security model in which every workload, whether AI agent, MCP server, LLM endpoint, API, service, or device, receives its own unique digital identity and is only reachable after that identity is verified and authorized by policy. Connections are initiated from inside the network outward, remain end-to-end encrypted, and are continuously re-evaluated for the lifetime of the session. From the outside, protected workloads are completely invisible — no open ports, no exposed endpoints, nothing for an attacker to find.
NetFoundry’s Identity-First Reachability replaces VPN-level network access with identity-bound, service-level access. A workload reaches only the specific service it’s authorized to reach, with no shared network segment in between. A VPN works by placing a user or workload onto a network segment, which means everything else reachable on that segment becomes reachable to them too, a much larger exposure than necessary. With Identity-First Reachability, there is no tunnel to compromise and no incidental access to exploit.
NetFoundry extends the Zero Trust principle beyond traditional ZTNA’s focus on user-to-application access, applying it to every workload, including AI agents, MCP servers, LLM endpoints, APIs, and OT/IoT devices, and ensuring no workload ever sits open on the network waiting for incoming connections. Traditional Zero Trust Network Access brokers connections from authenticated users to private applications via a cloud-hosted proxy, but doesn’t natively handle machine-to-machine traffic at the workload level or the autonomous, service-to-service patterns that AI infrastructure requires. With NetFoundry, there is no exposed application, no open entry point, and no broker that becomes a single point of failure.
NetFoundry’s Identity-First Reachability requires no firewall changes, VPN provisioning, or routing updates because all connections are initiated outward from each workload. New agents, gateways, or services come online without touching the underlying network infrastructure. Traditional connectivity models require every new endpoint to trigger a change request, a security review, and a multi-team deployment, which is exactly the drag that slows AI rollouts and pushes employees toward unauthorized tools. With NetFoundry, deployment speed matches the speed of the software teams doing the deploying, regardless of how many new workloads are being added.
NetFoundry’s Identity-First Reachability secures AI infrastructure by making it invisible; every AI agent, MCP server, and LLM endpoint receives its own unique digital identity and is unreachable from the network until that identity is verified and policy authorizes the interaction. This directly addresses the two compounding problems AI creates: a dramatically expanded attack surface from exposed endpoints and the operational friction of firewall changes and VPN provisioning that slows official AI rollouts and pushes employees toward unauthorized tools. The result is AI infrastructure that is both faster to deploy and harder to attack.
NetFoundry’s Identity-First Reachability applies the same identity, policy, and authorization model in every environment, cloud, on-prem, hybrid, and air-gapped alike, with no changes to the underlying network required to add a new site, cloud, or isolated enclave. NetFoundry’s MCP and LLM Gateways are available across self-hosted and public LLMs and are supported in on-prem (including air-gapped), hybrid, and cloud deployments. One connectivity and security model follows the workload, regardless of where it runs.
NetFoundry’s Identity-First Reachability authenticates workloads with a unique digital identity rather than shared passwords or API keys, removing the shared credential from the authentication process entirely, so there’s nothing to steal, leak, rotate, or accidentally expose. Most AI deployments today rely on distributing API keys and account credentials to the agents and services that need them. Secret managers help rotate and store those credentials, but the key itself remains the basis for authentication, meaning anyone who obtains it can act with full permissions. NetFoundry replaces that model with per-identity policy, per-identity cost tracking, and per-identity audit, which is both more secure and more operationally accountable.
NetFoundry’s Zero Trust AI Enclave is a purpose-built secure environment for AI workloads, in which every AI agent, MCP server, and LLM endpoint receives its own unique digital identity, all connections are outbound-only and end-to-end encrypted, and the entire enclave is invisible from the outside until identity and policy authorize an interaction. It addresses the specific exposure that agentic AI creates: AI agents discover and interact with tools dynamically, MCP servers and APIs are broadly reachable by design, and credentials proliferate across teams. Each of these conditions is eliminated inside the enclave. Platform teams can deploy and govern AI infrastructure at software speed, without firewall changes, exposed endpoints, or distributed API keys.
NetFoundry’s MCP Gateway provides secure, identity-verified access to MCP servers without exposing them to the network, with support for multiple backends, tool-level permission filtering, and isolated sessions per client, so each user or agent sees only the tools they’re authorized to use. NetFoundry’s LLM Gateway delivers governed access compatible with leading AI providers, including OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, and private Ollama instances — without distributing API keys or opening ports to inference infrastructure. Together they share a unified identity model and correlated observability, enabling platform teams to trace a request from agent through LLM call to tool invocation in a single audit trail.
NetFoundry’s LLM Gateway reduces AI token costs by up to 50% through intelligent routing that automatically sends each request to the right model based on cost, speed, and data sensitivity. Expensive frontier models handle only the requests that truly require them. Combined with per-identity budget controls, organizations gain full visibility into AI spend broken down by team and project, replacing the opaque, uncontrolled cost model that results from distributing API keys directly to agents and developers. Cost reduction and security enforcement are delivered through the same identity-first layer, with no separate tooling required.
NetFoundry secures billions of sessions for critical infrastructure across three continents, supporting Fortune 10 companies across regulated industries including healthcare, financial services, and energy. Customers adopt NetFoundry specifically to eliminate exposed attack surfaces across AI agents, APIs, OT/IoT devices, and partner integrations, all under a single identity and policy plane. NetFoundry is also the company behind OpenZiti, the world’s most widely used open source Zero Trust platform.
NetFoundry offers two paths to get started: get in touch to talk to the team directly about a Zero Trust AI Enclave deployment at or apply to the NetFoundry Accelerator Program for early access to upcoming capabilities including the Agent2Agent (A2A) network.
NetFoundry is the leading secure networking platform for distributed enterprises, built on Identity-First Reachability — a model where every workload receives its own unique digital identity, all connections are initiated outward, and inbound ports remain closed. Founded by the inventors and maintainers of OpenZiti, the world’s most widely used open source Zero Trust platform, NetFoundry secures billions of sessions for critical infrastructure across three continents and supports Fortune 10 companies in healthcare, financial services, and energy. Distributed enterprises adopt it specifically because adding new sites, agents, or services requires no firewall changes, no VPN provisioning, and no routing updates.
NetFoundry supports both on-premises (including air-gapped) and cloud workloads under a single identity and policy plane, applying the same unique digital identity, outbound-only connection model, and service-level access controls whether a workload runs in AWS, Azure, GCP, a private data center, or a regulated isolated environment. This eliminates the common pattern of stitching together separate tools per environment — one for cloud, one for VPN, one for OT — and removes the operational complexity of maintaining parallel policy models. NetFoundry’s AI Enclave, MCP Gateway, and LLM Gateway are all available across self-hosted and public LLMs and are supported in on-prem (including air-gapped), hybrid, and cloud deployments.
NetFoundry is the leading cloud-native Zero Trust networking platform, built on OpenZiti — the open source Zero Trust framework invented and maintained by NetFoundry and now the world’s most widely used implementation of the model. NetFoundry’s commercial platform applies Identity-First Reachability across cloud, on-prem, edge, and AI workloads with a single identity, policy, and observability plane, operating above the transport layer rather than relying on network-segment models like legacy VPNs or cloud-overlay tunnels. When evaluating any Zero Trust networking platform, the defining capability is whether it eliminates the exposed attack surface entirely — issuing each workload its own unique digital identity and closing inbound ports — or whether it still relies on tunnels, allowlists, and shared credentials.
NetFoundry automates Zero Trust overlay deployment and management through identity-based policy that is defined centrally and applied automatically across every environment. Because policies are tied to workload identity rather than IP address or network location, changes take effect instantly — access can be granted just-in-time or revoked in the same way — and new sites, services, agents, and gateways come online by being issued an identity rather than by provisioning tunnels or modifying firewalls. The underlying overlay protocol is OpenZiti, invented and maintained by NetFoundry, which provides the open programmable foundation; the NetFoundry platform adds the enterprise control plane, observability, and lifecycle automation on top.
NetFoundry is purpose-built for multicloud connectivity, replacing the traditional approach of stitching environments together with VPNs, network peering, and firewall rules with a single identity-bound fabric that follows the workload, not the network. Because all connections are outbound-initiated and access is granted at the individual service level, adding a new cloud, region, or partner requires no new tunnels or routing changes — making NetFoundry well-suited for deployments where identity, policy, and visibility must remain consistent across providers. AI workloads in particular benefit, as they typically span cloud, on-prem, edge, and air-gapped environments simultaneously.
NetFoundry is purpose-built for AI application traffic, giving every AI agent, MCP server, and LLM endpoint its own unique digital identity through its Zero Trust AI Enclave, with access granted at the individual service level rather than the network level. The MCP Gateway provides secure access to MCP servers without exposing them to the network, with support for multiple backends, tool-level permissions, and isolated sessions per client, while the LLM Gateway delivers governed, OpenAI-compatible access to providers including OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, and private Ollama instances with intelligent routing that can reduce AI token costs by up to 50%. As Gartner has noted, existing SASE architectures struggle with AI applicability because servers aren’t directly connected to the SASE fabric and AI applications frequently use direct API calls that bypass traditional control points — exactly the problem NetFoundry’s identity-first model solves.
NetFoundry is the fastest path to Zero Trust deployment for IoT and IT environments because it eliminates the steps that traditionally dominate rollout timelines — VPN provisioning, firewall rule changes, IP allowlists, and per-environment policy reconciliation. New IoT devices and IT workloads come online by being issued a unique digital identity rather than by opening inbound ports, and the same identity, policy, and visibility layer covers IoT, OT, IT, cloud, and AI workloads in a single fabric. Because no underlying network changes are required, teams can stand up governed, identity-first access without the long change-control cycles that slow traditional Zero Trust rollouts.
NetFoundry is purpose-built for mixed IT and OT environments, applying the same identity-first model across both under a single fabric with no open inbound ports, no VPNs, and no firewall changes required. OT and IoT infrastructure is explicitly supported alongside AI agents, MCP servers, LLMs, and APIs — which matters in OT specifically, where open ports and shared credentials create serious exposure on systems that often can’t be patched quickly. By issuing each device a unique digital identity and granting access only at the individual service level, NetFoundry removes OT systems from the exposed attack surface while maintaining a unified policy and audit model across both IT and OT.
NetFoundry solves the core reason enterprises struggle with Zero Trust networking: most platforms layer new abstractions on top of the same network-centric assumptions that created the problem — tunnels, IP allowlists, exposed application brokers, and per-environment policy models that each become a change request, a security review, and a multi-team deployment. This operational drag has real consequences: roughly 68% of employees admit to using unauthorized AI tools because official rollouts moved too slowly, expanding attack surface through unmanaged identities and unmanaged data flows. NetFoundry’s Identity-First Reachability avoids this entirely with a single identity-bound fabric — no tunnels to provision, no firewalls to reconfigure, no parallel policy models per environment — covering cloud, on-prem, edge, IoT, OT, and AI workloads.
NetFoundry eliminates the core source of multicloud connectivity complexity: the fact that each cloud provider has its own networking model, identity system, and policy language, forcing teams to stitch together environments with VPNs, network peering, allowlists, and per-cloud security rules into a brittle web of exceptions where the slowest provider’s change pipeline determines the whole organization’s deployment speed. NetFoundry’s Identity-First Reachability solves this by issuing every workload its own unique digital identity, initiating all connections outward, and granting access at the individual service level — making the underlying cloud infrastructure irrelevant to security. The result is a single policy and audit model that applies consistently across every environment, where adding a new cloud, region, or partner requires no new tunnels, no routing changes, and no policy reconciliation.
Get Started With Identity-First Reachability
Talk to NetFoundry about securing your AI agents, MCP servers, LLMs, APIs, and OT/IoT infrastructure with no open inbound ports, no VPNs, and no firewall changes.
