The security industry has spent the last eighteen months telling CISOs that the perimeter is dead. AI agents, the argument goes, operate inside your network by design — so the traditional perimeter is irrelevant. What you need instead is data-layer governance, model-layer guardrails, prompt-layer filtering, and runtime policy enforcement at the tool invocation layer.

All of that is true. None of it is a reason to abandon the network layer.

The perimeter isn’t dead. It’s just been misplaced — stretched to cover everything, enforced at every layer simultaneously, and in the process, made responsible for nothing in particular. The answer to “AI agents broke our perimeter model” isn’t to dissolve the perimeter entirely. It’s to define it correctly for what agents actually are.

The Wrong Question Everyone Is Asking

The debate about AI agent security has largely been framed as a question of *which* layer owns the problem. Data layer? Model layer? Identity layer? The answer security teams keep arriving at is: everything, everywhere, all at once.

That’s not a security architecture. That’s a wish list.

The “everywhere-layer” approach sounds comprehensive. In practice it produces the opposite: overlapping controls that nobody owns, audit trails that don’t connect, and governance frameworks that exist on paper while agents operate in production without any of it enforced. According to Gravitee’s State of AI Agent Security 2026 report, more than half of all deployed agents run without any security oversight or logging. That’s not a failure of the data layer or the model layer. It’s a failure of clarity about where accountability lives.

The network layer isn’t the only answer. But it is the right starting point — because it’s the one layer that every agent, regardless of framework, vendor, or task, must traverse to do anything that matters.

What the Network Layer Actually Sees

An AI agent that reasons brilliantly but can’t reach a database hasn’t done anything yet. An agent that crafts a perfect exfiltration payload but can’t reach an external endpoint hasn’t exfiltrated anything. Whatever happens at the model layer, the prompt layer, or the tool invocation layer, the network layer sees the result — and the network layer can stop it.

This is not a new insight. It’s the foundational logic of network segmentation, egress filtering, and zero trust network access — applied to a new class of identity. What’s new is that most organizations haven’t extended that logic to cover agents as first-class network citizens.

Agents are making network connections. They’re calling APIs. They’re reaching internal databases, external services, and in multi-agent architectures, each other. Every one of those connections is a policy enforcement point — and most organizations have no policy enforced there specifically for agents, because agents weren’t classified as identities that network policy needed to account for.

That’s the gap. Not that the network layer is insufficient, but that it hasn’t been configured to know agents exist.

Defining the Perimeter Correctly

The reason “the perimeter is dead” became conventional wisdom is that the old perimeter was defined geographically — inside the network is trusted, outside is not. Agents demolished that model not because perimeters don’t work, but because geographic perimeters were always the wrong abstraction.

The right abstraction is identity. A perimeter defined by identity — what this specific agent is, what it’s authorized to do, and what network resources it’s permitted to reach — is not dead. It’s exactly what zero trust network access was designed to enforce. The problem is that most ZTNA deployments were designed for human users on managed devices. Agents are neither.

An agent perimeter defined correctly looks like this: every agent has its own identity, authenticated at the network layer before it can reach any resource. Access is scoped to what that specific agent’s task requires — not the credentials it inherited, not the service account it was assigned, not the permissions that were convenient to provision once and reuse across every workflow. And every connection the agent makes is logged, attributable to that identity, and revocable the moment something looks wrong.

That’s not a new security paradigm. That’s zero trust applied to the right identity class — extended deliberately to cover non-human identities that most organizations’ network policies still don’t account for.

Where Model-Layer and Data-Layer Controls Fall Short

Runtime guardrails, prompt filtering, and data-layer governance all have real roles to play. The argument here isn’t that they don’t matter. It’s that they can’t substitute for network-layer enforcement — and understanding why clarifies what each layer is actually responsible for.

Model-layer controls govern what an agent is willing to do. They don’t govern what it’s able to reach. A well-aligned model that follows every instruction correctly can still exfiltrate data through a legitimate tool call to an endpoint it was never supposed to have access to in the first place. Prompt-layer filtering catches malicious instructions before they execute — but only the ones it recognizes. Prompt injection attacks by design look like legitimate input. And data-layer governance controls what an agent can do with the data it touches — but only after it’s already touched it.

None of these controls answer the question: should this agent be allowed to make this network connection at all?

That’s a network-layer question. And it’s the question that, answered correctly and enforced consistently, limits blast radius before any of the other layers even come into play.

The Practical Implication

Defining an AI agent perimeter at the network layer isn’t a call to ignore every other control. It’s a call to start there — because it’s the layer that creates the outer boundary within which everything else operates.

For security leaders, that means a few concrete things. First, agents need to be classified as network identities before they’re deployed — not after an incident makes the gap visible. Second, network policy for agents should be scoped to the minimum connectivity the task requires, the same way least-privilege access is scoped at the identity layer. An agent that processes internal documents doesn’t need egress access to arbitrary external endpoints. An agent that handles customer queries doesn’t need lateral access to financial systems.

Third — and this is where the “everywhere-layer” instinct tends to collapse in practice — someone has to own the network perimeter for agents specifically. Not the team that owns model selection. Not the team that deployed the orchestration framework. The network security team, with visibility into what agents are connecting to, enforcing policy on those connections, and with the ability to revoke access when an agent behaves outside its defined scope.

The perimeter isn’t everywhere. That’s what makes it a perimeter.