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?
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. No sensor to deploy per harness, no integration per platform, 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: traffic is evidence of a communication, not of a decision. 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. 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?
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. 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 catastrophic 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: 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. 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. Both inherit the boundary they sit on. 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. Neither sees the agent.
The consequence of the interception-equals-enforcement coupling is the same in both cases: enforcement is limited 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 put it to us plainly: 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?
Underneath it, 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.
What it cannot be is the agent control. 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?
Four questions, answerable from telemetry you already hold.
- Can you attribute a flow to a specific agent? Not to a host or a service account – to the agent, its owner, and the task it was performing. If attribution stops at an IP address, every subsequent finding arrives without an addressee.
- What share of your agents’ work is local? Coding agents operating on a checked-out repository, agents reading local files, agents reasoning across several turns before acting. That share is entirely invisible to network telemetry.
- Would a permitted, unremarkable action register? Authorized credential, approved destination, normal volume, wrong reason. 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?
The volumetric and unfamiliar-destination cases, yes, and reliably. 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. 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, and the distinction is worth being exact about. Better parsing improves what you can extract from traffic that exists. It 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 are not deeper layers of the packet. They live in the agent, 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.
