Google Threat Intelligence Group reports that a suspected financially motivated attacker compromised an organization's cloud infrastructure, then used an AI coding chatbot and a multi-agent framework to plan, build and run mass credential harvesting in less than six hours. According to Google's September 8 report, the operation compromised thousands of third-party credentials while agents managed scanning, troubleshooting and IP rotation with little human intervention.
This is a Google and Mandiant observation, not a public statement from the unnamed victim. BleepingComputer independently reported the research, but the exact measurements still originate with Google. The defensible conclusion is not that every intrusion is now autonomous. It is that automation can compress a credential-theft and response cycle from days into hours.
What Google observed—and what it did not
Mandiant says the attacker operated from a victim's legitimate cloud infrastructure. That gave the campaign trusted-looking source addresses while the agent framework scanned targets and collected credentials. Google describes the result as thousands of compromised third-party credentials, but does not identify the organization, publish a unique-victim count or say how many of the credentials were later used.
The same report describes a separate exposed command-and-control server running a framework called Recon. Its dashboard was designed to organize and validate more than 23,800 harvested secrets, including cloud and AI API keys. That figure belongs to the Recon observation; it must not be added to, or treated as the victim count for, the six-hour campaign.
Google also states that it has not observed threat actors broadly deploying fully autonomous pipelines for zero-day discovery and network exploitation against real-world targets. In the reported six-hour case, a human supplied the chatbot, prompt and agent instructions. The important shift is faster orchestration of familiar attack tasks, not proof that human operators have disappeared.
Start the secret-recovery clock at initial access
When an attacker can enumerate and test credentials at machine speed, a long-lived key remains useful for too long. Incident teams should assume that secrets reachable from the compromised cloud account, workload or automation runner may already have been copied. Rotation should be deliberate, but the preparation for it should begin during containment—not after a complete forensic narrative is available.
- Contain the execution path first. Isolate affected workloads, disable malicious automation and preserve the evidence needed to understand what the attacker could access.
- Revoke active access. Invalidate sessions, refresh tokens, temporary cloud credentials and attacker-created identities before distributing replacement material.
- Map the secret graph. Identify which keys can read other secrets, mint tokens, change identity policy, publish software or reach production data.
- Replace the issuers before the dependants. Rotate root, identity-provider, vault, CI/CD and cloud-control credentials before lower-impact application keys that they can recreate.
- Reduce scope and lifetime. Replace shared, reusable credentials with workload identities or narrowly scoped, short-lived credentials where the platform supports them.
- Verify every handoff. Confirm the person, device and destination independently before sending emergency access or recovery codes.
Do not return replacement secrets to the compromised workspace
A technically correct rotation can fail if the new value is pasted into the same cloud console, agent workspace, mailbox, chat or ticket that the attacker could inspect. Keep the incident record for decisions and evidence, but keep plaintext replacement values out of that durable record. A clean recipient device and a separately verified identity matter as much as encryption in transit.
Secretus can provide a time-limited, one-time encrypted delivery path for a temporary password, recovery code or API key after the incident team has verified the recipient and endpoint. That reduces persistent plaintext copies in email and chat. It does not detect an AI agent, clean compromised infrastructure, revoke an existing token or make an untrusted device safe.
Controls that reduce the next blast radius
- Prefer workload identity and just-in-time access over static credentials embedded in agent instructions, repositories or environment files.
- Assign a separate credential to each workload and environment so one leak can be revoked without a company-wide cutover.
- Block agents from reading secrets unless the task explicitly requires them, and log every secret-store read and token issuance.
- Alert on unusual validation attempts, rapid cross-service use, unexpected geography and key use from newly created cloud resources.
- Practice a recovery sequence that works when chat, email, CI/CD and the primary cloud account are all considered untrusted.
What remains unknown
Google does not name the affected organization, the vulnerable services scanned, the holders of the third-party credentials or the downstream impact. The public report does not establish how many records represented unique credentials, how many were valid when found or whether they were used after collection. Those gaps prevent a confirmed victim count or a claim that the campaign caused a particular breach.