The trap of IA code assistants: noise in detections and real risk for credentials

The recent X-ray that Sophos did about a week of his telemetry brings a clear lesson: the IA-driven code assistants are generating behavior patterns that behavioral-based detection engines interpret as intrusions, even if they are not. Legitimate automation processes - decrypt credentials saved in browsers using DPAPI, list the Credentials Administrator with cmdkey, download binaries with native utilities such as certutile or bitsadmin, or leave scripts in the home folder - are exactly the signs that for years have served as "high fidelity" to detect attackers. The change is the emitter: now it can be a development agent acting to help the user, an attacker using an agent to improve malware or an agent kidnapped by malicious inputs.

That doesn't make access to secrets harmless. Decrypt data protected by the Windows Data Protection API (DPAPI) or list credentials remain high-risk actions and must remain limited. Microsoft describes how DPAPI works and why its use constitutes access to sensitive material; any process that invokes it deserves a much higher level of scrutiny than a routine download of code. https: / / learn.microsoft.com

The operational lesson for security equipment is double. On the one hand, you can no longer blindly rely on rules that treated as definitive any use of living off the land tools. On the other hand, protection on access to credentials and persistence should not be reduced: a legitimate agent should not have a white card to extract secrets or to install components that survive the reboot. The telemetry that Sophos presents is punctual and limited to a specific fleet in June 2026, but the patterns agree with what other strategic reports describe: the lateral movement and abuse of legitimate tools are consolidated as the norm, and the IA agents introduce noise into these signals. See CrowdStrike's analysis of the trend towards operations without traditional malware. https: / / www.crowdstrike.com

To reduce false positives without opening the door to intrusions, detection teams must adopt a rule segmentation strategy. Listen less to "what" and more to "who / from where / for what": refine detections by parent process (e.g., identify agent processes such as claude.exe or cursor.exe), by work route and by reputation of the discharge destination. If a legitimate operation comes from a known agent, with an authorized workspace and download from a reputed domain, the event can be treated less severely; if the same conduct attempts to access the credentials store or write persistence outside a certified installer, the alert should be kept high.

At the policy and configuration level, there are immediate practical measures. To prevent or control dangerous modes of the attendees (for example, flags that jump permissions) through centralized policies; to deny the agent direct access to vaults and user credentials and to force integration through APIs of managed secrets; to require explicit approval for any automatic touch of the credentials store; and to separate development environments where agents can test downloads or execute scripts without affecting production workstations.

It is also appropriate to strengthen the "safety laboratory" for the IA tools themselves: to secure the input channel (to prevent the poisoning of prompts or data), to audit the actions that an agent proposes before allowing execution and to maintain a detailed record of the agent's decision chain to facilitate incident response. It is not enough to detect a low binary with certutil; the subsequent behavior must be observed: did it pivoted after a blockade? were alternative routes tested? That ability to "retry with another tool" is an active behavior marker that distinguishes a live attacker from a static script, and today is shared by benign agents.

For EDR suppliers and agent manufacturers there is a need for collaboration: code assistants should expose metadata that allow them to be reliably classified (executable signature, skillpack hash, standard time routes, operating mode) and security providers should offer documented ways to differentiate automated works and granular permissions. At the same time, the design of the agents should by default avoid extensive privileges over secrets and clearly document unsafe ways for administrators to disable them.

The balance is delicate: not all events around legitimate tools indicate intrusion nor should the guard be reduced over access to secrets and persistence. The practical result for any organization is to review EDR rules with focus on context and reputation, tighten controls around credentials and adopt minimum privileges policies for IA assistants. We are likely to see more noise in the detections in the coming months as the adoption of these agents grows; preparing now will reduce both warning fatigue and the real risk that an agent - benign, malicious or abducted - will allow a gap.