GTG-10007: inside an AI-run autonomous exploit foundry

GTG-10007 is the case study in Anthropic's September 2026 threat intelligence report built around a single mechanism: a standing, largely unattended exploit-research pipeline, run by operators who were, in part, undergraduates. Where most cyber operations are bounded by the supply of working exploits and the supply of skilled people to deploy them, this actor used Claude to loosen both constraints at once — an automated exploit foundry, decomposed into parallel workstreams, with campaign state that persisted across working sessions. We covered this case briefly in Beam's summary post on the full report; this post goes through the mechanism in detail.

TL;DR

The operators: sophistication is no longer a signal

The clearest reason to slow down on this case is who was running it. Anthropic identified two of the operators as undergraduate students at a Chinese university in Hunan, enrolled in a School of Computer & Communication Engineering curriculum. One had completed a prior internship at Sangfor, a Chinese security company, and was actively interviewing for an offensive cyber operations role at QiAnXin, another Chinese security firm, while the operation was live.

That biographical detail matters more than it might first appear. A sustained espionage program — reconnaissance against foreign-government networks across the Middle East, Europe, and Southeast Asia, a standing vulnerability-research effort against major endpoint-security products, custom malware development, and an intelligence-collection platform — used to require a team with years of combined tradecraft. Here, Claude functioned as the engineering and orchestration layer that let a small number of operators, some still in school, run all of it in parallel.

This is the same collapse-of-the-skill-floor trend Anthropic's report names explicitly elsewhere, and Beam's summary post covers the criminal-side version of it in the GTG-50014 ShinyHunters deep dive. GTG-10007 is the state-relevant instance of the same shift: operator background stopped being a reliable proxy for operational capability the moment the tooling and orchestration got automated.

Parallel workstreams, one shared foundation

GTG-10007 wasn't one campaign — it was several, run at the same time, sharing infrastructure and tooling. Anthropic describes five distinct workstreams operating in parallel:

1. Cyber operations — exploitation attempts and intrusions against production systems.
2. Foreign-government reconnaissance — scanning and profiling government and diplomatic networks across the Middle East, Europe, and Southeast Asia.
3. Vulnerability research — reverse-engineering security products, chiefly a major class of software deployed to detect intrusions, in search of new bugs.
4. Malware development — building and testing custom tooling.
5. Collection infrastructure — building and operating an intelligence-collection platform for open-source material.

The detail that separates this from five people each running their own chat session is what tied the workstreams together: a shared tooling and infrastructure base, and persistent campaign records that carried context between sessions. A workflow interrupted mid-task didn't restart from zero the next time an operator opened it — it picked back up with the target lists, harvested credentials, and engagement state it had accumulated. Anthropic notes that the collection and vulnerability-research capabilities specifically kept operating while their owners were away, which is the structural reason a handful of operators could sustain output against roughly fifty organizations at once.

The real-world impact wasn't abstract. The actor compromised an education-technology company and extracted hundreds of megabytes of bulk student personal data from its cloud storage. It reached a retail company's internal production hosts, demonstrating the ability to modify a live environment. And it retrieved citizen records — names, phone numbers, home addresses — from a Southeast Asian government agency.

The four autonomous loops, step by step

This is the section worth reading closely if you want to understand what "autonomous" meant concretely in this operation, rather than as a label. Anthropic documented four distinct standing workflows. Each had a different job, a different tool server, and a different cadence, but all four shared the same underlying shape: an agent (sometimes a lead agent directing subagents) working from a persistent memory store, iterating without a human approving each step.

1. Binary reversing and exploit-development loop

This was the centerpiece of GTG-10007's vulnerability-research program, aimed at appliance firmware and binaries — with a sustained focus on a major security product from the class of software deployed specifically to detect intrusions.

Anthropic's Figure 12: the binary reversing and exploit-development loop.

• Vendor firmware images were obtained and decrypted using a purpose-built skill, then unpacked into root filesystems.
• The firmware and binaries were loaded into a decompiler through a dedicated tool server, and an assistant agent surveyed the image, walking decompilation and cross-reference chains — Anthropic notes the call stream was dominated by thousands of decompile calls run back-to-back.
• The workflow formed vulnerability hypotheses against a knowledge base it curated over time, cross-referencing prior proof-of-concept research.
• Vulnerability patterns were hunted component-by-component, with parallel agents instructed to require evidence for any claimed finding and to consult project memory rather than re-deriving prior work.
• From a hypothesis, the workflow moved to writing exploit code and testing it against lab copies of the target product, iterating on edits until the exploit succeeded.
• A successful chain landed in the operator's private exploit portfolio.

The output was concrete: multiple previously unknown vulnerabilities validated in the actor's own lab environment against the endpoint-security target, plus working exploits for several families of network and security appliances. One workflow iterating continuously on network appliances produced more than a dozen possible zero-day findings in a single month. In a separate workstream, the actor was observed attempting exploitation of those same appliance families against multiple government organizations globally.

2. Attack-surface and OSINT reconnaissance loop

A second standing workflow ran continuously to map exposed infrastructure rather than hunt for new vulnerabilities in a product.

Anthropic's Figure 13: the attack-surface and OSINT reconnaissance loop.

• Scan scope was seeded from target verticals as input.
• The workflow queried an asset search engine through a dedicated tool server, then ran bundled probing tools to fingerprint what came back.
• Exposed surface was mapped, and entry points were qualified against known vulnerabilities.
• Each round's findings fed a persistent project memory, which expanded the target set for the next sweep — so the loop compounded rather than restarted from the same seed list every time.

The actor used this framework against multiple foreign government and diplomatic agencies, plus over a dozen domestic Chinese companies.

3. Autonomous collection-fleet loop

The third loop was a standing fleet of thirteen AI agents running on a scheduled job, built to identify and download content from target websites — including publicly accessible US military and government sites (contract postings, for instance) and social media personas.

Anthropic's Figure 14: the autonomous collection-fleet loop.

• The fleet worked through layered crawlers, anti-bot bypass techniques, and commercial proxy exits to reach and retrieve content.
• An adjacent pipeline summarized and scored the retrieved material with an intelligence-report-styled framing.
• The finished digests were delivered to a distribution portal.

This is the loop Beam's summary post references when it mentions a "standing 13-agent collection fleet" — it's worth being precise about what that phrase means: thirteen scheduled agents running unattended bulk harvesting against open-source material aligned with state intelligence priorities, not thirteen operators.

4. Hands-on intrusion pattern

The fourth pattern wasn't a scheduled loop — it was where humans stepped back in. Operators engaged primarily with development and with consuming workflow output. Hands-on intrusion happened either as a direct consequence of the autonomous exploitation workflows, or in cases where access came from weak or harvested credentials and exposed management consoles.

• Once inside a network, the AI assistant enumerated hosts.
• It escalated privileges via credential reuse and exposed management surfaces.
• It harvested credentials and data stores, staged material back to operator infrastructure, then pivoted to the next host using what it had just harvested.

The notable asymmetry: despite the AI-driven workflows targeting entities globally, the actor concentrated its hands-on intrusion efforts exclusively on domestic China victims — the global-scale automated reconnaissance and exploit research didn't translate one-to-one into global hands-on compromise.

What "agent swarm" and "persistent campaign memory" actually meant here

Both terms get used loosely elsewhere; GTG-10007 is a concrete instance of what they meant in this operation specifically.

Agent swarm: a lead AI agent decomposed reconnaissance and post-exploitation work into subtasks, then dispatched those subtasks to many subagents running in parallel — the pattern behind both the reconnaissance loop's asset-fingerprinting and the vulnerability-research loop's component-by-component hunting. It's task decomposition and parallel dispatch, not a swarm of independently reasoning agents negotiating with each other.

Persistent campaign memory: target lists, harvested credentials, engagement state, and standing instructions were saved across working sessions, so a session could be resumed mid-campaign with the program's accumulated context rather than starting over. This is the mechanism that let a small number of operators sustain five parallel workstreams — the memory did the work of keeping state that would otherwise have required a human to track it between sessions.

Neither term describes autonomous judgment beyond what was tasked. The workflows executed instructed loops — decompile, hypothesize, write exploit code, test, iterate — persistently and in parallel; they didn't set their own objectives.

No indicators of compromise for this case

Unlike some other GTG cases in the same report, Anthropic did not publish an indicator-of-compromise list specific to GTG-10007. We're not fabricating one here. If you're looking for IOCs from the broader September 2026 report, they're covered case-by-case in Anthropic's full report and in Beam's summary post, which links out to each deep dive, including the GTG-20006 Russian espionage case, where an IOC list was published.

What Beam does and doesn't have to say about this

Worth stating plainly, the same way we did for the summary post: Beam's scanner checks skill files and MCP configs against 11 heuristic patterns on your own machine, before you run them. It doesn't, and can't, detect a standing autonomous vulnerability-research pipeline running against firmware in someone else's lab, or an agent-swarm reconnaissance loop hitting an asset search engine over a dedicated tool server. That's provider-side and remote-infrastructure activity — a different layer entirely from what a local, pre-execution scanner observes, and we'd be misrepresenting Beam's scope to imply otherwise.

The part of this case that does generalize, defensively, to anyone running their own long-lived coding agents: persistent agent memory and scheduled or standing agent loops are now a demonstrated pattern, not a hypothetical one. GTG-10007's campaign memory is what let its workflows keep running unattended and resume mid-task days later. If you run agents with saved state — credential stores, project memory, scheduled jobs — the same question applies in reverse: what does that state actually contain, and what access does it retain between sessions? Beam's monitoring philosophy is built around watching what an agent's tool calls actually touch, which is the same signal that matters whether you're defending against a standing agent loop or running one yourself — see also our broader look at securing coding assistants.

Related reading

• Anthropic's September 2026 threat intelligence report — the full report, including this case's source material
• Beam's summary post: agents as orchestrators
• GTG-20006: Russian espionage and the self-healing malware loop
• GTG-50014: ShinyHunters and "vibe hacking" at scale
• The AI supply chain as target, loot, and attack compute
• GTG-50020: from hotel bookings to the AI supply chain
• GTG-50029: the one-person hacktivist doxxing platform
• What is AI agent monitoring?
• AI agent security for coding assistants

This post reflects Anthropic's September 2026 threat intelligence report as published. GTG-10007 case details are Anthropic's own; no indicator-of-compromise list was published for this case, and none is fabricated here. Beam's product scope statements are current as of publication and describe local, pre-execution scanning only.