Short answer: EDR watches processes, files, memory and network activity on endpoints, so it catches malware and hands-on-keyboard attackers. AI agent misuse usually looks like an authorized application making legitimate API and tool calls with valid credentials, often in the cloud, triggered by instructions hidden in ordinary content. EDR stays essential, but agents need their own controls on prompts, outputs, tool calls and identities.
- Keep EDR for the endpoints and servers that agents run on.
- Add an LLM/agent guardrail that inspects input and output for prompt injection and data leakage.
- Authorize every tool call with least privilege and a dedicated agent identity.
- Log prompts, tool calls and results into your SIEM and have someone monitor them.
- Require human approval for high-impact actions.
Last updated: November 2026
What does EDR actually see?
EDR sees operating-system behavior on a host: which process started, what it loaded, which files and registry keys it touched, and where it connected.
Endpoint detection and response (EDR) tools place a sensor on laptops and servers and collect telemetry such as process creation and parent-child chains, command lines, file writes, script execution, memory injection, credential access, and outbound connections. Detection logic then looks for patterns associated with malware and intrusion: an Office document spawning a shell, a known-bad hash, ransomware-style mass encryption, credential dumping, or lateral movement tools.
This works because classic attacks need to run something unusual on a machine. For how EDR relates to XDR and managed services, see EDR vs XDR vs MDR.
What does an AI agent actually do?
An AI agent reads content, asks a language model what to do next, and then calls tools and APIs on behalf of a user or a service account.
A typical agent loop looks like this: it receives a task, pulls context (emails, tickets, documents, web pages, retrieval results), sends that context to an LLM, and the model returns either an answer or a request to call a tool. Tools might be a database query, a file read, a ticket update, a code commit, a payment API or an email send. Increasingly, those tools are exposed through the Model Context Protocol (MCP), which gives agents a standard way to discover and invoke tools on MCP servers.
Nothing in that loop requires dropping a binary or running an odd command line.
Why doesn't EDR detect AI agent misuse?
EDR misses agent misuse because the harmful step is a legitimate action by an authorized process, decided by text the endpoint never interprets.
1. The actions are legitimate API and tool calls
When a hijacked agent exports a customer table or forwards a mailbox, it uses the same HTTPS calls and the same credentials it uses every day. From the host's point of view, an approved process made an approved TLS connection to an approved SaaS endpoint. There is no malicious process tree to flag. OWASP describes this risk as LLM06:2025 Excessive Agency: damage caused by an LLM-driven system that has too much functionality, too many permissions or too much autonomy.
2. Prompt injection lives in content, not binaries
Prompt injection (OWASP LLM01:2025) is an instruction hidden in data the model reads: a sentence in an email, a comment in a web page, white text in a PDF, a field in a ticket. To EDR this is just a document being opened or text being fetched. It is not executable, has no malicious hash, and only becomes "code" inside the model's reasoning. We cover the indirect variant in detail in Indirect Prompt Injection Attack Scenarios and Defense Strategies.
3. Cloud and SaaS agents never touch your endpoint
Many agents run inside a SaaS platform, a hosted agent service or a serverless function. The model call, the tool call and the data movement all happen between cloud services. If there is no sensor on the machine doing the work, or no machine you control at all, endpoint telemetry has nothing to record.
4. MCP and tool calls are opaque at the OS layer
On a developer laptop, a local MCP server is just another process exchanging JSON over stdio or HTTP. EDR may see the process start, but it does not parse which tool was called, with which arguments, or why the model chose it. The MCP project's own security best practices discuss risks such as confused-deputy authorization flows, token passthrough, over-broad scopes and malicious local server startup commands. EDR can help with the last one, because a malicious startup command is ordinary execution. The others are authorization problems, which is not what EDR is built to judge.
5. Agents act as non-human identities
Agents authenticate with API keys, OAuth tokens and service accounts. Misuse shows up as an identity doing something unusual: reading far more records than normal, calling a tool it never used before, or acting outside business hours. That signal lives in identity provider logs, SaaS audit logs and the agent's own tool-call log, not in endpoint process telemetry.
EDR vs AI agent security: comparison table
EDR protects the host; AI agent security protects the decisions and actions the agent takes; the two overlap where agents run on hosts you manage.
| Dimension | EDR | AI agent security | Where they overlap |
|---|---|---|---|
| Primary question | Is something malicious running on this host? | Is this agent being manipulated or doing more than it should? | Did an agent cause suspicious host activity? |
| Main telemetry | Processes, files, registry, memory, network connections | Prompts, model outputs, tool calls and arguments, agent identity, approvals | Agent runtime processes and their child processes |
| Typical threats | Malware, ransomware, credential dumping, lateral movement | Prompt injection, excessive agency, sensitive data in output, tool misuse | Agent that runs shell commands or code on a host |
| Where it works | Managed laptops and servers with a sensor | Between the app and the LLM, and between the agent and its tools (cloud or on-prem) | Self-hosted agents and local MCP servers |
| Response actions | Isolate host, kill process, quarantine file | Block or rewrite prompt, mask data, deny tool call, ask a human, revoke token | Kill a runaway agent process; contain a host the agent compromised |
| Blind spot | Legitimate API calls driven by malicious text | Malware and exploits on the host itself | Covered only when both are deployed and correlated |
Which controls cover the gap?
The gap is covered by controls that sit on the agent's inputs, outputs, tools and identity, plus monitoring that watches all of them together.
| Control | What it stops or reveals | Maps to |
|---|---|---|
| LLM/agent guardrail on input and output | Prompt injection attempts, jailbreaks, personal data or secrets leaving in responses | OWASP LLM01 Prompt Injection |
| Tool-call authorization and least privilege | Agent calling tools or scopes it does not need; write access for read tasks | OWASP LLM06 Excessive Agency; MCP scope minimization |
| Dedicated agent identity | Lets you see which agent did what, revoke one agent without breaking others | Non-human identity governance |
| Tool-call logging into SIEM | Unusual tools, volumes, destinations or timing; evidence for investigation | Detection and incident response |
| Human approval for high-impact actions | Sends, deletes, payments, permission changes executed without review | OWASP LLM06 human-in-the-loop; MCP tools guidance |
| Continuous monitoring (SOC/MDR) | Someone actually triages the alerts the controls above generate | Operations |
Guardrails on input and output
A guardrail sits between your application and the model. It inspects what goes in (user prompts and retrieved content) for injection patterns and policy violations, and what comes out for personal data, secrets or disallowed actions. KYRA AI Guardrail works this way as a proxy: it inspects LLM input and output, blocks prompt injection attempts and masks personal data before it leaves. No guardrail catches every injection, so treat it as one layer, not the whole answer. For open-source options, see our LLM guardrails guide.
Tool-call authorization and least privilege
OWASP's guidance for Excessive Agency is direct: give agents only the tools they need, scope each tool's permissions to the task, and enforce authorization in the downstream system rather than trusting the model to decide. A summarization agent should not hold a token that can delete records. Our guide to agentic AI security and least privilege walks through practical patterns, including for MCP servers.
Identity for agents
Give each agent its own service identity instead of reusing a human's session or a shared admin key. Where an agent acts for a user, run the action in that user's context with scoped OAuth tokens, as OWASP recommends.
Logging tool calls into the SIEM
Log every tool invocation with the agent identity, the user it acted for, the tool name, key arguments, the result status and whether a guardrail or approval step intervened. Send those logs to the same SIEM that receives EDR alerts and identity logs. This is the record EDR cannot produce.
Human approval
The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations. In practice, require explicit approval for anything that sends data externally, deletes, pays, or changes permissions; keep low-risk reads automatic so approvals do not become a reflex.
Monitoring and MDR
Logs only help if someone reviews them. A SOC or managed service can correlate a guardrail block, an unusual tool call and an EDR alert from the same host into one incident. KYRA MDR provides this kind of monitoring with 24/7 or business-hours coverage, depending on what an organization needs.
How do you combine EDR and AI agent security?
Run EDR on every host, add agent-layer controls around every agent, and correlate both in one SIEM so a single analyst sees the whole chain.
- Inventory agents. List each agent, where it runs (endpoint, server, SaaS), which model it uses, which tools and MCP servers it can reach, and which identity it uses.
- Keep EDR on agent hosts. Self-hosted agents, developer machines with coding agents and local MCP servers are still endpoints. EDR will catch an agent that is tricked into launching a malicious script or downloading a payload.
- Put a guardrail in the model path. Route LLM traffic through an inspection layer for prompt injection and data leakage.
- Restrict tools. Remove unused tools, narrow scopes, prefer read-only, and enforce authorization in the target system.
- Add approval gates for high-impact actions.
- Centralize logs. Send guardrail events, tool-call logs, identity logs and EDR alerts to the SIEM with a shared agent or session ID so they can be joined.
- Write detections and playbooks. Examples: an agent identity calling a tool for the first time, a spike in records read, a guardrail block followed by a successful tool call, or an agent process spawning a shell. Define who can revoke an agent's token and how fast.
- Test it. Use red-team exercises and threat frameworks such as MITRE ATLAS and the OWASP Agentic AI Threats and Mitigations guide to check that each layer fires.
Key takeaways
- EDR answers "is something malicious running on this host?" AI agent security answers "is this agent being manipulated or overstepping?" You need both.
- Agent misuse usually looks like legitimate API and tool calls by an authorized process, so endpoint telemetry has little to flag.
- Prompt injection is carried in content, and many agents run entirely in the cloud, outside endpoint visibility.
- Close the gap with guardrails on input and output, least-privilege tool authorization, dedicated agent identities, tool-call logging and human approval.
- Correlate guardrail, tool-call, identity and EDR events in one SIEM and make sure someone monitors them.
FAQ
Why doesn't EDR detect AI agents?
EDR is designed to detect malicious behavior at the operating-system level: suspicious processes, files, memory activity and connections. An AI agent that has been manipulated typically uses its normal process, normal credentials and normal API calls, and the manipulation itself is text inside a document or web page. Agents running in SaaS or cloud services also never touch an endpoint with a sensor. EDR can still see an agent's process, but not why it made a given tool call or whether that call was authorized for the task.
Do I still need EDR if I have an AI guardrail?
Yes. A guardrail inspects what goes to and comes from the model; it does not see malware, exploits, credential theft or lateral movement on your hosts. And an agent tricked into executing code on a host is exactly what EDR is good at catching.
Can EDR see MCP tool calls?
Generally not at the level that matters. EDR may record that an MCP server process started or opened a network connection, but it does not parse which tool was called, with which arguments, or whether the calling agent should have been allowed to make that call. That context has to come from logging in the agent framework, the MCP server or a gateway in front of it.
What is the biggest AI agent security risk?
OWASP ranks prompt injection as LLM01 in its 2025 Top 10 for LLM Applications, and for agents it combines dangerously with excessive agency (LLM06). An injected instruction is much more harmful when the agent holds broad permissions and can act without approval, so reducing tools and permissions is often the most effective first step.
How should AI agent activity be monitored?
Log prompts (with sensitive data masked), guardrail decisions, tool calls with arguments and results, and the identity used for each action, then send them to your SIEM alongside EDR and identity logs. Build detections for unusual tools, volumes and destinations, and assign a team, internal SOC or MDR provider to triage the alerts and revoke agent credentials when needed.
References
- OWASP GenAI Security Project, LLM01:2025 Prompt Injection
- OWASP GenAI Security Project, LLM06:2025 Excessive Agency
- OWASP GenAI Security Project, Top 10 for LLM Applications
- OWASP Agentic Security Initiative, Agentic AI – Threats and Mitigations (February 2025)
- MITRE, ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems
- Model Context Protocol, Security Best Practices
- Model Context Protocol, Tools specification
