On 7 July 2026, Sophos X-Ops published research that should give every development team pause. After analysing a week of endpoint telemetry from its behavioural detection engine, Sophos found that AI coding agents — Claude Code, Cursor, and OpenAI Codex among them — are routinely triggering the same detection rules written to catch human attackers. The agents are not malicious. They simply do things that, to a behavioural engine, look indistinguishable from an intrusion.
For teams that have adopted AI coding assistants (and at this point, that is most teams), this creates an urgent operational problem: your security tools are now fighting your development tools, and if you do not manage the conflict deliberately, you will either drown in false positives or, worse, start ignoring alerts that matter.
TL;DR
- Sophos X-Ops research (July 2026) shows AI coding agents like Claude Code, Cursor, and Codex trigger endpoint detection rules for credential access and code execution — the same categories used to catch real attackers.
- Credential access alerts account for 56.2% of blocked activity, primarily from agents using Windows DPAPI to access browser-stored secrets during legitimate development tasks.
- Living-off-the-land binary (LOLBin) detections are triggered when agents use system tools like certutil.exe to download dependencies — a technique attackers also favour.
- The bigger risk is not false positives but alert fatigue: teams that suppress AI-triggered alerts may miss genuine attacks hiding in the same telemetry.
- Development teams need dedicated EDR policies for AI agent workstations, process-level allowlisting, and separate telemetry streams to maintain security visibility without blocking productivity.
What Sophos Actually Found
The Sophos research examined seven days of telemetry from their CIXA behavioural engine on Windows, counting unique machines rather than raw event volume to avoid skewing the data. The results paint a clear picture of where AI agents collide with security tooling.
Credential access dominated, accounting for 56.2 per cent of all blocked activity. A detection rule called Creds_3b, linked to Sophos’s CookieGuard protections, generated significant alert volume when AI agents invoked Windows Data Protection API (DPAPI) functions to decrypt browser-stored credentials. From the agent’s perspective, it might be reading a stored API token or accessing a development credential. From the endpoint’s perspective, it looks exactly like credential theft.
Execution came second at 28.8 per cent. This category covers agents spawning processes, running scripts, and executing code in ways that mirror attacker behaviour. When an AI agent iterates through multiple approaches to solve a problem — installing packages, running shell commands, modifying system configurations — it creates a telemetry pattern that behavioural engines have been trained to flag.
LOLBin abuse rounded out the findings. Sophos documented OpenAI Codex attempting to download a legitimate Python installer using certutil.exe, a Windows utility that attackers have abused for years to fetch malicious payloads. The agent was doing something entirely benign, but the method it chose is on every threat hunter’s watch list.
Why This Is Not Just a False Positive Problem
The instinctive reaction is to treat this as a tuning exercise: whitelist the AI agents, suppress the alerts, move on. That instinct is dangerous.
The real threat is not that your AI agent is getting blocked. It is that genuine attacks can hide in the noise your AI agent creates. If your security operations team learns to ignore credential access alerts from developer workstations because “that is just Claude Code doing its thing,” you have created a blind spot that an actual attacker will exploit.
This is not hypothetical. Sophos’s own research documented a separate case where an attacker ran approximately 80 malware modules through an AI-assisted evasion lab, using Claude Opus to coordinate iterative testing against EDR products. Each cycle refined the payload based on what the security tool detected. The attacker’s workflow looked remarkably similar to a developer using an AI agent to debug code — trial, error, refinement, retry.
When legitimate and malicious behaviour produce identical telemetry, the problem is no longer technical. It is architectural.
The MITRE ATT&CK Overlap Problem
The reason AI agents trigger security tools is that their normal operations map directly onto MITRE ATT&CK tactics:
- T1555 (Credentials from Password Stores): An agent accessing
.envfiles, browser-stored tokens, or credential managers looks identical to credential harvesting. - T1059 (Command and Scripting Interpreter): Agents spawn shells, execute Python scripts, and chain commands — the same execution patterns used in post-exploitation.
- T1105 (Ingress Tool Transfer): Downloading packages, fetching dependencies, pulling container images — all legitimate development tasks that match tool transfer detection signatures.
- T1547 (Boot or Logon Autostart Execution): Agents that modify system services, create scheduled tasks, or adjust startup configurations trigger persistence detection rules.
The overlap is not incidental. AI coding agents are, by design, powerful automation tools that interact deeply with the operating system. That is precisely what makes them useful, and precisely what makes them look like threats.
What Your Team Should Do
Managing this requires changes across development, security, and operations. Here is a practical framework:
1. Create Dedicated EDR Policies for AI Agent Workstations
Do not simply whitelist AI agents globally. Instead, create a dedicated device group in your EDR console for machines running AI coding tools. Apply a tailored policy that adjusts specific behavioural rules — particularly around credential access and script execution — while maintaining full detection coverage for other attack categories.
2. Implement Process-Level Allowlisting
Rather than suppressing entire detection categories, allowlist specific processes. If Claude Code runs as claude and spawns child processes through a known process tree, your EDR policy can recognise that chain and reduce alert severity without eliminating visibility. This is more surgical than category-level suppression and preserves your ability to detect genuinely anomalous behaviour.
3. Separate Your Telemetry Streams
Route AI agent telemetry to a dedicated SIEM workspace or dashboard. This gives your security team the ability to baseline what normal AI agent behaviour looks like on your specific workstations, making it far easier to spot deviations that might indicate a real attack using an AI agent as cover.
4. Lock Down Credential Access
If your AI agents do not need to access browser-stored credentials (and most development workflows do not), block that access path entirely. Use environment variables or dedicated secret management tools (HashiCorp Vault, AWS Secrets Manager, or even a well-configured .env file with restricted permissions) instead of letting agents reach into browser credential stores.
5. Audit Your Agents’ Tool Usage
Review what system tools your AI agents actually invoke. If Codex is using certutil.exe to download dependencies when curl or wget would do the job without triggering LOLBin detections, configure the agent to prefer the safer alternative. Most AI coding tools support configuration files that can constrain which system utilities the agent is allowed to use.
6. Establish a Baseline Before You Tune
Before adjusting any detection rules, run your AI agents for at least a week with full detection enabled and record every alert. This baseline tells you exactly which rules fire, how often, and in what context. Without it, you are tuning blind.
The Bigger Picture: Security Architecture for the AI-Augmented Workspace
This problem is not going away. As AI agents become more capable — browsing the web, managing infrastructure, interacting with APIs — their behavioural footprint will expand into even more ATT&CK categories. Development teams that treat this as a one-off tuning exercise will find themselves revisiting the same problem every few months.
The sustainable approach is to treat AI agents as first-class entities in your security architecture, with their own identity, their own policies, and their own monitoring. This aligns with the broader zero-trust-for-AI-agents movement that frameworks like Microsoft’s ZT4AI and the IETF’s draft agent authentication specification are driving.
At REPTILEHAUS, we help development teams integrate AI tooling without compromising their security posture. Whether you are configuring EDR policies for AI-augmented workflows, building agent governance frameworks, or rearchitecting your security monitoring for the age of AI assistants, our team has the DevSecOps expertise to get it right. Get in touch if your security alerts are telling you something your development process has not caught up with yet.
📷 Photo by Markus Spiske on Unsplash
