Recent analysis from Sophos revealed an unexpected friction point in modern infrastructure security: AI-powered coding agents, when installed on workstations or build systems, are triggering endpoint detection and response (EDR) rules originally written to catch actual attackers. The tools themselves—Claude Code, Cursor, OpenAI Codex, and similar agents—are not malicious. They simply perform a range of activities that, when observed through a behavioral security lens, resemble threat actor techniques.
What AI Agents Do That Looks Suspicious
Modern coding assistants operate with fairly broad system access. To function effectively, they often need to inspect running processes, query credential stores, enumerate installed software, and interact with the file system at scale. Sophos' telemetry found instances of these agents decrypting browser credentials, listing contents of Windows credential stores, and performing other reconnaissance-like activities that security rules were specifically tuned to flag.
From a detection engine's perspective, this behaviour is indistinguishable from legitimate attack chains. A process querying the Local Security Authority Subsystem Service (LSASS) for credentials could be a human intruder gathering domain passwords—or it could be an AI agent trying to understand the system environment. The signal alone tells you nothing about intent.
The Tuning Challenge for Infrastructure Teams
For organisations running AI coding tools on developer machines or build systems, this creates a genuine operational headache. Security teams face a choice: either suppress or whitelist these detection rules, which reduces the effectiveness of the EDR solution, or maintain strict policies that deny engineers the tools they find productive.
The problem scales across diverse infrastructure environments. If you're running a mixed fleet of developer workstations with varying levels of AI tooling adoption, tuning rules to account for each agent's specific behaviour becomes tedious. A rule that was sensible for a Windows-only environment now requires exceptions for Linux containers running similar agents. Different versions of the same tool may exhibit different patterns.
Infrastructure teams accustomed to strict allowlisting policies face particular friction. If the security posture requires explicit approval for each system-level action—which is entirely reasonable in security-sensitive environments—then an AI agent that tries to enumerate system state will consistently fail or require continuous exception requests.
Context and Legitimate Constraints
The reality is that not all organisations can simply disable EDR detection rules. Teams responsible for hosting infrastructure, payment processing systems, or compliance-sensitive workloads cannot afford false negatives in their intrusion detection. Whitelisting an entire tool because it occasionally performs credential-store queries creates blind spots.
A more sustainable approach involves understanding the specific context in which these tools operate. If an AI coding agent is running on an isolated development laptop used only for non-sensitive code review, the security posture can differ from an agent deployed in a continuous integration pipeline that handles production credentials. Similarly, an agent running under a restricted service account has different risk characteristics than one running with full user privileges.
Looking Forward
As AI-assisted development becomes routine rather than novel, EDR vendors will need to refine their detection models to account for known-benign tool behaviour. This doesn't mean relaxing security; it means moving away from simple pattern matching toward context-aware detection. Factors like source process reputation, presence of known AI libraries, and audit log evidence of intended development activity can all contribute to smarter classification.
Infrastructure teams should start by inventorying which AI tools are actually in use across their environments and testing their specific EDR responses. Understanding whether your detection rules fire on Claude Code, Cursor, or other agents installed locally gives you a baseline for rational policy decisions. Document those findings and work with your security team to define appropriate exceptions based on risk context rather than blanket whitelisting.
The underlying lesson is simple: automated detection rules designed for one threat model will inevitably create friction with new, benign tools. Managing that friction deliberately—through testing, context-aware tuning, and clear communication between infrastructure and security teams—beats discovering it during a critical audit or incident response.
