The framework did nothing a skilled attacker couldn't. It just ran without waiting for a human decision.
What Google actually watched happen
AI agent credential harvesting is an attack pattern in which an attacker uses an autonomous, multi-agent AI framework to automate steps like scanning for exposed secrets, troubleshooting, and IP rotation without waiting for human review at each step. On September 8, 2026, Google's Threat Intelligence Group (GTIG) published a report documenting a real-world case of it, not a red-team exercise: Mandiant observed a suspected financially motivated attacker compromise an organization's cloud infrastructure, then deploy an autonomous, multi-agent attack framework on top of it. Using an AI coding chatbot, a prompt, and a set of agent instructions, the attacker planned, built, and executed a mass credential-harvesting campaign that compromised thousands of third-party credentials—in less than six hours. A separate case in the same report—an exposed C2 (command-and-control) server running a framework GTIG calls "Recon"—involved a dashboard managing over 23,800 harvested secrets; that figure belongs to that case, not this one.
Google's report doesn't characterize the exploits as novel—what it documents is the automation. Per the report, the agent instructions "enabled the AI to autonomously manage the vulnerability scanning pipeline, perform real-time troubleshooting, and execute Internet Protocol (IP) rotation logic without manual intervention." Operating from the victim's own cloud infrastructure let the attacker route traffic through legitimate IPs. Every one of those steps is something a skilled attacker could already do by hand. The agent framework just did all of it continuously, without sleeping and without waiting for a human to approve the next move.
That's worth sitting with if you run infrastructure security: the six-hour number isn't a story about a smarter attack. It's a story about a faster one.
The mechanism the report actually blames
It's tempting to read this as "AI attacks are now undetectable." Google's own report doesn't support that framing. In a grouped mitigations passage, the report says "these activities" triggered Gemini safety responses, and that Google then disrupted campaigns based on the actors' operational-security failures and disabled related assets. What it never describes is anyone interrupting the six-hour loop while it ran.
What it does say, elsewhere in the same report, is that GTIG has "not yet observed threat actors deploying fully autonomous pipelines against targets in the wild." A human still triggered this operation and deployed the framework. The agent handled execution at machine speed—it didn't run the whole kill chain end to end on its own.
The mechanism the report names instead is more specific, and more useful: "human-in-the-loop latency is dramatically reduced, compressing the traditional window for defenders to respond." That's the actual claim. Attackers can now execute at a velocity that outpaces how fast a person can notice, decide, and act. The defender's problem is timing: by the time a human is in position to respond, the window has already closed.
The report also frames this as part of a gradual pattern over the last quarter, not a one-off. It explicitly disclaims any "immediate shift to fully autonomous exploitation."
Why "compressed response time" is the harder problem to solve
Alert-driven response assumes a human is somewhere in the chain—reviewing an alert, approving a remediation, deciding whether a scan result is a real finding. That assumption holds against a human attacker working at human speed. It doesn't hold when the other side has automated scanning, troubleshooting, and IP rotation into a continuous loop, and treating this as a detection-gap problem leads to the wrong fix: better logging and better alerting still assume a human reads the alert before the next step happens. The loop from access to thousands of credentials closed in under six hours.
The question worth asking your own team: how long does it actually take, right now, from an anomalous scan hitting your logs to someone approving or blocking the next step? Compare that measured interval directly against this report's under-six-hour campaign window.
Where this connects to execution control
This article reads GTIG's compressed-response-window finding as a judgment-timing problem: an action goes unevaluated until after it happens. The same gap shows up on infrastructure you govern. Where Alpacon's command judgment is enabled, every command an agent runs is scored in real time, before it reaches the host—not after an alert fires.
The takeaway
Google's report shows a real campaign compressing the time between "access obtained" and "objective completed" into less than six hours. The fix is judgment that runs before the command executes, not after the alert fires.
That's what "runtime judgment on AI agent execution" has to mean in practice: evaluating what an agent is about to do, before it does it, while there's still time for a person to weigh in.
