IT, OT, and defense networks have each built security architectures around the assumption of controlled boundaries. AI workloads are dismantling those assumptions — but the security architecture hasn’t moved.
Network isolation was always more conceptual than absolute. An air-gapped network, physically isolated from all external connections, with no wired or wireless path to outside systems, was long considered the strongest security guarantee available to high-risk environments. In OT and defense environments, the perfectly isolated network coexisted with USB drives, maintenance laptops, vendor remote access sessions, and data historians bridging operational networks to enterprise IT. In corporate IT environments, the trusted internal network coexisted with site-to-site VPNs, partner tunnels, and cloud workloads that made “inside the perimeter” a fiction sustained mostly by convention. Stuxnet demonstrated in 2010 that physical isolation doesn’t survive contact with human operational reality. The broader security community absorbed a version of that lesson — and then largely continued treating network boundaries as meaningful architectural guarantees anyway, because the alternative required admitting that the foundational assumption of enterprise network security needed to be rebuilt from scratch.
AI is forcing that conversation whether organizations are ready for it or not.
What AI Connectivity Requirements Actually Look Like Across the Enterprise
The AI use cases driving connectivity into previously bounded networks aren’t theoretical, and they aren’t confined to a single industry or network type.
In corporate IT environments, AI agents need access to internal databases, ERP systems, CRM platforms, and proprietary data stores that live behind network boundaries deliberately kept off the public internet. The agents themselves may run in cloud infrastructure, in a SaaS vendor’s tenant, or on infrastructure the enterprise doesn’t fully control — which means every tool call the agent makes crosses a boundary the security team designed to limit exactly that kind of traversal.
In OT environments, predictive maintenance agents monitor industrial control systems that need real-time sensor data. Autonomous process optimization tools need visibility into operational execution systems. Quality assurance agents need access to manufacturing data that lives on networks segmented from enterprise IT for regulatory and safety reasons — and that segmentation was the entire security guarantee.
In defense and high-assurance environments, decision support tools need to ingest data from sensors, communications systems, and operational databases that were deliberately kept off any network reachable from outside. The classification boundary or operational isolation that protected that data wasn’t an architectural preference — it was a hard requirement.
Each use case creates identical pressure: the AI workload needs access to data that the network boundary was specifically designed to protect. Teams deploying these workloads face the same three options regardless of which network type they’re operating in. They can deny the connectivity, which kills the use case. They can create an exception — a firewall rule, a VPN tunnel, a data diode that turns out to be less unidirectional than advertised — which defeats the isolation guarantee. Or they can find an architecture that provides exactly the access the AI workload needs without creating the network-level exposure the boundary was meant to prevent.
Most organizations, under schedule pressure with a working VPN already available, choose option two. The documentation still says the boundary is intact. The network no longer is.
Why Adding Controls to the Existing Perimeter Doesn’t Solve This
The instinct across IT, OT, and defense environments is to manage new connectivity requirements by layering controls onto the existing boundary — tighter firewall rules, more granular VPN segmentation, additional monitoring on the connection that now crosses the perimeter. This approach carries a structural problem that no amount of additional tuning resolves: it extends a perimeter model into an environment where the perimeter was the entire security guarantee. Effective defense requires treating every AI agent as a non-human identity subject to Zero Trust verification, not as a trusted node that inherited access by crossing a boundary.
A firewall rule that permits an AI agent to reach a specific internal resource also creates a network path that an attacker who compromises that agent can traverse. The rule doesn’t know the difference between the authorized agent and an adversary operating through stolen credentials or a manipulated session. The monitoring that flags anomalous behavior does so after the connection is established and traffic is already flowing. The segmentation that limits lateral movement stops at the network boundary — not at the workload identity, not at the session, and not at the specific tool call the agent was actually authorized to make.
The perimeter controls aren’t misconfigured. They’re operating exactly as designed — at the network layer, where the threat that matters in agentic AI environments doesn’t live. Zero Trust AI agent security operates at the identity and authorization layer, below what perimeter controls can see or enforce.
Isolation Without Disconnection
The architecture that resolves this across all three network types is the same: Identity-First Reachability™, where the resource the AI agent needs to reach is not reachable from the network at all, and connectivity forms only when both the agent and the resource present cryptographically verifiable workload identities validated against policy.
This is machine-to-machine Zero Trust in practice. The internal database, the OT sensor array, the defense operational system — none of them expose an inbound port, a public hostname, or a network address that an attacker can enumerate. The AI agent doesn’t receive network access to a segment; it receives authorized access to a specific resource, for a specific session, bounded by the identity policy governing that agent’s role. The blast radius of a compromised agent is exactly what that agent was permitted to reach — nothing adjacent, nothing lateral, nothing the underlying network path would otherwise make available.
This is what network isolation was always trying to accomplish: the resource is unreachable unless you are specifically and verifiably authorized to reach it. Identity-First Reachability (sometimes called identity-first connectivity) achieves that guarantee in an environment where AI workloads require real connectivity — not theoretical isolation that exceptions have already compromised.
The Forcing Function Organizations Have Needed
Security teams across IT, OT, and defense have known for years that their network boundaries were eroding. AI workloads haven’t created that problem — they’ve made it undeniable and immediate in a way that competing organizational priorities previously allowed to defer.
The teams that use this moment to rebuild connectivity architecture around workload identity rather than network perimeters will find that AI deployment accelerates alongside their security posture, not in conflict with it. The teams that respond by extending perimeter controls onto AI connectivity will eventually explain how a network documented as bounded became the path of least resistance for an adversary who simply compromised an agent.
Frequently Asked Questions
NetFoundry’s Identity-First Reachability™ is a connectivity architecture built on a simple principle: a resource doesn’t exist on the network until you’ve proven you’re specifically authorized to reach it. Think of it less like a locked door — which still exists and can be found — and more like a room that only appears when you have the right key. There are no inbound ports, no public hostname, and no network address an attacker can find and target. A VPN works differently: it grants access to a network segment, and once inside, a user or workload can move around that segment, probe adjacent systems, and potentially reach things they weren’t supposed to. Identity-First Reachability grants access to one specific resource, for one specific session, with nothing adjacent exposed. There’s no segment to explore and no lateral movement possible.
NetFoundry’s position — consistent with how Zero Trust frameworks define the problem — is that firewalls guard the wrong boundary for AI agent threats. A firewall works like a checkpoint at a building entrance: it decides who gets in, but once someone is inside, it can’t track exactly what they’re authorized to touch. An AI agent that clears the firewall inherits access to everything on that network segment — and if that agent is ever compromised, so does the attacker operating through it. Firewalls can’t verify whether the identity presenting credentials has been hijacked, or enforce which specific actions an agent was actually permitted to take. Zero Trust AI agent security closes that gap by making every action identity-verified and session-specific, not just the initial entry.
NetFoundry works with OT environments — the operational networks running manufacturing floors, power systems, and industrial equipment — where AI use cases like predictive maintenance and process optimization require agent access to systems that were deliberately kept separate from corporate IT for safety and regulatory reasons. That separation is the security guarantee. The risk isn’t the AI agent itself; it’s what connecting the agent requires. Most organizations end up punching a hole through that boundary — a firewall exception, a VPN tunnel, a workaround — and each hole degrades the isolation the OT network was built around. Our approach lets AI agents reach the specific operational data they need through outbound-only, identity-verified sessions, without opening inbound ports or touching the network boundary that OT security depends on.
NetFoundry uses workload identity — essentially a verified credential for software rather than a person — as the foundation for every connectivity decision we make. Just as an employee badge proves who a person is and what rooms they’re allowed to enter, a workload identity proves which AI agent is making a request and exactly what it’s authorized to access. This matters because AI agents operate autonomously, often around the clock, without a human approving each action. Traditional network security assumes a person logged in and authenticated at the start — AI agents don’t work that way. Without workload identity, a compromised agent inherits access to everything its network can reach. With it, the blast radius is limited to exactly what that specific agent was permitted to do.
NetFoundry’s Identity-First Reachability™ is built for environments where there’s no room to trade connectivity against security — you need both, fully intact. In defense and high-assurance environments, the systems AI tools need to reach were kept off externally reachable networks for a reason: not preference, but hard requirement. Our architecture honors that requirement. The protected system has no inbound ports, no findable address, and no network path that exists outside of an authorized, identity-verified session. The AI workload gets the access it needs; the protected system stays effectively invisible to everything else. We work with organizations operating under strict compliance and classification requirements to implement this without firewall changes or network reconfiguration.
Your AI workloads need connectivity. Your network boundaries still need to hold. NetFoundry’s Identity-First Reachability™ solves both, eliminating the inbound attack surface entirely with no firewall changes, no open ports, and no exceptions that become your next breach.
See Identity-First Reachability™ works in your environment →
