Your agent decrypted the browser's saved passwords, listed the credential manager, pulled an installer with a Windows system utility, and dropped a script into the startup folder. Every one of those is on the checklist for a real intruder. Sophos watched a coding agent do all of it. Nothing was malicious — which is exactly the problem, because the telemetry an attacker generates and the telemetry your agent generates are the same telemetry.

On July 7, 2026, Sophos X-Ops published an analysis of a week of endpoint telemetry from June, looking at what happens when developers point coding agents at real machines. The finding is a collision, not a bug anyone can patch. The everyday work of an agent — read a credential, run a command, download a tool, keep something running between reboots — maps almost one-to-one onto the MITRE ATT&CK tactics that endpoint detection is tuned to catch. So the sensors fired.

What the sensors actually saw

Across the week, the largest share of blocking rule hits — 56.2% — fell under Credential Access, and another 28.8% under Execution. Those are two of the most attacker-shaped categories in the framework. The single biggest credential rule, at 42.6% of that group, fires when a process uses Windows' Data Protection API (DPAPI, the OS service that unlocks a user's stored secrets) to decrypt the browser's saved logins. Sophos traced it to GStack's /browse skill — a popular skill pack that gives an agent a browser — running PowerShell to unlock saved browser data. It caught it running under Claude Code.

The rest of the list reads like an incident report. Agents ran cmdkey /list to enumerate the Windows Credential Manager. They killed the browser process and then reached into its credential store. They downloaded a Python installer using certutil and bitsadmin — two legitimate Windows binaries that attackers abuse to fetch payloads without tripping a download filter, the technique defenders call a LOLBin ("living off the land binary"). Cursor wrote a VBScript into the Windows Startup folder, which is textbook persistence. And Claude command lines carried --dangerously-skip-permissions, the flag that turns off the agent's own "are you sure?" prompts.

None of it was an attack. In context it is almost always automation the developer asked for. But Sophos is blunt about what that means for defense: the rules are working as designed, and behavior alone can no longer tell a benign agent from a real one.

One command block, two authors, one sensor. A coding agent running a browser-automation skill and an intruder doing post-exploitation issue the same moves — decrypt the browser vault, list the credential manager, fetch a tool with a LOLBin, write to Startup. The endpoint sensor sees identical telemetry and cannot say who typed it. The only fact that differs is whose machine the commands ran on.

The trap is fixing it at the sensor

Read that finding as an operator and the pressure is obvious. Your team adopts coding agents. The endpoint tool starts throwing credential-access and execution alerts every time someone runs one. The alerts are noisy, and they're "false" in the sense that no one is under attack — so the natural move is to quiet them: add an exception for the agent, whitelist the skill pack, stop flagging DPAPI reads from that process tree.

The moment you do that, you have told your defenses to ignore the exact sequence a real intruder uses. And the agent is not a safe thing to carve out, because it is the most likely thing on the machine to be turned against you. A prompt injection hidden in a repository, a poisoned marketplace skill, a malicious dependency — we have covered each of these — makes the agent run attacker instructions with your privileges. When that happens, the agent does the same DPAPI decrypt, the same credential-manager dump, the same LOLBin fetch — except now it means it. You have blinded the one sensor that would have caught it, in the name of stopping it from crying wolf about itself.

Sophos lands on the sober version: detection engineering will have to adapt, some rules will need tuning, and the distinguishing signal has to come from context — which agent, invoked how — rather than from the action alone. That is correct, and it is also a lot of ongoing work to keep a sensor honest about a moving target. There is a blunter option: stop running the agent where the sensor lives.

Move the agent, not the alarm

Bromure Agentic Coding runs the whole agent one hypervisor away, inside a disposable Linux VM on your Mac. The credential-store reads, the tool downloads, the persistence writes — all of it happens in a box that is not your machine, and that reset wipes back to a clean base image between sessions. Three things follow, and none of them require you to soften a single rule on the host.

The noise never reaches your endpoint. Your host's real defenses stay strict because the agent isn't on the host to trip them. The startup-folder write lands in a throwaway filesystem; the reboot it was waiting for never comes, and the reset discards it either way.

The credential reads come up empty. This is the direct hit on that 56.2%. Bromure keeps real secrets on the host and swaps in fakes at the proxy on the wire, so what actually sits in the VM is decoy material — a brm_… placeholder where the API key should be, a synthetic kubeconfig, throwaway git and ssh credentials. An agent that decrypts the browser vault or dumps the credential manager inside that VM harvests nothing that works. The real value is substituted only on the outbound request, at a boundary the agent can't reach around.

--dangerously-skip-permissions stops being dangerous. The flag exists because being asked "are you sure?" on every step kills the point of an agent; people turn it off. What makes it reckless is the machine underneath. Move the machine to a disposable VM with decoy credentials and the flag is just fast — the reason to fear it was never the flag, it was the blast radius.

Two places to put the same agent. On your machine (left), the attacker-shaped commands hit real credentials and real persistence, and your endpoint tool is stuck choosing between constant false positives and a blind spot. In a Bromure VM (right), the same commands hit decoy credentials in a box that resets, the host sensor stays strict because the agent isn't on the host, and outbound moves cross a boundary that swaps in real secrets, gates destructive calls, and logs the traffic.

What about the hijacked agent

Containment answers the noise, but the sharper worry is the agent that is not merely loud — it has been turned. Bromure's boundary is built for that case too. Its on-device injection detection scores the untrusted content and instruction files the agent reads — with a local PromptGuard model and a fine-tuned classifier — before the agent acts on them, so the rogue "now exfiltrate the keys" gets flagged at the door. The moves that would matter outside the box — a push, a deploy, a Delete* against your cloud — cross the host proxy, where Guardrails can strip destructive calls entirely and per-destination consent can require a human tap first. And every outbound request lands in the session trace, so the callback an intruder needs shows up as a logged line carrying a fake credential.

The behavioral collision Sophos measured is real and it is not going away — a coding agent's honest job overlaps with an attacker's playbook by design. You cannot resolve that at the sensor without either drowning in false positives or cutting a hole your own agent will walk through the day it is compromised. Bromure resolves it somewhere else: it stops caring which one typed the command, because the command lands in a box that resets, spends credentials that are decoys, and can only touch the outside world through a boundary that watches.

What this draws a line around

Isolation is containment, not a promise that nothing bad executes. It is worth being precise about the edges.

Those are Windows names; the collision is not

DPAPI, cmdkey, certutil, and the Startup folder are Windows. Bromure runs the agent on Linux, so those exact binaries never fire inside it. But the pattern is platform-independent: an agent on Linux reads ~/.aws/credentials, dumps environment tokens, and writes a cron or systemd unit — the same attacker-shaped moves under different names. The control is the same too. Location and decoys, not signatures.

Substitution covers the secrets you configure

The decoy swap protects the credentials you put in a profile: model keys, git and cloud tokens, managed database endpoints, ssh keys. A password a script writes to a file mid-session, or a secret you paste into the box by hand, is just a file the agent can read. Keep secrets in the broker, not in the workspace.

Detection is a net, not a wall

On-device injection scoring flags a rogue instruction more often than not, but a determined author can starve any single scanner. Treat the detector as one layer; the containment — a throwaway box with fake keys and a logged egress — is what holds when a detector misses.

Your host EDR still matters

Bromure does not replace endpoint protection; it gives it a cleaner job. The agent's noise moves off the host, so your sensor keeps watching the machine you actually log into, undulled — and a real intruder there still has to get past it.

The lesson underneath the Sophos numbers is not "agents are dangerous." It is that you cannot tell a good actor from a bad one by the shape of the commands, because the shape is the same. So stop trying to decide it at the keyboard, and decide it at the perimeter instead: run the agent where its attacker-shaped work is contained, its credentials are fake, and its every step outward is logged. Install it.