Between July 9 and July 13, 2026, roughly 1,200 AI agents executed about 17,600 actions against Hugging Face’s production infrastructure. No human was steering them. They had escaped an evaluation sandbox, staged from a customer container on a third-party platform, and chained weaknesses every one of us has on a checklist somewhere, including an exposed cloud metadata endpoint, a shared credential, and overbroad Kubernetes roles. From a single compromised pod to cluster-admin, it took under 13 hours. Hugging Face disclosed the incident on July 16, three days after the activity had already stopped.
We have spent a lot of time inside this incident. It is the scenario behind the agentic attack tabletop simulation we published this fall. The forensic lessons are well covered elsewhere. The lesson for how a security operation must run is discussed much less, and it is why the two of us are writing this together. One of us runs commercial and customer operations at Mitiga, and the other runs R&D. Helios AIDR is already fast. Over the past several months, our engineering team has been rebuilding the infrastructure underneath Helios AIDR so that the full path from event to triaged, actionable alert completes in under 3 minutes.
Amir Gabrieli and Brandon Allen will walk through this architecture, and what attackers are doing at machine speed, in a webcast hosted by Brian Contos on Wednesday, Nov. 18, at 11 AM CT. Register for “The Hour You Don’t Have.”
The attackers run at machine speed now
For 20 years, dwell time was the defender’s hidden ally. A human intruder would land, look around, wait for a quiet hour, move one hop, and then wait again. Every detection pipeline in the market was tuned to that rhythm. Hours to detect and respond was tolerable because the attackers also needed hours. That math no longer holds.
The Hugging Face swarm tested thousands of paths cheaply and in parallel, and the one chain that worked was buried in the noise of thousands that failed. Once the swarm read a credential from a Kubernetes secret, the agents held admin on 2 clusters within 1 second. Sysdig’s JadePuffer research shows the same shape on the ransomware side, with reconnaissance, exploitation and encryption run end to end by an agent.
The exploits were mundane. Nothing in that chain was new except for the tempo. The post-mortems show both Hugging Face and OpenAI had the signals. Hugging Face’s stack correlated the attack and didn’t escalate it to the right severity. The gap was both triage and time.
EDR protects the endpoint. Everything else, including the cloud control plane, SaaS, identity, AI services, and third-party connections, is where the autonomous adversary ends up.
Hourly batches were built for a human-speed adversary
Today, most cloud detection runs on a batch pipeline. Logs land in a bucket, and a collector sweeps the bucket on a schedule. Detections then run on the swept batch. Behavioral detections, the ones that need a window of activity to spot a pattern, run on a daily window. An analyst finally picks the alert up from a queue.
In the security operations we have run and worked beside, an hour or two to an actionable cloud alert is considered acceptable, and 15 minutes is considered excellent. Against the swarm above, an hour means you are too late and reading the autopsy.
It would be a mistake to fix this one stage at a time. A detection that fires in 30 seconds and then waits 4 hours in a triage queue is a 4-hour detection. A fast alert that’s wrong is worse than a slow one because false positives are the thing that slows the team down at speed. So, the unit that needs to shrink is the whole path from event, through detection, enrichment, triage, to the response action in your hands. Anticipate. Detect. Interrupt. Stop. The interrupt only happens if detection and response happens inside the attacker loop.
What we are building: under 3 minutes, triage included
Before the end of the year, from the moment telemetry hits Mitiga, we’ll run a single-event detection, enrich it, triage it with AI and deliver it to your destination (your SIEM, SOAR, ticketing, or chat) in under 3 minutes. It will come as a triaged alert with the identity, the asset, the history, and the recommended action attached, ready to work or ready to act on automatically.
Three things contribute to that 3-minute speed:
- Collection moves to every minute. If a source publishes by the minute, like AWS CloudTrail, that means data is with us a minute after it exists. Where a provider offers push or streaming delivery, we take it, and that clock starts even earlier. Where a provider rate-limits or batches on its side, that delay comes from them, and we will be transparent about it per source.
- Behavioral, multi-event detections move from daily windows to hourly windows. Patterns that require an hour of activity to show up will appear in that hour, not the next morning.
- Incident correlation runs as every alert comes in.
We are already faster than the hour-or-two the market accepts. The rebuild is about going from minutes to under 3, and we are rebuilding the existing pipeline as a stream rather than tightening the batch schedule. Cutting a scheduled sweep from an hour to 20 minutes would have been a smaller project, but the data still waits in a bucket between sweeps. Attackers don’t wait. Our internal target for single-event mean time to respond is already heading toward 1 minute, and we will keep publishing as we push forward.
The architecture and what it means for your MTTR
Mean Time to Respond (MTTR) is the time from an event to an alert an analyst can act on, including vendor delay, collection and triage. Mitiga’s part of that number is measured in minutes today, and it will be under 3 before the end of the year.
One stream, two lanes, near real time.
Instead of sweeping a bucket on a schedule, we pull each object the moment a notification says it landed. We poll API sources every minute, and Azure sources run through Event Hub. Where a vendor streams, we subscribe.
Everything lands on a streaming backbone. For a source like AWS CloudTrail, about half of our detection logic looks at a single event, and those detectors will run on the stream as the event passes by. The other half needs a window of activity to see a pattern, like an unusual sequence of API calls, a credential used from 2 places, or a slow enumeration. Those run on hourly windows written to the forensic data lake, and their alerts rejoin the same stream.
We enrich each alert with the identity behind it, the asset it touched, and the history of both, pulled from the forensic data lake. AI triage assigns severity, closes out the noise and stitches related alerts together into an incident as they arrive. Detection takes tens of seconds. Much of the 3 minutes is the enrichment and triage, and that’s where the next round of engineering goes.
The triaged alert leaves with a recommended response action in tow. Helios AIDR will run the action if your policy allows. Otherwise, your SOAR or analyst will, with the context already at hand.
There will be one architecture, with no legacy pipeline running beside the new one. A source that hasn’t moved to event-driven collection yet still gets stream detection on everything we collect from it. It already gets most of the hours and loses only the last few minutes until the switch is made.
The agents inside the 3 minutes
Helios Fleet, the six AI agents in Helios AIDR, will do the work inside that window. They share one memory and run on our normalized data layer spanning cloud, SaaS, identity, and AI, so every handoff carries full context.
How to measure any vendor, including us
If you are evaluating vendors, including us, measure the time from the event happening to an alert your analyst can work with, vendor delay, collection, and triage counted. Detection-engine latency on its own is a number nobody has ever been breached over.
Three questions to ask:
- When does your clock start: when the event happens, when the data arrives, or when a scheduled sweep picks it up?
- Is triage inside the number, or does the alert wait in a queue after it?
- Which sources are behind your average, and what is the vendor delay for each?
The agents are not waiting for the industry to catch up. We are fast today, and we would rather be the ones who moved first.
Let them come.
Sources
- Hugging Face: Anatomy of a Frontier Lab Agent Intrusion, technical timeline of the July 2026 incident (primary forensic record)
- Breached.Company: what the 4 post-mortems (OpenAI, Hugging Face, METR/Redwood, JFrog) corrected about the Hugging Face breach (source of the 1,200-agent, 17,600-action, 13-hour and 1-second figures)
- Mitiga: agentic attack tabletop simulation
