You already run EDR. Here is what it can't see about coding agents
Endpoint detection and response watches processes, files and connections. A coding agent's tool calls happen inside one process, so the event that matters never reaches the sensor. What EDR covers, where it stops, and what to add for coding agent endpoint security.
Your EDR sees the agent process, the shell it spawns and the connections it opens. It does not see the tool call that read ~/.aws/credentials, because that call never left the agent's own process, and it sees nothing at all when the agent runs in a cloud runner. Coding agent endpoint security is the layer that records those calls, decides them before they execute, and attributes them to a person and a policy. This post covers what EDR provides, the five events it has no record of, and the order to add the missing layer. It describes Microsoft Defender for Endpoint as documented in November 2026, the MCP 2025-06-18 specification, and Claude Code v2.1.
What EDR collects, in the vendor's own terms
Microsoft's EDR overview is a fair description of the category. The sensor "continuously collects behavioral cyber telemetry", listing "process information, network activities, deep optics into the kernel and memory manager, user login activities, registry and file system changes", retained for six months (EDR overview). Analysts query that telemetry through tables such as DeviceProcessEvents, DeviceNetworkEvents and DeviceFileEvents.
Microsoft also publishes the limit that matters: "Defender for Endpoint detection is not intended to be an auditing or logging solution that records every operation or activity that happens on a given endpoint. Our sensor has an internal throttling mechanism, so the high rate of repeat identical events don't flood the logs." That statement is why an EDR export is not an audit trail. None of this is a criticism: process and network detection is what stops malware and credential dumping. The unit of work for a coding agent, though, is a tool call, and that is not one of those events.
The five events EDR has no record of
| Event | What the sensor sees | What is missing |
|---|---|---|
| A tool call with arguments | Nothing, when the call stays in process | The tool name, the path or URL it touched, and the decision that allowed it |
| A local MCP call | Two existing processes and a pipe | Which server, which tool, which arguments, and whether the server was sanctioned |
| A model request | One TLS connection to the provider | The prompt, the tool definitions offered to the model, and the model version |
| A file read for a tool call | Sometimes a file event, often nothing at the default collection set | That the read was a tool call, what it returned, and where the content went next |
| A credential lease | A process reading a file or holding an environment variable | That the credential was short-lived, which policy issued it, and when it expired |
The last row is the one most teams miss. If the credential is a lease the platform can revoke, the request carries an identity the platform knows.
A tool call is not a process
Claude Code's PreToolUse hook receives the call as JSON on standard input, with tool_name and tool_input fields (hooks reference). A hook that logs the read of a credentials file is three lines:
#!/bin/bash
jq -c '{session: .session_id, tool: .tool_name, path: (.tool_input.file_path // .tool_input.command)}' \
>> /var/log/agent-tools.jsonl
The same action in an EDR console is a row in DeviceProcessEvents for claude with a command line, or nothing at all if the read was a library call inside that process. There is no column in that schema named tool_name, and no field that says the read was requested by a model, in a session, under a policy, as the second step of a task.
For Bash tool calls the gap narrows, because the agent does spawn a child process and the sensor sees it, but the record is still a command line with no link to the tool call that produced it. For Read, Grep, WebFetch and every MCP call, there is nothing to reconstruct.
The MCP stdio transport makes the second row concrete. The specification defines stdio as the client launching the server as a subprocess and exchanging JSON-RPC messages over standard input and output. The launch is one process event at session start; the thousands of calls after it are bytes on a pipe that belong to no process event and no connection.
Attribution is the second gap. An EDR row carries a device, a user account and a process, which answers which machine and which login, not which agent, session, tool, policy or model. A platform that resolves sessions through your identity provider puts a person and a role on every decision.
Response is containment, and containment is the wrong size
EDR response actions are built for an infected host. The manual actions in Defender for Endpoint Plan 1 are described as running an antivirus scan, isolating the device, stopping and quarantining a file, and adding an indicator to block or allow a file (EDR overview).
Every one of those is the right move against ransomware and the wrong move against a policy violation. Isolating a developer's laptop because an agent read a .env file stops their work and their builds, and the next sprint goes into an exception process. That is how a control becomes a ticket rather than a control.
What the agent case needs is a decision about the next call: deny it with a rule and a reason, hold the session for an approval, revoke the credential lease, and record all three. The action is narrow, explainable, and it does not take the machine away.
The agent that is not on an endpoint
GitHub's Copilot coding agent runs in a GitHub Actions environment rather than on the developer's machine (about the coding agent), and Cursor and Codex offer cloud agents on the same model. Nothing is enrolled on a laptop for those runs, so endpoint telemetry has no device to attach to. The vendor keeps a session record that lists the tools used, which helps for that run and is not one record across vendors.
That is not a reason to skip the endpoint layer, since most work still happens on machines people carry. It is a reason to want the same policy and record in both places.
What to add, in what order
- Inventory first. You cannot decide calls for agents and servers you cannot name. Collect the AI tooling, versions and MCP configuration on each endpoint, including stdio servers, and keep it current.
- A pre-call decision. Bind policy to the tool call, evaluated locally so it works offline and before the action rather than after it. Start in monitor mode and read the decisions before enforcing any of them.
- Sequence state. Add the rules that per-call policy cannot express, starting with read-then-egress.
- One record, in your SIEM. Emit the decision as OpenTelemetry with the session, identity, tool, target and rule, into the pipeline your SOC already watches.
Keep the EDR: it catches the credential dumper on the same laptop, and no agent platform replaces it.
How Alyria Beacon covers the gap
Alyria Beacon is a signed, user-space daemon for macOS, Linux and Windows, with no kernel driver and no hooking, so it runs beside your EDR rather than competing with it for the same interception points. It inventories the AI tooling and MCP configuration on each machine, including stdio servers that never touch the network, and observes process and config-level activity from user space to flag out-of-band agent activity.
On that inventory it evaluates Lyra policy locally on every MCP and model call, with no cloud round trip, so the decision exists before the action and continues to exist when the laptop is offline. Enforcement is opt-in and starts in monitor mode. Every decision is signed into one audit chain and emitted as OpenTelemetry through Spectra, to Alyria Cloud or straight into your Elastic or Kibana SIEM, where trajectory analysis joins a session's calls into something your detection rules can match.
The endpoint side is documented at Alyria Beacon, and the rollout guide covers the move from monitor mode to enforcement. For what each layer can see, the comparison guide sets endpoint, gateway and cloud runtime side by side. For the category definition, see what is agent detection and response.
Try it with Alyria
Install Alyria Beacon on a few developer machines and open the inventory. The MCP servers on that list are the ones your EDR has no event for, including stdio servers that never touch the network. Start free and read the Beacon docs.
Frequently asked questions
Can I detect agent tool calls from EDR telemetry alone?
Partly. You can infer Bash activity from child processes and see model provider connections. You cannot recover the tool name, arguments, MCP server, policy decision or session, because those exist only inside the agent process.
Does this mean EDR is not needed on developer machines? It means EDR is not sufficient for this workload. The operating system attacks are still real, and the sensor is the right tool for them.
Do I need a kernel driver for the agent layer? No. A kernel driver conflicts with the EDR already on the machine. A signed user-space daemon can observe process and config activity, read what the clients expose, and evaluate policy in the request path.
What about agents in CI or a cloud runtime? Endpoint telemetry does not follow them. The equivalent is a governed runtime, where every model and tool call is mediated because the agent executes inside it. That trade-off is in laptop or cloud.