AI Agent Network Security: Why Identity Alone Won't Contain a Compromised Agent

Last week at Zenith Live, Zscaler announced AI Broker, a new product that secures agent-to-agent and MCP traffic by governing which AI agents are allowed to access which systems. It's a real product addressing a real problem, and I'd encourage anyone running agentic workloads to take a look at it.

But it got me thinking about something I tell my kids constantly, usually right before one of them does the exact thing I told them not to do: knowing who's allowed in the building is not the same thing as knowing what happens once they're inside.

That distinction is the whole story of why AI agent network security and AI agent identity are two different problems, and why most of the industry right now is only solving one of them.

The New Hires Nobody Vetted

Here's the thing about AI agents that I don't think has fully landed yet. Every agent your organization deploys is, functionally, a new employee. It has credentials. It has access. It can read files, call APIs, move data, and talk to other systems on your behalf. The only difference is that this new hire started this morning, has no manager, never went through onboarding, and can clone itself a thousand times before lunch.

Zscaler's framing at Zenith Live leaned into exactly this idea. Jay Chaudhry described AI agents as a new digital workforce operating at machine speed, and argued that security models built around human identities aren't equipped to handle it. He's right about that. AI Broker, with its Agent Registry and fine-grained access policies, is essentially an HR system for this new workforce. It answers the question every security team should be asking: who is this agent, and what is it allowed to touch?

That's identity. That's access governance. And it's necessary.

It is also, by itself, not enough. And I think most people in our industry already know this, even if nobody's said it quite this directly yet.

Badges Don't Stop You From Wandering

Think about how security actually works in a building you've worked in. You get a badge. The badge tells the system who you are and which doors it should open for you. That's identity, and it's important. If your badge doesn't work, you're not getting past the lobby.

But once you're inside, with a valid badge, walking down a hallway? Nothing about the badge stops you from opening a door it wasn't meant to open, if that door happens to be unlocked. The badge system assumes you'll go where you're supposed to go. It doesn't physically prevent you from wandering into the server room because you got curious, or because someone propped a door open, or because you're not actually you anymore, you're an attacker who's been wearing your badge for the last six hours.

This is, almost exactly, what happened in March with the LiteLLM cascade. TeamPCP didn't forge anyone's identity. They rode in on a trusted, signed update to a piece of middleware that a third of cloud environments were already running. Every credential that got exfiltrated was a real credential, doing what it was authorized to do, from the system's point of view. Identity worked exactly as designed. And the breach still happened, because nothing was watching what that traffic was actually doing once it started moving.

That's the gap: not in identity systems, but in what identity systems can see and control once they've done their job. This is exactly the gap AI agent network security is meant to close.

Two Different Questions, Both Worth Asking

I want to be careful here, because this isn't a knock on what Zscaler announced. AI Broker answers a real and increasingly urgent question: which agents should be allowed to talk to which systems, tools, and data? That's the access governance layer, and as agent sprawl accelerates, organizations that don't have an answer to that question are going to be in trouble fast.

But there's a second question, and it's a network question, not an identity question: once an agent's traffic is moving, between services, across a VPC boundary, into a Kubernetes cluster, out toward the internet, what can it actually reach? This is the core question AI agent network security has to answer, and it's a different question than the one AI Broker answers.

That second question doesn't care what badge the agent is carrying. It cares about the path the traffic is taking and whether anything along that path is enforcing a policy about where it's allowed to go. An agent with a perfectly valid identity, behaving exactly as its access policy permits, can still be the thing that carries a compromise from one workload to every workload it's allowed to talk to. Identity governance doesn't shrink that blast radius. Network containment does.

This is the argument we've been making since we introduced the Cloud Native Security Fabric, and it's why we built it the way we did: enforcement that lives at the workload, on every path, regardless of whether anything has been detected yet. Not because identity doesn't matter. Because identity alone was never going to be the whole answer, for agents any more than it was for the credentials TeamPCP walked out the door with in March.

What Good AI Agent Network Security Actually Looks Like

If you're building out your AI security stack right now, here's the question I'd put in front of your team: when we say we're securing AI agents, are we describing who they are, or where they can go?

If the honest answer is "who they are," that's not wrong. It's just half the picture. The other half, the AI agent network security half, is the one that determines what a single compromised agent, or a single piece of trusted code that turns out not to deserve that trust, can actually do once it's moving through your environment.

Identity tells you who walked in. The network tells you how far they got. In the agentic era, you're going to need answers to both.

Learn more about what securing AI agents across clouds looks like.