A security analyst gets paged at 11pm: an endpoint on the engineering VLAN just decrypted a browser-stored credential using the Windows Data Protection API, then attempted a download through certutil, then pivoted to bitsadmin when the first attempt was blocked. Every one of those steps is textbook attacker behavior — credential access followed by a living-off-the-land download technique, exactly what the detection rule was written to catch. The analyst spins up an incident, isolates the machine, and starts pulling logs. What actually happened: a developer asked Claude Code to fix a failing integration test, and the agent, reasoning its way through the task with full local privileges, did what looked to it like the fastest path to the fix. Sophos published research in July 2026 after reviewing a week of its own endpoint data and finding this pattern repeatedly, across Claude Code, Cursor, and OpenAI Codex, none of it malicious, all of it indistinguishable from an attack to the rules watching for one.
The specific triggers are worth naming because they map directly onto MITRE ATT&CK categories security teams have spent years tuning for. A rule called Creds_3b, tied to Sophos's CookieGuard protections, fired repeatedly when agents used DPAPI calls to decrypt browser-stored credentials — a routine way for an agent to retrieve a saved session token, and also exactly how credential-stealing malware operates. When an agent's attempt to fetch a file via certutil.exe -urlcache -split -f got blocked by a rule labeled Lateral_1b, it pivoted to bitsadmin.exe /transfer, which a second rule, Exec_5a, blocked in turn — a LOLBin download fallback pattern that shows up in nearly every ransomware playbook published in the last five years. Separately, Cursor tripped a persistence rule by using PowerShell to drop a script into a Windows startup folder, so it would run again on reboot. Writing to a startup location outside a trusted installer is one of the most reliable persistence signals defenders have, and the agent had no way of knowing that doing it made it look like malware.
Why behavioral detection cannot tell the difference
Endpoint detection rules do not evaluate intent — they evaluate low-level system behavior: which API calls were made, which binaries were invoked, what got written where. An AI coding agent solving a legitimate engineering task and an attacker executing a post-compromise playbook can produce the identical sequence of system calls, because both are trying to accomplish similar low-level goals (read a credential, fetch a file, persist across reboot) with the same operating-system primitives. The rule has no visibility into who — or what — issued the command, only what the command did.
The Alert Fatigue Trap This Creates
This is not simply an inconvenience that resolves itself as SOC teams get used to it. It creates a genuine bind. If security teams leave detection rules as-is, every engineering team running AI coding agents at scale generates a steady stream of alerts that look identical to active compromise — and each one has to be triaged as if it might be real, because occasionally one will be. That is alert fatigue in its most dangerous form: not noise from a misconfigured tool, but noise from legitimate high-signal rules firing on legitimate activity, which erodes analyst trust in exactly the alerts they most need to take seriously. The alternative — broadly whitelisting the behaviors AI agents commonly trigger — is worse. Blanket exceptions for "credential decryption from this VLAN" or "PowerShell writes to startup folders from developer machines" reopen precisely the detection coverage those rules existed to provide, and an attacker who compromises a developer laptop now has a documented blind spot to hide inside.
A Realistic Scenario: The Incident That Wasn't
Consider a fintech company that rolled out Claude Code to its engineering team in Q2 2026, with no coordination between the platform team deploying it and the SOC team that owns endpoint detection. Three weeks in, an agent working on a legacy integration needed to authenticate against an internal tool using a session token already stored in the developer's browser — a reasonable shortcut to avoid re-prompting for credentials mid-task. It used DPAPI to decrypt the stored token, which tripped a credential-access rule tuned to catch exactly that technique. SOC treated it as a live incident: the laptop was isolated, the developer was locked out mid-sprint, and a senior responder spent six hours reconstructing what had happened before concluding there was no compromise. Multiply that by every engineer running agents daily, and the SOC either burns out triaging phantom incidents or starts taking AI-flagged alerts less seriously than it should — both bad outcomes, and both entirely avoidable with coordination that should have happened before rollout, not after the first false alarm.
What Actually Fixes This
The fix is not a smarter detection rule or a smarter agent — it is treating AI coding agents as a distinct, identifiable category of activity in your security architecture, the same way you would treat a service account or a CI/CD pipeline that also does unusual-looking things as part of its normal job:
- Run agents under dedicated, tagged identities — a distinct process owner or service account for agent-initiated actions, separate from the developer's own login, so telemetry can distinguish "this developer typed a command" from "an agent acted on this developer's behalf."
- Scope allowlists narrowly to the agent binary and expected behavior pattern, not broadly to the VLAN or the developer role — an exception for Claude Code's known DPAPI usage pattern is very different from disabling Creds_3b for an entire engineering subnet.
- Give agents ephemeral, sandboxed execution environments for tasks that involve credential access or file downloads, rather than running them directly on a developer's primary machine where a false positive triggers a full incident response.
- Build a separate triage path for agent-flagged alerts — a lighter-weight first pass that checks "was this an agent, and does it match a known-benign pattern" before a human responder spends hours on full incident reconstruction.
- Bring SecOps into the agent rollout plan before the first deployment, not after the first false alarm — detection engineering needs to know what agents are being deployed, what they are permitted to do, and what their normal behavior looks like, the same way it would need to know about any other new class of automated system touching the network.
None of this argues against deploying AI coding agents — the productivity case for them is well established and only getting stronger. It argues that rolling them out without telling the team that owns your detection rules is an operational gap, not a minor oversight, and it is one that shows up in the middle of the night as a false-positive incident rather than during a calm planning meeting where it is cheap to fix.
Where Wizeb Comes In
Wizeb deploys AI coding and automation agents with this coordination built into the rollout from day one — agents run under identifiable, scoped identities, execute in sandboxed environments rather than directly on developer hardware where possible, and every deployment includes a briefing to the client's security team on what the agent does, what it is permitted to touch, and what its normal behavior pattern looks like before it goes live. For clients who have already rolled out AI coding agents without that coordination, we run a targeted review: which agents are running under which identities, what SOC alerts they have already triggered, and what a properly scoped allowlist and triage path would look like without reopening real detection coverage.
The Sophos research is a preview of a coordination problem every organization deploying AI agents at scale will eventually hit, whether it surfaces as a 2am false alarm or a quieter mismatch between what your platform team ships and what your SOC is tuned to expect. Visit wizeb.com/services/ai-agents to get your current agent deployments reviewed against your own detection rules before the next false positive costs someone a night of sleep.
Get your AI agents reviewed against your own SOC rules
Wizeb audits how your deployed AI coding and automation agents behave against your existing endpoint detection rules, identifies which alerts are agent-driven false positives, and designs scoped identities and allowlists that close that gap without reopening real detection coverage. Visit wizeb.com/services/ai-agents to start the conversation.