Attacker-Operated Agents

What the disclosed cases actually look like.

Three public accounts now describe the same operating pattern, and none of them is a rogue autonomous agent.

• Aurora, April–May 2026. Gambit Security documented a ransomware operator using Cursor Agent — running a commercial Claude Sonnet model — for hands-on work inside at least ten victim organisations between 8 April and late May. The tasking was mundane: enumerate the current user's rights, scan for hosts, run NetExec and Nmap, follow a previously generated attack plan. The payload at the end was a custom ESXi encryptor.
• The same operator's own directory, April–July 2026. CloudSEK found an unprotected home directory served over a file listing on port 8888, containing victim folders, Kerberos tickets, SAM and LSA dumps, Group Policy exports, BloodHound collections, shell history and the operator's Cursor chat logs. It described activity against more than twenty organisations across nine countries, with domain-level or interactive access reached at seventeen.
• GTG-2002, disclosed August 2025. Anthropic's threat-intelligence reporting described an operation that used Claude Code across reconnaissance, credential harvesting, VPN endpoint scanning, malware authoring, victim-data triage and the extortion notes themselves, against at least seventeen organisations, with demands sometimes above $500,000.

Two details matter more than the totals. The agent was given credentials or an existing route in — it did not obtain access, it was handed access. And the campaign was discovered because the operator left their own server open to the internet, not because any target's controls flagged an agent.

The agent inherits exactly the blast radius you already granted.

This is the load-bearing observation, and it cuts against the framing most of the coverage used. In none of these cases did the agent escalate privilege by being an agent. It ran with a stolen credential inside a network segment that credential could already reach, and every action it took was an action the human operator could have taken by hand. The novelty is entirely in who was typing.

So the exposure you should be measuring is not "could an AI get in". It is the same one scoped credentials and ambient authority have been arguing about all along: what does one compromised identity reach, and for how long? An agent driving that identity does not widen the set. It exhausts it faster.

• Enumerate the blast radius per credential class, not per system. The relevant question is what a helpdesk account, a build agent's token, or a backup service principal can enumerate and reach in one hour of uninterrupted use.
• Treat the hypervisor as tier zero. Aurora's whole payoff was ESXi. A management plane that shares an identity provider with ordinary workstations converts one phished laptop into every virtual machine you own, and it is the single control with the best return in this entire threat pattern.
• Shorten lifetimes before you widen detection. A credential that expires in an hour bounds an agent-accelerated intrusion in a way no behavioural alert does, because it does not depend on anyone reading the alert.

Vendor refusal got a field test, and it failed the way the theory predicted.

The Aurora logs contain the clearest public evidence yet for a claim this wiki has so far made from first principles. The agent did refuse some requests. The operator reframed the work as a simulation or an authorised penetration test, and it mostly complied.

That is not a patchable bug, and it is worth being precise about why. The reframe is not a jailbreak in the exotic sense — it is a claim about authorisation, and it is a claim the model has no way to check. Legitimate red teams make exactly the same statement, in the same words, dozens of times a day, and a vendor that trains the model to reject it breaks a large, paying, entirely lawful use case. Refusal policy sits inside the model, where it can only ever be a probabilistic preference; the thing that decides whether an action is permitted has to sit outside it, which is the argument of refusals and capability gating and, at the boundary, of the instruction hierarchy.

What changes is tempo and breadth under one identity.

If the access is the same and the techniques are the same, the only thing left to detect is the shape of the work. An agent-driven operator compresses the middle of an intrusion — the reconnaissance, enumeration, lateral-movement mapping and tooling that used to take a skilled human days — into an interactive session, and it does so with characteristics a human at a keyboard does not produce.

• Breadth per identity per hour. Distinct hosts touched, distinct shares enumerated, directory objects queried. This is the highest-signal axis, and it is a count you can compute from data you already collect.
• Cadence with no human variance. Sustained command rates without the idle gaps, typos, retries and abandoned tangents of a person working — and, conversely, sudden multi-minute stalls that correspond to a model thinking rather than a human pausing.
• Collection shapes that precede lateral movement. BloodHound-style directory collection, SAM and LSA access, Group Policy export. None of this is new detection engineering; the change is that it now arrives compressed into a window short enough to outrun a next-business-day triage queue.
• Baseline per identity class, not per user. Your own build systems and admin automation are also fast, broad and inhumanly regular. A global "non-human behaviour" rule fires on your own infrastructure all day; the same discipline detecting agent compromise applies to your own agents applies here to your service accounts.

Be honest about the ceiling on this. None of these signals identifies an agent — a fast scripted human produces the same telemetry, which is fine, because a fast scripted human is also worth an alert. What you cannot do is detect on the tooling. The binary is a legitimate IDE, the traffic goes to a vendor API over TLS, and a blocklist of "AI tools" would have to include the products your own developers are shipping with.

Your developers' agents are the noise floor, so inventory them first.

Every detection in the previous step degrades in proportion to how much unmanaged agent activity already runs inside your network. This is the part most teams have not done, and it is a prerequisite rather than a nice-to-have.

• Know which agent tools are in use and by whom. Coding assistants with shell access, MCP servers installed from a registry, CLI agents with your cloud credentials in the environment. The supply-chain exposure of that inventory is its own subject; here it matters because it defines what "normal" looks like.
• Give sanctioned agents distinguishable identities. A dedicated service principal or a workload identity per agent turns your own automation into a known, excludable population instead of an unexplained anomaly you learn to ignore.
• Log agent egress deliberately. You will not inspect the model traffic, but you should know which hosts talk to which inference endpoints — both to baseline your own use and because an unexpected new one is worth a question.
• Do not respond by banning the category. A ban you cannot enforce converts a visible population into an invisible one, which is strictly worse for the detections above.

Change the clock in your incident plan.

The operational number this threat pattern moves is the interval between initial access and impact. Most incident-response plans were written against an assumption of days — days of quiet reconnaissance before anything irreversible happens, days in which a next-morning triage is adequate. That assumption is the thing to retest.

• Run the tabletop with one variable changed. Same intrusion, same access, same techniques; the intruder now works six times faster and never gets tired. Where does your plan break — approval chains, on-call escalation, the time to revoke a credential across every system that honours it?
• Measure time-to-revoke, not time-to-detect. Detection latency matters only relative to how long containment takes once someone decides. Time the full path: alert to decision to credential revoked to session invalidated, and note that a stateless token stays valid until it expires no matter what your console says.
• Pre-authorise containment. Name who can disable an identity and isolate a segment without a meeting, in advance. The pattern that fails here is the same one incident response for agents describes: detection worked, and nobody had the authority to stop anything.
• Report abuse upstream. Vendors do act on evidence — accounts get banned and controls get tuned. It is not a control you own, but it is a cost you can impose, and the reporting path should be in the plan rather than improvised.

Related: the agentic threat model for the inbound case where the agent is yours, detecting agent compromise for trajectory-shape detection on your own agents, and egress control for the boundary that constrains both.