AI Agent Security vs NDR
Network detection and response infers what a machine is doing from the traffic it produces. That inference holds for conventional systems, whose communication patterns are a stable projection of fixed behavior. An agent's traffic is a lossy projection of its activity: identical flows to identical destinations can be routine or serious depending on context the wire does not carry, and a substantial share of agent activity produces no network traffic at all.
What does NDR actually cover for AI agents?
NDR covers the loud failures, and those are worth catching. Network detection and response watches east-west and north-south traffic for patterns that indicate compromise: lateral movement, command-and-control beaconing, connections to known-bad infrastructure, and volumetric anomalies in outbound data.
Applied to agents, that catches a genuinely useful class of event. An agent exfiltrating a large volume of data to an unfamiliar destination is exactly the shape NDR was built to detect, and it will detect it regardless of whether anyone has instrumented the agent or even knows the agent exists. That last property matters more than it sounds, because an unknown agent on the network still generates traffic, which makes NDR one of the few controls that offers any coverage at all over agents nobody has discovered.
It is also agent-agnostic by construction, with no sensor to deploy per harness, no integration per platform and no dependency on the agent cooperating. For an organization with no agent visibility whatsoever, network telemetry is a reasonable first place to look.
What can’t NDR see about an AI agent?
The limits follow from one property of the medium, which is that traffic is evidence of a communication rather than of the decision behind it, and that property has four consequences.
Most agent destinations are the destinations everything else uses. An agent’s outbound traffic goes to model provider APIs, GitHub, Slack, Salesforce, the organization’s own services – all over TLS, all to endpoints that carry legitimate enterprise traffic constantly. There is no unusual destination to flag and no unusual protocol to fingerprint. What distinguishes a reasonable API call from an unreasonable one is the content of the request and the reason behind it, neither of which survives inspection at the network layer in any environment that terminates TLS responsibly.
A large share of agent activity never crosses the wire. A coding agent reading and rewriting a local repository, an agent loading a skill definition from its own configuration, an agent reasoning its way toward a bad decision across several turns of context – none of this produces a packet. Skills in particular are a known blind spot for any traffic-based control, because they grant capability through configuration rather than through an outbound connection. A British bank customer had already deployed MCP gateways and surveyed its employees, and Geordie still surfaced significantly more tool connections than either had captured.
Traffic carries no identity and no intent. NDR sees a flow between two addresses, but it does not see which agent initiated it, which human’s delegated credentials it is acting under, what instruction prompted it, or what context the agent held at the time. Attributing a flow back to a specific agent requires something that already knows which agents exist and what they are configured to do, which is the problem rather than the solution.
The dangerous input looks like an ordinary fetch. When an agent retrieves a document, a web page, or a tool response containing injected instructions, the network sees an authorized request to a permitted resource returning content. The compromise happens inside the agent’s context window, several layers above anything a network sensor observes.
Why doesn’t traffic inspection work for AI agents?
Traffic inspection falls short for agents because the inference underneath it stops holding. NDR is built on the premise that a machine’s communication pattern is a reliable projection of its behavior – a database server talks to application servers in predictable ways, so deviation is signal, and that premise depends on the machine’s behavior being fixed.
An agent’s behavior is not fixed, and its traffic is a lossy projection of it. The same HTTPS request to the same approved API is appropriate or seriously harmful depending on what the agent was asked to do, what was in its context, and which data it had already gathered. Two agents producing byte-identical network patterns can represent entirely different risk. No improvement in inspection resolves this, because the discriminating information was never in the traffic.
This is the argument behind a line we use internally and mean literally, that agents aren’t traffic, and securing them as though they are inherits an assumption that no longer describes the system.
What is the difference between NDR and AI agent security?
| NDR | AI agent security | |
|---|---|---|
| Primary object | The traffic an agent produces | The agent as a system |
| Source of truth | Network flows, metadata, destinations and volumes | Agent configuration, context, tool definitions and execution path |
| Coverage of unknown agents | Partial – sees any agent that generates traffic | Full – discovers agents across cloud, code, endpoint and browser |
| Coverage of local activity | None – no traffic, no signal | Full – reads the agent’s own execution path |
| Core assumption | Communication pattern projects behavior | Behavior must be observed where it is decided |
| What it detects | Volumetric anomalies, known-bad destinations, lateral movement | Actions that are permitted and unremarkable but wrong for the context |
| Enforcement point | The network path – block the flow, quarantine the host | The agent’s own configuration and execution path |
| Enforcement precision | Allow or deny at a boundary | Context-specific, per agent, per department, per use case |
The third and fourth rows together explain why NDR is a reasonable floor and a poor ceiling, since it covers something of everything that talks and nothing of anything that doesn’t.
Is NDR the same argument as MCP gateways?
Structurally it is the same architecture one layer down, and recognizing that is useful during an evaluation. Both inspect agent communications from outside the agent and inherit the boundary they sit on, and in both the component doing the inspecting is usually the component doing the enforcing, which locks coverage and control to the same line.
The practical difference is resolution and scope. An MCP gateway understands the protocol it proxies, so it can reason about individual tool calls, but it only sees one tool type. NDR understands no application protocol in particular, so its reasoning is coarser, but it sees every flow, and neither of them sees the agent.
The interception-equals-enforcement coupling has the same consequence in both cases, limiting enforcement to what the boundary can do, which is allow or deny. That produces a fail-open or fail-close decision with no ability to distinguish a finance agent legitimately handling financial data from a marketing agent that should not be. At the volumes enterprises are now running – one customer applies inline controls across tens to hundreds of thousands of agents daily – the operational cost of getting that binary wrong is substantial. A hedge fund customer told us plainly that downtime from failed controls could cost more than a security incident.
Separating interception from enforcement is what changes this. Several interception mechanisms across cloud, code, endpoint and browser can feed a single enforcement layer operating through the agent’s own execution path rather than at a network edge, which decouples how much you can see from how precisely you can act.
Where does NDR sit alongside agent security?
NDR sits underneath agent security, as a floor rather than a substitute. NDR remains the right control for network-borne threats, and an agent that has been compromised into behaving like conventional malware will still be caught by conventional means – that is a real outcome and no reason to turn anything off.
It cannot be the agent control, though, because the risks specific to agents are the ones that look entirely ordinary on the wire: an agent using credentials it legitimately holds, reading a repository it is legitimately permitted to read, calling an API every other system in the estate also calls. Detection built on anomaly in communication pattern passes all of these through, because none of them is anomalous.
The productive arrangement is to treat network telemetry as one input into an agent-aware picture rather than as a detection layer standing on its own. A flow becomes meaningful once you can say which agent produced it, what that agent was configured to do, and whether this was within its remit – and those three facts come from somewhere other than the network.
How do you tell whether your network coverage is enough?
Each of these four questions can be answered from telemetry you already hold.
- Can you attribute a flow to a specific agent? That means attributing it to the agent, its owner, and the task it was performing, rather than to a host or a service account. If attribution stops at an IP address, every subsequent finding arrives without an addressee.
- What share of your agents’ work is local? Work such as coding agents operating on a checked-out repository, agents reading local files, and agents reasoning across several turns before acting is entirely invisible to network telemetry.
- Would a permitted, unremarkable action register? Consider an authorized credential, an approved destination and a normal volume, with the wrong reason behind them. If detection depends on something looking unusual on the wire, this class passes through cleanly.
- Can you act on a finding without blocking the flow? If the only available response is to cut the connection or quarantine the host, you have detection without proportionate control.
Common questions
Can NDR detect AI agent data exfiltration?
NDR reliably detects the volumetric and unfamiliar-destination cases. What it misses is exfiltration that resembles legitimate work – an agent moving data to a sanctioned SaaS platform it has permission to write to, at a volume consistent with normal operation, for a reason nobody authorized. That path is a permitted route used for an unintended purpose, which is precisely the shape agent data risk tends to take.
Does encryption stop NDR from working on agent traffic?
It constrains it to metadata: destinations, volumes, timing and flow shape. For conventional threat detection that metadata is often sufficient, because the suspicious part is usually where the traffic is going, whereas for agents it is usually insufficient, because the destination is almost always somewhere the organization already approved and the discriminating detail is in the payload and the context behind it.
Isn't agent security just NDR with better protocol parsing?
No, because better parsing improves what you can extract from traffic that exists but does nothing for activity that generates no traffic, and it does not supply the agent's configuration, its instruction, or the context it held when it acted. Those live in the agent rather than in some deeper layer of the packet, which is why the observability has to start there.
We have EDR and NDR. Isn't that both ends covered?
It covers both ends of a model that assumed systems sit on devices and talk over networks. An agent is a system whose configuration lives in one place, whose tools live in another, whose data access lives in a third, and whose behavior spans all of them – so the two controls each catch a projection, and the thing casting the shadow is not in either view. The companion entry on EDR makes the device-side half of this case.
