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 reading 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 that 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 were not attacks at all. 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 is 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 stuff 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 read saved browser passwords. They ask Windows to list what is in the credential store, which is a locked drawer where the operating system keeps logins for apps and websites. They enumerate files, network shares, and running processes to figure out where they have 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 is how it understands the machine it is working on.

In practice, the detection engine cannot tell the two apart from behaviour alone. It sees a process reading credential stores. It fires.

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. That analyst 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 in the company running an AI assistant, and the queue gets long fast.

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

There is a second issue nobody wants to talk about. These agents are running 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 will happily perform hostile actions using a trusted developer account. The endpoint tool has now been trained by its own operators to ignore exactly that pattern.

What should ordinary users take from this?

If you use an AI coding tool at work, assume your security team can see what it is doing, and expect awkward questions when it touches saved passwords or system settings. Do not point it at your personal accounts on a work machine.

One thing the post-mortem will say: the alerts were there, the analysts just stopped reading them.

Operational takeaway: if you run AI agents in production developer environments, tag their processes and build separate detection logic for them, do not just mute the rules.