Google’s Threat Intelligence Group has drawn a line under a shift that security teams have been arguing about for two years: artificial intelligence is no longer just something attackers use to move faster. It is now something they steal, ransom, and fight each other over.
In a report published September 8, GTIG (the merged Mandiant and Google threat research unit) laid out its findings from the second quarter of 2026, and the headline case is stark. A financially motivated actor broke into an organization’s cloud environment, then used an AI coding assistant, a single prompt, and a set of agent instructions to plan, build, and run a mass credential harvesting campaign, start to finish, in under six hours. No human operator sat in the loop for most of it.
The mechanics of a six-hour breach
GTIG’s researchers, Aurora Blum, Kelli Vanderlee, Jess Xia, David Mainor, and Kimberly Goody, describe an attacker group tracked as UNC6780 that turned AI development infrastructure itself into an attack surface. The group trojanized legitimate forks of Model Context Protocol (MCP) servers, including a copy of the popular tiktoken_mcp package, and published them to PyPI. Once a developer or an AI coding assistant pulled the package, injected code reached into GitHub Actions workflows and extracted OIDC tokens straight from the CI/CD runner.
Media Partner
From there, a credential stealer GTIG calls DUSTMAKER did the rest: harvesting secrets, then republishing compromised packages with valid SLSA Build 3 attestations so the poisoned code looked legitimate to any automated supply chain check. UNC6780 also planted adversarial prompts inside hidden IDE configuration directories, such as .claude/, .vscode/, and .cursor/, engineered to make LLM-based security scanners wave the malicious code through. GTIG counted more than half a dozen distinct methods the group used to target AI coding tools, from Claude and Copilot to Cursor and Cline, over the quarter.
The scale of what got harvested is what stands out. GTIG says a single campaign managed more than 23,800 secrets, mostly API keys for cloud and AI services, through a real-time dashboard the actor called “Recon.” Separately, the report ties the group to unauthorized deployment of 48 vCPU compute instances on compromised cloud accounts, used to run AI workloads the victim never authorized or billed for.
When the AI model itself is the ransom
The second thread in the report is arguably the more consequential one for CISOs who have spent 2026 racing to stand up AI programs of their own: attackers are no longer just after the data an AI system touches. They are after the AI system.
GTIG documents a healthcare organization where intruders stole corporate records, drug research data, and a proprietary AI model the company had built in-house, then threatened to publish all of it unless a ransom was paid. In a separate case involving an AI media generation company, attackers exfiltrated source code, prompts, “skills,” model training scripts, and API secrets, and used the haul as extortion leverage. As the report puts it: “In Q2 2026, Mandiant investigated multiple data theft extortion operations in which threat actors stole proprietary AI data, including models, skills, prompts, source code, and related research.”
That framing matters because it reclassifies AI infrastructure, not as a productivity tool sitting alongside the crown jewels, but as a crown jewel in its own right. A stolen customer database is a familiar breach. A stolen model, complete with the prompts and training scripts that make it reproducible, is functionally a stolen product, and GTIG’s report suggests extortion crews have already worked that out.
The market is pricing this in
GTIG also tracked the underground economy adjusting in real time. Prices for stolen Claude and Gemini credentials on criminal marketplaces roughly doubled over the course of 2026, the report found, a signal that demand for AI-service access is climbing faster than defenders are locking it down. Separately, GTIG observed coordinated model distillation campaigns, attempts to copy the behavior of Google’s own AI models by hammering them with more than 100 million prompts, an industrial-scale effort to extract a competitor’s model economics without the R&D spend.
None of this is abstract for defenders. GTIG’s researchers also flagged that the gap between a public patch and a working, AI-generated exploit is now measured in about a month, not the quarters it used to take, after LLM-generated exploit artifacts turned up roughly a month behind a recent Firefox patch release.
What it means for the security leader
The practical shift is that AI tooling now needs to be inventoried, scoped, and monitored the way any other privileged system is, not treated as a developer convenience sitting outside the asset register. That means CI/CD pipelines that call AI coding assistants need the same OIDC token scoping and runner isolation as any other automated deployment path. It means MCP servers and other AI agent plugins pulled from public registries need the same supply chain scrutiny as any other third-party dependency, because GTIG’s report shows attackers are specifically targeting that trust relationship. And it means any organization that has built or fine-tuned a proprietary model needs to ask whether that model, and the prompts and scripts that reproduce it, are protected like the intellectual property they are, because GTIG’s healthcare and AI-media cases show ransom crews already treat them that way.
Security teams have spent the past year adjusting to AI agents acting as threat actors in their own right and to a widening exploit-development race between frontier AI labs and attackers. GTIG’s Q2 findings add a third front: the AI systems themselves, and the data that trains them, are now on the target list, not just the tool bench.
What to do
Three moves follow directly from GTIG’s findings. Treat MCP servers, AI coding plugins, and agent frameworks pulled from public package registries as unverified third-party code until proven otherwise, and pin versions rather than trusting forks. Scope CI/CD OIDC tokens tightly enough that a compromised runner cannot reach beyond the pipeline it serves. And classify any proprietary model, along with the prompts, skills, and training scripts that reproduce it, as a protected asset with its own access controls and monitoring, not an artifact left sitting in a developer’s workspace.
Source: Google Threat Intelligence Group
