CSIPE

Published

- 19 min read

The Six-Hour AI Attack Is a Response-Clock Test

AI Security Agent Safety Cloud Security

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

An attacker broke into an organisation’s cloud environment, assembled a team of AI agents, and used it to compromise thousands of outside credentials in less than six hours. That is the sharpest finding in a Google Threat Intelligence Group report published on 8 September 2026. The agents managed scanning, corrected operational errors, and changed internet addresses without waiting for a person to nurse every step along (Google Threat Intelligence Group).

Six hours makes an excellent headline. It also tempts us to learn the wrong lesson. This was not a magic model waking up and inventing crime from an empty chat window. According to Google’s account, a financially motivated actor first had control of a victim’s cloud resource. The attacker then supplied an AI coding chatbot with a prompt, agent instructions, and prepared Markdown playbooks. Human choices established the foothold, the objective, the operating instructions, and the place from which the work ran.

The important change is the shrinking gap between those choices and thousands of completed actions. A conventional script already gives an attacker speed. An agent can add adaptation: notice a failed request, alter the next attempt, keep the scanning pipeline moving, and rotate its source addresses. If your controls assume that a person will pause between those steps, six hours becomes a test your response path may never have been designed to take.

What Google actually observed

The report covers activity Google tracked during the second quarter of 2026, rather than a campaign that began this week. Google published the findings on 8 September. Mandiant investigators, part of Google, saw a suspected financially motivated actor compromise an unnamed organisation’s cloud infrastructure and deploy an autonomous, multi-agent framework there. The public report does not name the victim, identify the initial access method, or publish a complete minute-by-minute account.

That boundary matters because some retellings slide from “agent-enabled campaign” into “AI launched an attack by itself.” Google makes a narrower claim. The attacker used an AI coding chatbot, one prompt, a set of agent instructions, and preconfigured Markdown files as operational playbooks. With those ingredients, the framework planned, built, and ran mass credential harvesting in less than six hours, compromising thousands of credentials belonging to third parties (Google Threat Intelligence Group).

Independent reporting is consistent on the core sequence. SiliconANGLE reported on 8 September that troubleshooting and internet-address rotation ran without an operator, while traffic left from the victim’s own cloud addresses (SiliconANGLE). The Hacker News separately reported that the system managed vulnerability scanning, real-time troubleshooting, and IP rotation without continuous human handling (The Hacker News). Those publications rely on Google’s investigation for the underlying incident, but their accounts help separate Google’s actual wording from looser summaries circulating around it.

One number needs extra care. Infosecurity Magazine reported that Google found a separate command-and-control server with a production dashboard designed to organise, validate, and manage more than 23,800 harvested secrets (Infosecurity Magazine). Google’s report describes that “Recon” framework in the same broader section on agentic harvesting, but the public material does not establish that all 23,800 secrets came from the unnamed six-hour cloud operation. They belong in the same discussion of direction and scale, not in one combined incident total.

The restrained reading is already serious enough. Criminals used an agent framework during a real intrusion, delegated several repetitive and adaptive tasks to it, and reached thousands of credentials within one working day. We do not need to inflate that into a fully independent cyber operator. The practical problem is automation that can make decisions quickly enough to outrun a human-centred response queue.

The cloud foothold was the launch pad

Picture the compromised cloud resource as a rented workshop whose key has been stolen. The intruder does not have to carry every tool through your front door. They can use your electricity, your workbench, your network address, and whatever identities happen to be stored inside. From the outside, activity may appear to come from a legitimate customer of a familiar cloud provider rather than from an obviously hostile machine.

That is why the first sentence of Google’s incident description deserves as much attention as the words “multi-agent.” The actor had already compromised cloud infrastructure. The AI framework increased the speed and scale of what happened next, but the stolen environment supplied execution, connectivity, and a respectable route onto the internet. SiliconANGLE’s report notes that traffic left from the victim’s addresses. A blocklist built around yesterday’s known attacker systems is a poor answer when the attacker can borrow a clean address today.

Cloud identities make the problem larger. A workload may have permission to read an object store, ask a secrets manager for a credential, start another machine, write to a queue, or call a third-party service. Those permissions are useful because software needs to do real work. They are also authority. Once an attacker controls the workload, the relevant question is not “Which server was hacked?” It is “What could the server’s identity cause, read, create, and pay for?”

Google’s wider report shows why that authority map matters. During the same quarter, investigators saw adversaries steal application-programming-interface credentials, proprietary models, prompts, source code, and AI research. They also saw compromised cloud environments used for unauthorised model workloads. In one separately described April 2026 case, an exposed GitHub token reportedly allowed an attacker to provision expensive graphics-processing machines at the victim’s expense (Google Threat Intelligence Group). Data was only one valuable asset; permission backed by someone else’s account and budget mattered too.

A team that inventories hosts but not identities will miss this shape. The compromised machine is one box on the diagram. Its service account, reachable secret stores, build tokens, allowed internet destinations, spending quota, and access to other projects are the lines leaving the box. Those lines determine the blast radius. An agent can follow them faster, but it does not create them from nothing.

This is the same design problem that appears with legitimate coding agents. The model’s prose may be impressive, cautious, or confused. None of those qualities should decide whether a process can read production credentials or send arbitrary traffic. The durable control sits around the process: a narrow identity, an isolated runtime, a destination policy, a budget, and an audit trail that another system can inspect.

Agents remove the pauses defenders quietly depend on

Many security programmes contain hidden waiting periods. An attacker runs a scan, reviews the results, fixes a broken command, changes infrastructure, and starts again. Defenders may get an alert somewhere in that sequence. A person triages it, finds the service owner, opens a ticket, asks whether the traffic is expected, and eventually receives permission to contain the system. The attacker and defender are both moving through queues.

Agentic automation changes one side of that race. Google’s observed framework could manage a scanning pipeline, troubleshoot failures, and rotate internet addresses without returning to a human after each snag. None of those abilities is science fiction. Together, they remove dead time. A task that would have sat until an operator noticed an error can immediately take another branch.

The defensive lesson is not “buy an AI security product.” A faster detector still loses if its output enters a slow approval chain. Suppose an alert fires 12 minutes after a new cloud workload begins contacting hundreds of unrelated login endpoints. If the on-call analyst cannot identify the owning service account, suspend its outbound access, or revoke its short-lived credentials without three meetings, the detection has documented the incident rather than contained it.

Six hours exposes the difference between alert latency and response latency. Alert latency is the time from suspicious action to a useful signal. Response latency continues through enrichment, ownership, decision, authorisation, and enforced containment. Teams often measure the first number because the monitoring tool supplies it. The attacker experiences the whole chain.

A practical exercise is to place a stopwatch beside one high-confidence cloud alert. Start it when the event happens, not when an analyst opens the case. How long until the signal reaches someone who understands it? How long until that person knows which identity is acting? Can they stop new outbound connections while preserving disks and logs? Can they revoke the relevant credential without taking down five unrelated services? If the answers rely on finding the right colleague during office hours, your real control runs on a human schedule.

This does not justify automatic shutdown for every odd request. False positives have costs, especially in shared production systems. It does justify pre-authorised, bounded containment. A security service might suspend one newly created workload, quarantine one service account, or restrict one process to approved destinations when several strong signals agree. The action should be reversible, logged, and small enough that responders are willing to use it.

NIST’s current incident-response guidance treats preparation, detection, response, and recovery as part of ordinary risk management rather than as a binder opened after a breach (NIST SP 800-61 Revision 3). That framing fits a six-hour campaign. The fastest useful response is the one whose owner, authority, evidence, and safe action were settled before the alert arrived.

Watch the effects, not the personality of the model

It is tempting to defend against agent attacks by looking for agent-like language, familiar model names, or a particular framework. That can help an investigation, but it is a brittle main control. The attacker can change the model, edit the instructions, replace Markdown with another format, or fall back to ordinary scripts. The harmful effects remain much more stable.

A credential-harvesting system has to do observable work. It makes many outbound requests. It touches targets or services that the compromised workload did not normally contact. It may create new compute, fetch tools, read secrets, or produce a burst of authentication events. It needs somewhere to store results. If it rotates source addresses by creating or switching infrastructure, that control-plane activity also leaves records.

Normal behaviour gives those events meaning. A public web service might legitimately serve thousands of customers while having no reason to initiate connections to thousands of unrelated authentication endpoints. A continuous-integration runner might download packages and upload build artefacts, but it should not create graphics-processing clusters or read the customer database. A model-evaluation worker may call one model provider, yet have no business reaching arbitrary internet hosts.

“Anomaly” is too vague to operate on its own. Turn it into enforceable statements. This service account may start machines only in one project. This workload may call these four external domains. This build job may read a signing credential only during the release stage. This agent may spend up to a fixed amount per run. This newly provisioned resource may not create another identity. Each statement gives monitoring a clear violation and containment a limited target.

Outbound controls deserve special attention because the observed framework used the victim’s environment as a route out. Security teams often protect incoming paths carefully and leave outbound access open. The assumption is understandable: a server needs updates and APIs, so allowing the internet is convenient. The result is that code running inside the boundary can scan, call, upload, and change destinations freely.

Start with the sentence “the computer still had a way out.” Then use the technical term: egress control. A useful egress policy restricts destinations, protocols, and sometimes request types according to the workload’s job. It also records denied attempts. A coding agent that needs a package registry and source host should not automatically inherit a route to every address on the internet. A production service that sends mail through one provider does not need to connect directly to arbitrary mail servers.

Address rotation also weakens simplistic rate limits. If each source address receives a generous allowance and the attacker can obtain new addresses, the campaign can spread requests across them. Defenders need limits tied to the identity, account, project, destination class, or business operation, not only to an IP address. The same rule helps with legitimate automation that loops unexpectedly. Good boundaries protect against malicious intent and ordinary software mistakes at the same time.

The model’s “intent” is a distraction at this layer. A safe system does not need to decide whether the process is evil, confused, or merely broken before limiting an impossible effect. If a documentation generator tries to create 200 new machines, the correct first response is refusal. Investigation can decide why afterward.

Credentials turn speed into reach

The campaign’s outcome was measured in credentials because a credential carries authority beyond the machine where it was found. An API key can open a storage bucket, spend money, call a model, publish a package, or impersonate a service. A cookie may preserve an authenticated session. A build token can cross from source code into releases consumed by customers. Each stolen identity offers another branch in the attack graph.

This is why counting secrets is less useful than classifying them. Ten expired test keys may be noise. One current release credential may alter every artefact your customers install. The response order should follow what each identity can do, where it can be used, and whether its activity is visible. Teams need that context before an incident, because collecting it after thousands of values have left is slow.

Long-lived keys are especially forgiving to an attacker. They survive restarts, move easily between machines, and often lack a natural end. Short-lived credentials reduce the useful window, provided the system can also stop new credentials being minted. Revoking one access token while leaving the compromised workload able to request another is containment theatre.

OWASP’s Secrets Management guidance treats creation, rotation, revocation, expiration, and auditing as one lifecycle (OWASP Secrets Management Cheat Sheet). That lifecycle needs an owner. A key with no named service, expiry, expected location, or tested rotation path is an incident-response debt waiting to be collected.

There is a second trap after discovery. Teams rotate the obvious cloud key and declare the incident contained, even though the compromised identity could reach third-party services. The outside credentials in Google’s account belonged to third parties, which means harm crossed organisational lines. Your investigation has to follow access, not ownership. If the workload could read a deployment token, a support platform key, a source-host credential, and a model-provider key, all four belong in scope even when four different teams pay the bills.

Rotation alone may also leave artefacts produced under stolen authority. A compromised build runner might have published a package. A stolen administration token might have created another account. An agent with access to a customer platform might have changed webhook destinations. Revoking the original key closes one door; it does not reverse every action already taken through it.

A useful credential inventory therefore contains more than a secret’s location. Record its issuer, owner, privilege, allowed environments, maximum lifetime, rotation method, logs, downstream artefacts, and emergency revocation path. Add the answer to one awkward question: what can this identity create that would survive its own revocation? That field often reveals persistent access no key scan will show.

Build a response path that fits inside the new clock

You do not need to beat an autonomous framework at every keystroke. You need to stop one compromised workload from turning its local foothold into broad authority. The work is concrete, and much of it improves reliability even if this exact campaign never touches your organisation.

Begin with one exposed or high-value cloud workload rather than a company-wide programme. Choose a continuous-integration runner, agent worker, internet-facing application, or shared automation service. Trace what it can read, call, create, and spend. Then run the response path against a safe simulation with a clock running.

  1. Map the workload’s effective authority. Start from the runtime identity and follow every reachable service, secret, role-assumption path, deployment system, and external API. Include inherited permissions and credentials injected at start-up. The result should fit on one page well enough for an on-call responder to use at 03:00.

  2. Reduce standing permission before tuning alerts. Remove unused roles, split release authority from ordinary builds, and replace long-lived keys where the platform supports short-lived identity. Put expensive compute and new identity creation behind quotas or separate approval. A perfect alert cannot compensate for a workload that can do almost anything.

  3. Give the workload a destination policy. List the internet services it genuinely needs, then block or proxy the rest. Record denied requests with workload identity and destination. If an open route is temporarily unavoidable, assign it an owner and expiry date rather than calling it a permanent exception by accident.

  4. Detect bursts by identity and effect. Watch for unusual fan-out, repeated authentication attempts, rapid resource creation, secret-store reads, new regions, unfamiliar service calls, and spend acceleration. Correlate across changing source addresses. A campaign rotating IPs should still look like one account causing one class of effect.

  5. Pre-authorise a narrow containment action. Decide who may quarantine the workload, disable its service account, block outbound traffic, or freeze new resource creation. Preserve control-plane logs, workload disks, and volatile evidence where practical. The action should stop expansion without erasing the information needed to understand what happened.

  6. Revoke by reach, then inspect persistence. Rotate or revoke every credential the workload could access, including external services, and block the compromised identity from minting replacements. Review accounts, workloads, scheduled jobs, webhooks, packages, releases, and other durable objects it could have created. Notify affected third parties when evidence shows their credentials were exposed.

  7. Prove recovery before restoring autonomy. Rebuild from known inputs when trust in the runtime is gone. Re-enable permissions and destinations in stages. Confirm that the same simulated behaviour now produces a timely alert and a bounded stop. Recovery is complete when the authority path has changed, not when the dashboard turns green.

The stopwatch makes this sequence honest. Measure time to a useful alert, time to identify the acting workload, time to stop new outbound effects, and time to revoke reachable authority. Run the exercise during the coverage conditions you actually have. A 20-minute weekday result and a four-hour overnight result are different security controls.

Do not set a six-hour target merely because the reported campaign lasted less than six hours. The first useful containment may need to happen much earlier. If a workload can attempt thousands of logins per minute, your acceptable window might be measured in minutes. Derive the target from the rate of harmful effects and the authority at stake.

The Secure Harness makes the same argument for coding agents: permission, execution, network access, evidence, and release should meet at one boundary. The goal is to make the next forbidden effect difficult, visible, and stoppable in practice rather than to declare an agent harmless in theory.

What this report does not prove

Good incident response begins with calibrated claims. Google’s report does not establish that every attacker now operates an autonomous multi-agent system. It does not say an AI model independently selected the victim. It does not reveal how the unnamed organisation’s cloud infrastructure was first compromised. It also does not provide enough public detail to reproduce the campaign’s exact timing or assign every harvested secret to a named service.

The report describes several distinct kinds of activity in one broad threat update. One financially motivated actor ran the six-hour harvesting operation. A China-linked espionage group separately tried to design an automated penetration-testing framework with Gemini, but Google says that effort did not progress beyond attempts to build it and that associated assets were disabled. Other sections cover attacks on AI research, model extraction, software-supply-chain compromise, and stolen compute. Combining all of them into one super-attack would be inaccurate.

Even the word “autonomous” needs context. The framework acted without manual intervention for parts of scanning, troubleshooting, and address rotation. Humans still provided the compromised environment, objective, prompt, instructions, and playbooks described in the report. Autonomy is a property of particular steps, not a declaration that people disappeared from the operation.

These limits reduce hype without reducing the engineering consequence. A criminal does not need a general-purpose cyber mind. They need automation that can keep working through small failures while people are absent. Defenders who rely on those small failures to buy time have to replace accidental delay with deliberate boundaries.

There is also no reason to abandon AI coding tools because criminals use them. Ordinary scripting, cloud infrastructure, and open-source software all serve defenders and attackers. The right question is whether a tool operates inside controls that match its possible effects. A useful agent can keep substantial autonomy within a narrow identity, restricted network, capped budget, isolated runtime, and monitored release path.

That position is less dramatic than “AI has changed everything,” and more actionable. Adaptive automation has become cheap and accessible enough to compress a meaningful credential operation into part of a day. The response is to shorten and strengthen the control path around authority.

Six hours should change the rehearsal

A security team cannot count on an attacker stopping for lunch, reading every error, or manually choosing the next address. Google’s September 2026 report gives us a real case in which agents removed those pauses. The campaign still needed a foothold, instructions, compute, network access, and credentials. Those dependencies are the defender’s handles.

Use the six-hour figure as a rehearsal constraint, not a marketing slogan. Pick one powerful workload. Draw its authority and outbound paths. Trigger a safe signal. Watch how long ownership, approval, containment, credential revocation, and recovery really take. The gaps will be more valuable than another argument about whether the framework was truly autonomous.

Speed changes the value of boundaries. A narrow identity limits the first minute and the sixth hour alike. A destination rule blocks both a clever agent and a broken script. A quota turns an open-ended bill into a bounded incident. A tested kill switch gives the on-call person something better than a ticket marked urgent.

The memorable phrase from this incident is “less than six hours.” The durable lesson is simpler: your response clock starts when the machine acts, not when a person notices.

For more security and AI engineering in plain English, join the newsletter. It is one email per month.

Sources