The Network Security Principle AI Deployment Gets Wrong
I spent a long time thinking about AI agent security the wrong way.
Every conversation in the field seemed to orbit the same questions. Prompt injection. Jailbreaks. Hallucinated outputs. How do you stop a model from saying something it shouldn't? That's a real question and worth serious attention. But it kept pulling focus away from something that turned out to matter just as much: not what an agent says, but where it reaches.
The moment I noticed the gap, I was debugging a production issue. One of the agents had made an outbound call to an endpoint that had no business being reachable from its execution environment. The call wasn't malicious. It was just there. An API the agent had encountered in its context window, available because nothing in the infrastructure prevented it. The request went out. The response came back. No alarm fired. From a network perspective, everything worked exactly as designed.
That's what unsettled me. Everything worked exactly as designed.
The problem with reasoning about AI security purely through content is that it treats the model as the perimeter. If the model produces safe outputs, you're safe. But modern AI agents don't just generate text. They call tools. They retrieve context from external sources. They write to storage and invoke downstream services. The surface area isn't the model's output window; it's every endpoint the agent can reach at runtime.
Network engineers figured this out for software systems decades ago. The insight wasn't "trust the software to make good decisions about what it accesses." It was "define what the software is allowed to access in the first place." Zone-based architectures came from that thinking. Instead of asking whether a particular request is safe, you ask whether the traffic pattern fits the relationship between two defined zones. You draw the zones, you define the permitted flows, and everything outside those flows gets dropped before the safety question even comes up.
That reframing is exactly what AI agent egress is missing.
Most AI agent deployments handle outbound traffic the same way early web development handled database queries: with good intentions and a hope that nothing goes wrong. The agent has a list of tools. The tools call APIs. There's usually some rate limiting. Maybe an allowlist of domains that's half-maintained and never pressure-tested.
What's missing is the structural guarantee.
An allowlist living in application code can be bypassed. A tool that fetches web content can be directed at internal infrastructure if the prompt is crafted to point it there. A model trained to be helpful will try to fulfill requests, and if a request subtly asks it to retrieve a document from a service it was never supposed to reach, nothing in the content layer stops it. The model doesn't know it's doing something wrong, because from its perspective it isn't. It's just following through on what the context asked.
Zone-based egress addresses this at the infrastructure layer, not the application layer. You define zones based on trust and sensitivity. The agent lives in its execution zone. Internal services live in a separate, protected zone. The open internet is its own zone. Traffic flows between zones follow explicit policy: an agent can call services in the approved-integrations zone, but it cannot initiate traffic toward internal infrastructure. That policy is enforced at the network level, not in the model's decision-making, not in the application code, not in a system prompt that instructs the agent to "only call approved endpoints." Policy in a prompt is behavioral. Zone enforcement is structural.
This distinction matters more than it sounds. Trust must be structural, not behavioral. You don't secure a system by teaching it to behave correctly. You secure it by constraining what it can do regardless of how it behaves.
When I started applying zone-based thinking to agent deployments, a few things shifted. The attack surface shrank. An agent that literally cannot reach internal infrastructure doesn't need perfect defenses against every variant of prompt injection targeting that class of threat. The zone boundary does the work before the threat even gets to be a threat. Debugging got cleaner too. When something unexpected happened with egress, the zone policy gave me an audit trail: what was attempted, what was permitted or denied, which zone the traffic originated from. I could answer the question quickly, rather than reconstructing it from scattered logs.
The biggest shift, though, was in how I reasoned about agent capabilities before deployment. Instead of asking "what can this agent do?", I started asking "what zones can this agent reach, and from which zones can it be reached?" That's a much more answerable question. It translates directly into infrastructure policy, and it can be audited without reading model weights or testing behavioral edge cases.
None of this is novel engineering. Zone-based architectures are standard network security practice. The idea of separating trust zones and enforcing directional flows is decades old. The reason it's not standard practice in AI deployment is that most attention is concentrated at the model layer. That's where the novelty lives. That's where the interesting research is happening. The infrastructure layer feels mundane by comparison.
But mundane is usually where the serious vulnerabilities are waiting.
If you're thinking about how to secure an AI agent, don't only ask what it can say. Ask what it can reach. Draw the zones. Define the permitted flows. Enforce them below the application layer. The security properties that actually hold under adversarial conditions come from structural constraints, not from prompts or training or hoped-for behaviors.
Zone by zone. That's how you build something you can actually trust.
Top comments (0)