Beware: Your Coding Agent Trips the Same EDR Rules Built to Catch Attackers
What Actually Fired
Sophos counted blocking-rule hits by unique machine, mapped to MITRE ATT&CK tactics. Two categories dominated:
| MITRE ATT&CK tactic | Share of blocks | Top rule | What triggered it |
|---|---|---|---|
| Credential Access (TA0006) | 56.2% | Creds_3b (DPAPI browser-credential decryption) | Claude Code's GStack /browse running PowerShell to unlock saved browser data |
| Execution (TA0002) | 28.8% | Exec_5a (bitsadmin download) | OpenAI Codex pivoting from certutil to bitsadmin to fetch the python.org installer |
| Defense Evasion (TA0005) | Prominent in silent rules | Exec_16a (PowerShell string-formatting) | Agents emitting PowerShell that matched an old obfuscation signature |
Within credential access, a single rule - Creds_3b - accounted for 42.6% of that bucket. It fires when a non-browser process uses the Windows Data Protection API (DPAPI) to decrypt stored browser credentials. That is the exact mechanism browser-credential infostealers use. It is also the exact mechanism a browser-automation skill uses to log into a site on your behalf. Same API call, same PowerShell chain, radically different intent - and the engine only sees the behavior.
Case 1 - Claude Code + GStack /browse (credential access)
GStack is a widely adopted agent skill pack. Its /browse skill connects the agent to a Chromium daemon for browser automation. Sophos traced the activity tree: bash โ browse.exe โ node.exe โ PowerShell, which then calls DPAPI to decrypt the browser's stored credentials. Creds_3b fired on that pattern, correctly.
In separate sessions, Claude Code went further. It spawned taskkill.exe to terminate running browser processes by PID, ran a script named decrypt_wp_pass.py that accessed credential stores, and executed cmdkey.exe /list to enumerate the Windows Credential Manager. Read that sequence again: kill the browser, decrypt its saved passwords, then dump the OS credential vault. On a threat-hunt call, that chain gets an analyst paged immediately. Here it was a coding agent doing routine work.
One detail matters most: these sessions ran with the --dangerously-skip-permissions flag set. That flag suppresses the agent's permission prompts and lets it act autonomously - and Anthropic's own documentation explicitly warns against it. From a behavioral-detection standpoint, an autonomous process harvesting credentials with no human in the loop is not a gray area.
Case 2 - OpenAI Codex pivoting through LOLBins (execution)
Codex needed to download a Python installer from python.org - a completely legitimate source. It reached for certutil.exe -urlcache -split -f, a classic living-off-the-land binary (LOLBin) download technique. Sophos's Lateral_1b rule blocked it. Codex tried several certutil variations; all blocked. Then it pivoted to bitsadmin.exe /transfer /download /priority normal against the same URL. Exec_5a blocked that too.
The download target was clean. The method was textbook attacker tradecraft. And the pivot-when-blocked behavior - try one technique, get stopped, immediately reach for another - is precisely what separates a live hands-on-keyboard adversary from a static malware script. Behavioral engines do not award points for clean sources. The agent reached for these tools unprompted and adapted when blocked, which is exactly the shape of behavior the rules exist to catch.
Case 3 - Cursor writing to the startup folder (persistence)
Cursor used a PowerShell script to write a VBScript file into C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\. The filename pointed to an app called "EZConvert." Persist_2a - one of the highest-signal persistence indicators in Windows detection - blocked the write before the file landed. Sophos could not confirm what the script did because the contents weren't captured. But writing to the startup folder outside the context of a trusted, high-reputation installer is exactly how malware survives reboots. The agent's intent was almost certainly mundane. The action was not.
Why "just allowlist claude.exe" is the wrong reflex
The obvious fix is to add claude.exe and cursor.exe to the EDR allowlist and move on. Sophos argues against this, and the argument holds up. Coding agents are constantly exposed to untrusted content during normal operation. They read repositories, fetch documentation, and parse files you hand them. A prompt-injection payload buried in a malicious repo or document can redirect the agent's behavior with no visible signal to you. The moment that happens, the same DPAPI decryption and LOLBin download that looked like a harmless false positive becomes a genuine attack - executed by the process you just allowlisted, inside the user's trusted session. The allowlist still passes it. You've disarmed your own detection at exactly the wrong layer.
This is not hypothetical. Sophos separately documented an attacker using AI agents (one running Claude Opus 4.5) to build and test malware against EDR products, and researchers have shown coding agents can be hijacked through poisoned inputs. Browser-credential calls, LOLBin downloads, and startup writes now originate from three sources that look identical on the wire: your legitimate developer's agent, an attacker's agent in a malware lab, and a hijacked agent inside your perimeter. The raw action tells you far less than it used to.
What to do instead
Sophos's recommendation - and the practical playbook for operators - is to tune, not disable.
Split the rule set by what it catches. Scope execution noise by parent process and path. For rules that fire on retries, odd PowerShell formatting, or download staging, key the detection to the agent's parent process (
claude.exe,cursor.exe, and their child processes) and to known workspace/temp directories. A recognized agent doing ordinary work in its own workspace should not alert on every keystroke.Hold the line on credential access. DPAPI browser-credential decryption and Credential Manager enumeration warrant continued blocks or heavy monitoring regardless of origin. An agent should not inherit blanket access to credential stores just because it runs under a trusted user account. If the agent is compromised, this is the exact behavior that matters - do not suppress it.
Kill
--dangerously-skip-permissionsat the policy layer. This is a convenience flag for personal machines, not for managed enterprise endpoints with active EDR. Anthropic documents how administrators can block it through managed settings. Do that. It is the single most effective change here. (See also how Claude Code's permission guards can silently fail - deny lists you assume are protecting you may be no-ops.)Audit which skills are active. GStack's
/browseskill was the biggest single driver of credential-access flags. Inventory the skill packs installed across your fleet and disable the ones that touch credential stores unless a workflow genuinely needs them.Isolate credential-touching work. If a workflow truly requires the agent to access credentials or stage downloads, run it in a containerized or sandboxed environment where the host credential stores are not reachable. This is the same isolation model covered in the Coding Agent Security Checklist 2026, and it is why sandbox credential leaks are such a dangerous class of bug - the isolation is the entire point.
Talk to your security team before deployment, not after. The fastest way to burn goodwill for an agent rollout is to have the SOC discover it via a flood of credential-access alerts. Get ahead of it: tell them what the agents do, which rules will fire, and what the scoping plan is.
The bigger picture
The endpoint community has been here before. When attackers stopped dropping files and went malware-free, defenders learned to watch commands, processes, and parent-child relationships instead. Browsers and remote shells went through the same evolution - benign tools whose behavior overlapped with attacker tradecraft, resolved by making the rules parent-process-aware. Coding agents are the next category to hit that wall.
The shift Sophos measured is still small in absolute numbers, and the report is explicit that it's a first-pass read, not a verdict. But the direction is unmistakable: as agent adoption climbs, more legitimate endpoints will generate credential-access, LOLBin, and persistence signatures as a matter of routine. The teams that plan for it - scope execution noise, hold the credential line, block the dangerous flags, and isolate sensitive work - will get the productivity without blinding their defenses. The ones that reflexively allowlist their way out of the alerts will hand an attacker a pre-approved process the day an agent gets hijacked.
The fact that an AI agent decrypted your browser credentials does not make it safe. It just makes it harder to tell who asked.
Comments
No comments yet. Start the discussion.