TL;DR
- Why EDR doesn’t detect AI agents: EDR hunts for malicious software. AI agents aren’t malicious; they’re trusted tools using an employee’s own access.
- Agents look like the person who started them. They run as trusted processes, use that person’s credentials and reach company systems through MCP servers.
- In a real attack, every step looked routine. The s1ngularity malware got AI coding agents to hunt for secrets, and nothing looked like malware.
- New EDR discovery finds agents on managed devices. It doesn’t decide what they may do, or see agents in the cloud.
- Close the gap with a layer above the endpoint: one inventory, an identity per agent and policy checked before every call.
A supply chain advisory lands at 9 a.m. The security lead’s Endpoint Detection and Response (EDR) console is green: every laptop reporting, no alerts overnight. The telemetry for an affected developer machine shows a package install. A Node.js process. A command-line tool the developer uses every day. Some file reads. An upload to the developer’s own GitHub account.
Nothing on that list is malware. The developer’s tokens are gone anyway.
This guide explains why EDR doesn’t detect AI agents, even when an agent is doing the damage. EDR is working as designed. Agents sit outside that design, and closing the gap is now a core part of AI agent security.
Why doesn’t EDR detect AI agents?
EDR doesn’t detect AI agents because nothing an agent does looks like an attack. Agents run as trusted software, act with the employee’s own credentials and talk over normal HTTPS. EDR judges whether a process behaves maliciously. It can’t judge whether an agent’s action was intended or allowed.
Endpoint detection and response watches processes, files, registry changes and network connections on each device, and compares them with known attack behavior. It’s very good at catching malware, exploit chains, credential dumping and lateral movement. Its core question: is this activity malicious?
That question assumes an intruder. An AI agent isn’t one. It’s an employee’s tool, holding the employee’s keys, so EDR has nothing to flag, even when the agent is turned against you. One real attack shows how.
What EDR saw vs what the agent did: a real attack, step by step
On August 26, 2025, attackers published malicious versions of the Nx build package to npm. StepSecurity called it the first documented case of malware weaponizing AI CLI tools for reconnaissance. The install script didn’t bring its own spyware. It ran the AI coding agents already on each machine (Claude Code, Gemini CLI and Amazon Q) with their permission checks switched off, and told them to find secrets. GitGuardian counted 2,349 credentials harvested from 1,079 compromised developer systems.
The same attack, now known as s1ngularity, read two ways:
| Step | What the endpoint logged | What actually happened |
| 1 | npm install runs a postinstall script | A poisoned package starts its payload |
| 2 | A Node process launches an AI CLI | The malware hands its recon job to the developer’s own agent |
| 3 | The CLI starts with a “skip permissions” flag | Every safety prompt is switched off |
| 4 | The CLI reads files across the home folder | The agent hunts for keys, tokens and crypto wallets |
| 5 | A process calls the GitHub API with the developer’s token | Secrets leave in a new public repo under the developer’s own account |
No exploit, no unknown binary, no strange domain.
It isn’t a one-off. In February 2026, Check Point Research showed how a cloned repo’s config files could make Claude Code run commands and leak its API key before the user could confirm the trust prompt (since patched).
Why EDR can’t see AI agents: five blind spots
They run as trusted processes
Coding agents such as Claude Code, Cursor and GitHub Copilot run from the command line, as desktop apps or as IDE extensions, started by the user. That’s step 2: EDR sees the developer’s usual tools.
They act with the employee’s identity
An agent inherits whatever its user is signed in to: Git, cloud CLIs and SaaS tokens. Every action is logged as the human. Okta’s question says it all: “Was that the person or the agent?” In step 5, EDR saw a developer using their own GitHub token.
Their traffic looks like any approved SaaS app
Agents talk to model APIs over TLS, on domains your network already allows, so prompts and file contents travel inside trusted traffic. EDR sees an HTTPS connection to an approved vendor, not what was sent.
The risk is in intent, not behavior
EDR judges how a process behaves. It can’t judge whether a generated command matches what the user asked for, or what policy allows. Prompt injection makes it worse: instructions hidden in a web page or README can steer an agent using permissions it already has. Reading files across a home folder (step 4) is ordinary behavior. The intent behind it wasn’t. Seeing intent takes AI agent observability, not process telemetry.
MCP servers give agents tools EDR can’t parse
Model Context Protocol (MCP) servers connect agents to GitHub, Jira, databases and internal APIs. They can come from public registries, run with the user’s access and hold tokens to internal systems. That mix is why MCP security risks are hard to see from the endpoint. EDR can see an MCP server start or open a connection, but not which tool was called, with what arguments, or why.
Employees install all of this themselves, which is how shadow AI agents pile up unnoticed.
Can EDR detect AI coding agents now?
Partly. EDR vendors are getting better at detecting AI coding agents, which fixes the “we can’t see it” half on managed devices.
Microsoft made local AI agent discovery generally available in Defender in late October 2026, covering more than 50 supported agents and MCP servers on Windows and macOS. Okta added endpoint agent discovery through its CrowdStrike Falcon integration, in early access.
Two limits remain:
- Finding isn’t deciding. Discovery lists agents. It doesn’t decide what a well-behaved agent may touch.
- Scoring costs extra. Microsoft’s docs say Defender for Endpoint Plan 2 covers discovery, while risk levels need Microsoft 365 E7 or Agent 365.
For our security lead, discovery finds 40-odd coding agents and MCP servers across the developer fleet. Nobody can say who owns each one, which tokens it holds or what it’s allowed to touch.
The agents EDR will never see
Discovery also stops at the device, and a growing share of agents never touch one. Teams run agents in cloud accounts, Kubernetes clusters, CI pipelines and SaaS agent builders. No laptop means no EDR sensor.
So one more endpoint tool can’t close the gap on AI agent sprawl. The laptop agents are the ones the security lead found. The cloud agents are the ones nobody mentioned.
Endpoint discovery stops at the laptop. Your agents don’t. Learn how shadow agents spread across clouds, clusters and SaaS, and why their identities are the real exposure. Read the white paper:
EDR vs AI agent security: the questions each one answers
EDR asks whether something is malicious. AI agent security asks five questions about authority, and most of them sit above the endpoint.
| Question | Can EDR answer it? | What answers it |
| Which agents and MCP servers exist, and where? | Partly, on managed devices with newer agent discovery | One live inventory across laptops, clouds and SaaS |
| Whose identity is each agent acting under? | No, it sees the human user | A separate identity and owner for every agent |
| What is each agent allowed to reach? | No | Least-privilege scopes per agent and per tool |
| Is this action allowed right now? | No, it only judges behavior | Policy checked before the call goes through |
| Can we reconstruct what it did and why? | Partly, at the process level | Tool-call logs with inputs, outputs and the policy decision |
The OWASP Top 10 for Agentic Applications (December 2025) names the risks behind these questions, including agent goal hijack, tool misuse and exploitation, and identity and privilege abuse. None of them requires malware. It also cross-maps to the OWASP LLM Top 10. A Gartner survey found that 69% of organizations suspect or have evidence that employees use prohibited public GenAI. The old shadow IT playbook won’t catch it.
How to close the gap
Keep EDR, and add controls built around the agent rather than the device. An enterprise AI security platform covers that layer.
Build one inventory across laptops and cloud
Combine agent-based device discovery, OAuth grants, shadow AI discovery tools and read-only cloud scans. No single source sees everything.
Give every agent its own identity and owner
Stop agents borrowing the employee’s tokens, so logs can tell the person from the agent. That’s the basis of AI agent access control.
Scope credentials and keep humans on destructive actions
Use short-lived, per-tool tokens or gateway virtual keys, and keep production credentials off laptops. Keep approval prompts on for shell commands. The s1ngularity malware switched them off.
Treat MCP servers as third-party code
To govern MCP servers, pin versions, review updates and approve servers from a short list.
Check policy before each call, and log it
Put identity and policy in the request path, through an LLM gateway, so every call is checked before it reaches a model, tool or API, and logged in an audit trail. Calls that bypass the gateway skip all of it.
The first four shrink the blast radius. Only the last can say no before something happens, and it’s the hardest to build: it has to cover laptop and cloud agents, know each agent’s identity and sit in every call’s path.
Where Lyzr Opencontroller fits next to EDR
That missing layer is what Lyzr Opencontroller, a control plane for AI agents, is built to be. EDR keeps watching how software behaves on the device. Opencontroller decides what each agent is allowed to do, wherever it runs.
| The gap | How Opencontroller closes it |
| Which agents exist? | Read-only scans across clouds, clusters and developer laptops build one live inventory, including unregistered shadow agents |
| Whose identity is it acting under? | Each agent gets its own identity through the identity provider you already run, plus a named owner, instead of a shared key |
| What can it reach? | Tool and model policy limits each agent to the tools, MCP servers and models it’s authorized to use |
| Is this action allowed? | Identity, policy and budget are checked in the request path before a call reaches a model, tool or API |
| Can we reconstruct it? | Evidence for every call (trace, outcome, cost and policy verdict), built on open standards such as OpenTelemetry |
It works alongside EDR, not instead of it. An agent that could do whatever its API key allowed now does only what its identity and policy allow.
It runs inside your boundary. Deploy it in your VPC, on-prem or air-gapped. Credentials and telemetry never need to reach Lyzr, and read-only discovery changes nothing you run.
For our security lead, the 40-odd laptop agents and the cloud agents nobody had flagged land in one agent inventory, each with an owner. Agents that touch customer data get their own identities and route through Opencontroller, so a call outside an agent’s scope is refused before it lands, not found in a log a week later.
Book a demo to see what Opencontroller finds in your environment.
FAQ
AI agents run as trusted processes, use the employee’s credentials and talk over normal HTTPS, so nothing looks malicious. EDR judges how a process behaves, not whether an agent’s action matches intent or policy.
Newer EDR features can discover some coding agents and MCP servers on managed devices. Discovery shows an agent exists, not whether its actions were allowed, and it misses agents running in the cloud.
Not in a useful way. EDR sees an MCP server’s process and connections, not which tool was called, with what arguments, or whether prompt injection steered it.
EDR detects malicious activity on a device. AI agent security controls what agents may do wherever they run: their identity, their access and whether each action fits policy.
Yes. EDR still catches malware, exploits and lateral movement. Agent governance covers what EDR wasn’t built for.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
Got a use case in mind?
8 weeks from use case to agents running in production.
Platform, people and FDEs, all in. Bring your environment. We'll co-build and stay until it's live.
Talk to UsFree resource
101 AI Agents Use Cases
100+ production-ready AI agent use cases across Marketing, Sales, HR, Banking, Insurance, Operations and a lot more
Download now
