Firewall rules were designed for a world where connections came from known IP addresses, operated by humans, on predictable schedules. AI agents break every one of those assumptions.
For decades, network security operated on a simple premise: control what can reach what, and you control the risk. Firewall rules encoded that premise as policy — this subnet can reach that service, this IP range is permitted, everything else is denied. It worked well enough when the entities making connections were servers, workstations, and humans operating both.
But AI agents are none of those things. They’re autonomous software that makes decisions and takes actions without human instruction. An agent running an agentic workflow makes dozens of connections per session — to LLM APIs, to MCP servers, to internal databases, to external tools — and it does so dynamically, based on reasoning that no firewall rule anticipated. The IP address it calls from may be a shared cloud egress range (meaning dozens of unrelated workloads share the same outbound address). The destination may be an internal service that was never designed to receive autonomous requests. The firewall sees a valid connection from a permitted source address to a permitted destination address and allows it. It has no mechanism to ask whether the entity making that connection is actually authorized to make it.
That gap — between network-level permission and workload-level authorization — is where the AI agent security problem lives.
Why IAM Alone Doesn’t Close It
The natural response is to point at identity and access management: give agents service accounts, issue OAuth tokens, enforce scopes. That approach addresses authentication, but it leaves the network layer untouched. A stolen token — or a token issued to a compromised agent — still generates traffic that the firewall treats as legitimate. The credential validates the request; nothing validates the requestor.
More precisely: IAM tells you what an identity is permitted to do. It does not determine whether the entity presenting that identity is actually the workload you authorized.
A service account bound to a human-readable name and a rotating secret provides accountability after the fact. It does not provide machine identity assurance — no cryptographic proof the connection is coming from the workload you authorized.
This matters because AI agents are uniquely vulnerable to context manipulation. Prompt injections, poisoned tool results, malicious MCP servers — all of these can redirect an agent’s actions within a session that looks entirely legitimate from the network layer and the IAM layer simultaneously. The enforcement point those attacks bypass is the one neither firewall rules nor IAM policies actually occupy: the connection itself.
Identity-First Reachability Changes the Enforcement Model
The architectural shift that resolves this is moving the enforcement point from the network perimeter to the workload identity — and making that identity cryptographically bound to the connection at the moment it’s established.
In practice, this means the MCP server or internal tool the agent needs to reach is not reachable from the network at all. No open ports, no public hostname, no IP address to enumerate. Instead, the resource dials out through an authenticated tunnel, presenting a verifiable workload identity. The agent does the same. The connection forms only when both identities are validated against policy — before any data flows, before any tool call executes.
The firewall rule this replaces wasn’t wrong. It was just operating at the wrong layer. When identity is the enforcement point, the blast radius of a compromised agent is bounded by what that agent’s identity is authorized to reach — not by what happens to be reachable on the same network segment.
What This Looks Like for the Security Team
The operational impact runs in both directions. Security teams gain enforcement that travels with the workload rather than residing in perimeter infrastructure that agents were never designed to respect. They gain session-level visibility — which agent called which tool, when, with what parameters — rather than flow logs that show traffic without context. And they gain a policy model that scales with agent proliferation, delivering Zero Trust AI agent security regardless of where the agent runs or how the underlying network is structured.
Development and operations teams gain something equally valuable: a connectivity model that doesn’t require firewall rule changes or network reconfiguration every time a new agent or new tool integration goes into production. The security team stops being the bottleneck because the controls move to the layer the developers already think in — identity and authorization policy.
The firewall isn’t going away. But as AI agents become the dominant source of machine-to-machine traffic in the enterprise, the firewall alone is no longer a sufficient answer to the question of who — or what — is allowed to connect. Identity is.
Frequently Asked Questions
NetFoundry addresses a fundamental gap in how firewalls work: they verify network addresses, not workload identity. AI agents connect dynamically, reason autonomously, and can be manipulated mid-session through techniques like prompt injection, none of which a firewall rule can detect or prevent. We give every agent a cryptographically verified identity that must be validated before any connection forms, so the question shifts from “is this address permitted?” to “is this actually the workload we authorized?”
Identity-first reachability is NetFoundry’s approach to connectivity in which nothing is reachable by default — no open ports, no public hostnames, no exposed IP addresses. Instead, every workload (an AI agent, an MCP server, an LLM endpoint) dials out through an authenticated tunnel and presents a cryptographically verified identity. Connections only form when both sides are validated against policy. For AI agents specifically, this means that even if an agent is compromised or manipulated, it can only reach what its verified identity is explicitly authorized to access.
NetFoundry’s Identity-First Reachability™ gives AI agents, MCP servers, and LLMs cryptographically verifiable workload identities that enforce access at the connection layer — before the network sees any traffic.
