When your AI coder looks exactly like a hacker to the security software

Key points

• Sophos reviewed one week of its own endpoint security data and found AI coding assistants repeatedly triggering rules designed to catch human attackers.
• The tools involved include Claude Code from Anthropic, Cursor and OpenAI Codex, all now in wide use by software developers.
• The agents were not doing anything malicious, but their normal behaviour looks almost identical to how a real intruder pokes around a machine.
• Actions flagged included decrypting saved browser passwords and listing what sits in the Windows credential store, a built-in vault for logins.
• Security teams now face a growing pile of false alarms they still have to investigate one by one.

Here is a headache landing on a lot of security desks at once.

Sophos, which sells software that watches company laptops for signs of a break-in, looked at a week of alerts from its own customers. A chunk of them weren't attacks. They were AI coding assistants, the tools developers now use to write and run code on their behalf, behaving in ways that look identical to a burglar rifling through drawers.

The report, first surfaced by The Hacker News, names three of the most popular: Claude Code from Anthropic, Cursor and OpenAI Codex. None of them are malicious. That's the whole problem.

Why is a helpful AI setting off burglar alarms?

Because the alarms were written to spot exactly the kind of poking around these tools do as part of their job.

Endpoint security software, the kind that runs on your work laptop and flags suspicious behaviour, is tuned to catch what attackers typically do in the first minutes after they get in. They decrypt saved browser passwords. They ask Windows to list what's in the credential store, a locked drawer where the operating system keeps logins for apps and websites. File enumeration and process listing follow, so the attacker understands where they've landed.

An AI coding agent asked to "debug the login flow" or "help me test this script against our staging environment" will do many of the same things. It has to. That's how it understands the machine it's working on.

The detection engine can't tell the two apart from behaviour alone. It sees a process reading credential stores. It fires. We first covered this detection blind spot in our 1 July story on behaviour-based detection logic, and the gap hasn't closed.

What does this actually mean for a company?

More noise, and a real risk that a genuine attack gets lost in it.

Every false alert still has to be triaged by a human analyst, who has to work out whether the process reading the password vault is Claude Code doing what the developer asked or a real intruder using the developer's laptop as a beachhead. Multiply that by every engineer running an AI assistant, and the queue gets long fast.

The failure mode is obvious. Analysts start rubber-stamping alerts as "probably just the AI" and eventually wave through the one that wasn't. That's the incident that gets a postmortem.

There's a second issue nobody wants to talk about. These agents run with the developer's full permissions. If someone tricks the AI, through a poisoned dependency or a booby-trapped prompt hidden in a file it reads, it'll happily perform hostile actions using a trusted developer account. We reported exactly that scenario on 3 July: researchers planted a single bogus bug report and watched an AI agent obediently run the attackers' code, no alarm raised. The endpoint tool has now been trained by its own operators to ignore exactly that pattern.

Should you worry if you use one of these tools?

If you use an AI coding tool at work, assume your security team can see what it's doing. Expect questions when it touches saved passwords or system settings. Don't point it at personal accounts on a work machine.

The postmortem will say the alerts were there. The analysts just stopped reading them.

If you run AI agents in developer environments, tag their processes and build separate detection logic for them. Don't mute the rules.