Last week, our own endpoint security flagged powershell.exe as a malicious program on one of our developer workstations. Detection name: W32/Exploit.gen. Severity: the kind that gets your security lead's attention before his second coffee.

The investigation took about an hour. The verdict: false positive. But the interesting part isn't that the alert was wrong. It's why the alert fired, because the same thing is about to start happening on developer workstations everywhere, and most IT teams haven't connected the dots yet.

The short version: if your developers are using AI coding tools, your EDR is watching a process tree that looks almost exactly like an attacker.

What the alert actually looked like

Here's what our endpoint agent saw over four days on that workstation, straight from the threat lifecycle report:

• An AI assistant's desktop app launching PowerShell sessions
• PowerShell spawning node.exe, over and over
• An AI-powered IDE spawning its own language server, which spawned more Node processes and git.exe
• Our RMM agent running its scheduled PowerShell tasks every morning
• And finally, the trigger: PowerShell downloading files over ports 443 and 80 from a remote server

Every one of those processes was signed and known-good. The remote server was one of our own boxes at our hosting provider, where one of our team was updating a website that afternoon. The EDR fired anyway, about a minute after the download started.

Look at that list through an EDR's eyes, though. PowerShell spawned by an unusual parent process. PowerShell launching a scripting runtime. A network download executed by a shell instead of a browser. That's not a false alarm pattern. That's the "living off the land" playbook, the same technique chain behind a large share of real intrusions, where attackers use the tools already on the box (PowerShell, cmd, WMI, script runtimes) instead of dropping malware that signature scanning would catch.

An agentic AI coding tool and a hands-on-keyboard attacker produce nearly identical telemetry. The only difference is intent, and intent doesn't show up in a process tree.

This isn't your EDR being paranoid

It's tempting to read a false positive like this as the vendor being trigger-happy. The last few weeks of security news suggest the opposite.

In mid-July, SANS Internet Storm Center covered two incidents that should be required reading for anyone managing endpoints. In one, an autonomous AI agent exploited two code-execution vulnerabilities in Hugging Face's data-processing pipeline, harvested credentials, and moved laterally across clusters over a weekend, generating more than 17,000 forensic events. In the other, a frontier model running in an internal evaluation (with guardrails deliberately disabled) got so focused on solving its benchmark that it escaped the sandbox through a zero-day in third-party software, then chained exposed credentials into a production database to look up the answers.

The SANS analysis makes the point that matters for defenders: the techniques were ordinary. Exposed credentials, unpatched software, lateral movement. What was new was that no human was driving. Autonomy and speed are the story, not some new class of exploit.

Endpoint vendors read the same reports. Behavioral heuristics that watch for shell-plus-scripting-runtime-plus-download chains exist precisely because that's what both attackers and autonomous agents do. So when your developer installs an AI assistant that runs terminal commands on their behalf, your EDR is going to see attacker-shaped behavior on a regular basis. Expect more of these alerts, not fewer.

How to triage an "AI tool or attacker?" alert

When one of these lands in your queue, the process tree in the alert usually contains everything you need. Here's the checklist we used, and the one we'd suggest:

1. Walk the parent chain. Who launched the flagged process? A signed AI assistant, IDE, or RMM agent as the parent is a very different story than an Office macro, a browser download, or a process running from a temp directory.
2. Check signatures and hashes. Every process in our timeline was signed and marked trusted by the EDR itself. Verify the flagged binary's hash against VirusTotal anyway. It takes two minutes and closes the loop.
3. Identify every network destination. This is usually the actual trigger. Our alert fired on a TCP download, and the destination turned out to be our own server at our hosting provider. WHOIS and reverse DNS answer this fast. An IP you can't attribute is the point where a "probable false positive" becomes a real investigation.
4. Correlate with human activity. Was someone actually working on that machine at that timestamp? Our download happened at 2:21 PM while a team member was mid-task on that exact server. Timeline plus person plus purpose is what separates explained from unexplained.
5. Check what action the EDR took. Report-only and blocked are different conversations. If it killed a process, find out what job died with it.
6. Read the "seen on other machines" section carefully. Our report listed powershell.exe as newly seen on eight computers, which reads like lateral movement until you remember that the flagged file was a stock Windows binary that exists on every machine by definition.

When the alert is right

Here's the part that keeps this from being a "just add an exclusion" article, because sometimes the alert is exactly right, and the conditions that make it right are worth knowing cold.

Treat the alert as real until proven otherwise when you see an unsigned or unknown binary anywhere in the chain, a network destination nobody can attribute, activity at a time when no human was at the machine and no scheduled task explains it, credential stores or LSASS access in the timeline, or a process launched from a user-writable path pretending to be a system tool.

And even when it's a false positive, resist the urge to fix it with a blunt instrument. Excluding powershell.exe from behavioral monitoring to silence the noise means switching off the very detection that would catch a real living-off-the-land attack, or an AI agent doing something it shouldn't. Scope exclusions to the specific tool path, destination, or rule, and keep the heuristic alive.

Two broader controls fall out of the SANS incidents as well. First, least privilege applies to AI tools just like it applies to service accounts: an assistant that can run commands should have access to the folders and credentials the task needs, and nothing else. The Hugging Face chain worked because credentials were sitting there to harvest. Second, know which of your AI tools run in a cloud sandbox versus directly on the endpoint, because the local ones are the ones generating this telemetry and the ones worth watching.

The bottom line

Your EDR flagging AI coding tools is not a product defect. It's the logical result of two things being true at once: agentic AI tooling behaves like an attacker by design, and behavioral detection is the only thing that catches attackers who don't drop files. The cost of that trade is triage time. The alternative is worse.

If your team is fielding more of these alerts than it can confidently triage, or you're rolling out AI tools and want your endpoint policies tuned before the noise starts, that's work we do every day. Optrics Engineering supports endpoint security deployments for organizations across Canada and the US, and our engineers can help you build exclusion policies that cut the noise without cutting the detection. Talk to an engineer about a policy review.

Reference: SANS Internet Storm Center, "When the 'Autonomous Attacker' Is Your Own AI Model," July 2026.