Two Cloud Breaches Show How AI Is Compressing the Attack Timeline

In July of this year, attackers leveraged AI to run a full-scale attack against a cloud environment. The attack was almost entirely automated. AI chained access across applications, code repositories, deployment pipelines and data stores, stealing secrets, planting backdoors, pulling data and disrupting operations along the way. Work that would normally take a team of attackers weeks took one attacker just three days.

Five months earlier, a February breach in a similar environment showed a previous iteration of the attack style. Once inside, AI handled lateral movement and privilege escalation in under eight minutes.

These attacks are not outliers. Forty percent of organizations say that they’ve been targeted by AI-enhanced external attacks that leveraged automation for reconnaissance, phishing or lateral movement, according to ExtraHop's 2026 Global Threat Landscape Report. In the coming weeks and months, expect that percentage to grow.

What happened in the July 2026 attack

The attacker ran four workflows at the same time, deciding in real time what to scan, build and send out next. Reconnaissance, access, exfiltration and takeover normally run in sequence, with a human working through each stage. Running them in parallel is what compressed the timeline.

How the two breaches compare

The February incident proved narrower in scope than the subsequent July incident. AI effectively went from handling one stage of an attack to running the whole sequence.

Read through the middle row of the table. The lateral movement stage took eight minutes in February. While that stage represents just one piece of a larger attack, at this point, every piece of the chain can operate at that ultra-fast pace. In turn, attacks may be fully executed in as few as three days.

The part most analyses miss

In the July breach, AI didn't make four separate decisions over time. It executed four moves as one continuous sequence, seconds apart.

The four disruption actions are the ones that get quoted — and they are dramatic. Denied S3 access. Container capacity capped at zero. Network access blocked. Data queues purged.

But those actions were the ending, not the attack. By the time an attacker is changing bucket policies and scaling your containers to zero, they already own the environment.

The attack was everything before that — the chaining across applications, repositories, pipelines, and data stores — which is where an attacker is still discoverable, still moving, and still stoppable. That is also the part that doesn’t produce an active alert.

The distinction matters. The four disruption actions are control-plane calls, and by the time they fire, your options are recovery and negotiation. The chaining that got the attacker to that point required movement between systems, and that movement crossed the network, leaving a record that can be observed and reconstructed.

Why the alert queue loses this race

Each of the four actions produced an alert. Each alert was technically correct. An S3 permissions change here. A container scaling event there. A firewall rule update. A queue error.

An analyst works through them one at a time, deciding whether or not each is real, then tries to work out whether any of them are related. That is the pipeline every SOC has run for twenty years. But it was built for threats that moved at human speed.

Every minute spent triaging isolated alerts gives the attack time to reach its next stage. AI-powered attackers depend on that lag.

Defense needs what the attacker had

Keeping up takes more than faster analysts. Defense speed must match offensive speed. However, defensive AI only works if it has what the attacker had: context.

The July attacker did not just move fast. The attacker understood which systems mattered and how they connected, then sequenced the workflows accordingly. A defensive AI without that same understanding is not an agentic SOC. It’s automation layered on top of the same disconnected alerts the old tools already produced. Each one technically correct, each one meaningless on its own.

A human analyst may eventually connect those dots, but an AI-run attack does not leave much room for eventually.

Where that context comes from

This is the question most discussions of the agentic SOC skip.

An agent reasoning over fragmented logs has to constantly rebuild the picture, and even then, it may still be guessing. Worse, logs are what each system chose to report about itself, which means an attacker with sufficient access controls the testimony. Endpoint agents can be disabled. Log sources can be silenced. When those events occur, neither trigger an error, leaving the AI to mistake silence for safety.

The network is different. Network traffic captures ground truth instead of self-reported system logs, and even an attacker with valid credentials cannot move without leaving a trace. It’s the one place where the chaining shows up, in real time, regardless of what the endpoints and the control plane are reporting.

With that foundation, an agentic SOC gains three essential capabilities:

• It can tell you about an S3 lockout, a scale-to-zero and a firewall change that occurred ninety seconds apart and that belong to the same attack, sharing this info immediately, rather than in a post-incident review.
• It can tell you that a normal-looking action from an unusual identity is worth stopping, instead of letting it pass through clean — and at machine speed.
• It can show you which systems would actually hurt the business if disrupted, so response effort goes there instead of wherever the alert queue happens to point.

This is the context layer of the Context, Harness, Model architecture that ExtraHop and fourteen other founding members of the Agentic SOC Alliance are working toward. Context is foundational — no model, no matter how capable, can reason its way out of missing evidence.

Without it, an agentic SOC is fast, just fast at the wrong thing. With it, defense can finally move at the speed of the attack.