When AI coding agents look like attackers: reading behavioral EDR telemetry

Sophos reviewed a week of its own endpoint telemetry and found that AI coding agents such as Claude Code, Cursor, and OpenAI Codex were setting off detection rules written to catch human intruders. The agents were not malicious. They simply performed a lot of actions that, to a behavioral engine, are indistinguishable from an attack in progress.

Why a behavioral engine cannot tell the difference

Endpoint detection and response does not decide intent. It scores behavior. A rule fires when a sequence of observable actions matches a pattern that historically correlated with intrusion: a process decrypting stored browser passwords, a script writing itself into the startup folder, a system utility pulling a file down from the internet. These signals were chosen because human operators reliably produce them during hands-on-keyboard work. An AI coding agent, asked to set up a project or debug an environment, produces the same primitives for entirely ordinary reasons. The behavior overlaps; the intent does not. The engine only sees the behavior.

The rule was never wrong about the action. It was wrong about who was taking it, because that is the one thing behavioral telemetry cannot see. the false-positive problem restated

The behaviors that fire, mapped to tradecraft

Three categories in the Sophos data map cleanly onto techniques defenders already track. Each is a legitimate developer action and a well-worn adversary move at the same time.

Credential access

A rule keyed on the Windows Data Protection API generated a large share of the alerts. Agents called DPAPI functions to decrypt browser-stored credentials, which is exactly what an infostealer does after landing on a host. The system cannot tell a config-reading agent from a credential thief, because both ask the operating system the same question: unwrap this protected secret for me.

Living off the land

Codex tried to fetch a Python installer using certutil, a signed Windows utility. That call was blocked, so it fell back to bitsadmin. Both are living-off-the-land binaries, or LOLBins: trusted system tools that attackers abuse precisely because they are already present and rarely flagged. An agent reaching for them to download a dependency looks identical to a dropper staging a payload.

Persistence

Cursor tripped a persistence rule by using PowerShell to write a script into the startup folder so a task would run on every boot. Startup-folder persistence is one of the oldest entries in the attacker playbook. The mechanism is the same whether the goal is a convenience hook or a foothold that survives reboot.

Why this matters beyond noise

The immediate cost is alert fatigue. A behavioral rule that fires dozens of times a day on developer machines trains analysts to dismiss it, and a dismissed rule is a blind spot the day a real intruder produces the same signal. The second-order risk is subtler and already documented in adjacent research: an attacker who can drive an approved agent inherits its reputation. If claude.exe or cursor.exe becomes a trusted parent process that the pipeline learns to ignore, that trust is a surface. This is the same trust-boundary failure we traced when a local service trusted any caller on loopback, and the same confused-deputy shape as MCP tool poisoning, where a component with legitimate privileges is steered into misusing them.

How to tune it without going blind

The fix is not to silence the rule. It is to split it by what it is actually trying to catch, so agent noise can be scoped out while the underlying tradecraft stays covered. Useful axes to key on:

• Parent process lineage. Scope the rule so a DPAPI call whose ancestry traces to a known agent binary is handled differently from one spawned by a random process. Never blanket-allowlist the binary itself, because that hands an attacker the exact process to impersonate.
• Workspace and temp path. Downloads and script writes confined to a developer workspace or the agent's temp directory carry a different risk than the same actions landing in a system or startup location.
• Download reputation and destination. A bitsadmin fetch from python.org is not a fetch from a fresh, unknown host. Key the LOLBin rule on the reputation of the target, not just the tool.
• Egress and outbound scope. Constrain and log where agent processes are allowed to send data, so an unexpected destination still surfaces even when the local action is expected.

Reproducing it in a lab

You can study this safely on an isolated host running your own EDR or a rule engine you control. Point a coding agent at an ordinary setup task, such as bootstrapping a project that downloads a dependency and adds a launch hook, then read the telemetry. The tell is a cluster of high-signal detections whose parent process is the agent and whose targets are benign. Then tighten the rules along the axes above and confirm the developer flow goes quiet while a hand-run infostealer sequence still fires.

# split a credential-access rule so agent lineage is scoped, not silenced
AGENT_BINARIES = {"claude.exe", "cursor.exe", "codex.exe"}

def classify(event):
    # event: {name, parent_chain, target_path, dest_reputation}
    is_agent = any(p in AGENT_BINARIES for p in event.parent_chain)
    in_workspace = event.target_path.startswith(("C:\\dev\\", event.workspace))
    if event.name == "dpapi_decrypt":
        # agent + workspace = low, still logged; anything else = alert
        return "review" if (is_agent and in_workspace) else "alert"
    return "alert"

# never do this: a blanket allow hands attackers a process to wear
# if is_agent: return "allow"   # <-- do not

The transferable habit is the one we keep coming back to: an observable action is not the same as an intent, and any signal a defender learns to ignore is a signal an attacker will learn to produce. Start from the InnoCTF writeups index or read more about this project if you are building detection labs.