Four things decide whether anyone stops an agentic intrusion. Miss one and the other three no longer matter. We checked ourselves against all four.
In July 2026, an autonomous agent running frontier models with its safety classifiers off spent about five days inside Hugging Face's production infrastructure and ran an intrusion end-to-end with no human directing it. Hugging Face caught it, shut it down, and then surprised everyone. They published a timeline of ~17,600 recovered actions, including a candid account of where their stack fell short.
You can read a detailed timeline backwards, from what the agent did to what a defender would need to interrupt it. So, we built a Hugging Face-style agentic attack, with the same class of intrusion moving across the same control planes, and we ran it against our platform. We mapped each stage and the telemetry, detection, correlation and response it would demand, scored where Mitiga would see it and where it would not, and then checked every assumption in that model against our product.
The whole thing hinges on four things that must go right.
- The data has to arrive in time.
- Something has to fire on the identity that did the work.
- The signals must combine into a single incident within a relevant time window.
- Something has to act.
Mitiga is built for the shape of this attack, which ran almost entirely across cloud, SaaS, and identity control planes. Here's how we scored on all four.
How the attack chained Kubernetes, AWS, and source control
Entry was an application flaw, and that belongs to appsec. The next part is the crux of the attack, and the escalation we modeled follows the shape Hugging Face disclosed.
An agent that reads a service account token out of a pod can reach instance metadata, take the node's cloud credentials, authenticate to the cluster API as the node itself, escalate to node root, and read a cluster secret full of keys. A couple of those keys open everything: a credential bound to cluster admin across multiple clusters and a mesh VPN key that puts the agent on the corporate network and into source control with write access.
The chain crossed Kubernetes, AWS, the internal network, and source control. There was no malware, no human logged in, no endpoint touched, and nothing for the identity provider to flag. A service account crosses those boundaries and the credentials it can reach, and the evidence sits in four separate log sources, each holding a few ordinary-looking lines. The intrusion is the crossing, and a chain that lives in the seams between control planes is invisible to anything that watches one plane at a time. Pulling those planes into one place, so the chain shows up as a single timeline, is what we call Panoramic Awareness.
What's new about agentic attacks, and what isn't
Treating agentic attacks as a new category that requires a new theory is the wrong approach. Hugging Face said plainly that the weaknesses were familiar, including unsafe dataset processing, exposed cloud metadata, overly broad access, and long-lived credentials, and that a capable human could have exploited the same ones.
One thing is new, and it isn't a technique. Nobody planned this campaign. No operator picked the targets or chose the escalation path or decided to keep going on day three. It emerged from an autonomous system that was pursuing a goal. This isn’t going to stop here. It’s not going back in the box. Every organization now putting agents into production, with production credentials, is expanding the exact surface this campaign exercised.
Everything the agent did inside has an ordinary name, with actions like metadata theft, service discovery, permission enumeration, container escape, and valid account abuse. The scale changed, and it goes in two directions.
Speed, correctly understood
People hear "agentic" as instantaneous. It wasn't. It took about five days total. The decisive stretch, from first in-cluster recon to cluster admin across clusters, took about thirteen hours, which is within the window that mature teams already aim for. And it won't compress as much as the hype implies, because the agent didn't spend those hours learning how to attack Kubernetes. It spent them learning this environment. It learned which service account held which binding, where the secrets were stored, and which path was live. That work is per target and specific to you. Better models just waste fewer attempts. The agent still has to ask your control plane, and the answers are yours alone.
Less room for luck
A lot of real-world detection is partly luck. The right analyst takes the right shift, ending up just where they need to be at the right time. Or a hunt was already scheduled that week – very lucky. Maybe a rule update landed mid-campaign, or the attacker slips up just so. Luck needs time. A long campaign leaves room for it, and a compressed one doesn't. When the clock shrinks, the accidental catches stop happening, and your engineered detection has to carry the whole load. The goal for good programs was always to catch an intrusion inside a shift. What changed is that you can no longer treat it as aspirational.
Four things that decide whether an agentic attack gets stopped
1. The data must arrive while it still matters
Against a chain that reaches cluster admin in hours, a log source on a daily batch cycle delivers history, not evidence. This is an industry-wide blind spot. Cloud audit can be near real time, but managed Kubernetes audit and anything polled or batched often isn't, and most stacks tolerate that latency because their threat model never assumed an adversary moving at such speed. It's also the one pillar where AI offers no advantage, because no model can make a log arrive sooner. It's collection engineering, and it's ours to win. Near-real-time collection across every decisive source is our top platform priority, in flight now, because latency is the difference between stopping a chain and reading about it later. The bar is minutes, not a daily cycle, and you should hold every vendor to it.
2. Something must fire on the identity that did the work
Every step in that chain was a legitimate capability, used by a workload that was supposed to have it. The industry spent ten years developing detection engineering focused on people, with signals like impossible travel, new device, sign-in risk, and privilege escalation on named users. Few of those fire on a data-processing service account doing something it has never done before.
The coverage exists but was scoped wrong, and it misses this case. A rule that excludes every system principal is a sensible noise-reduction choice, right up until the attack lands on a workload identity. A threshold tuned for bulk doesn't fire on precision. The detection exists, sits in the coverage matrix, and contributes nothing. And a human red-teamer might never discover the exact boundary where a rule stops firing, but an agent enumerating exhaustively will because it tries everything. Scoping errors that were theoretical are now reachable through brute force.
We went searching for these patterns in our library during this exercise, and we found some. That work is underway, and it points out that the industry's real under-investment is verifying that each detection still fires on the behavior it names after the schema underneath it changes. That doesn't scale by hand, so this stage is where machine assistance earns its place in detection, with continuous verification of the library.
3. The signals have to compose in a window that matters
This is the center of the problem, and Hugging Face is the proof. Their signals came from several layers at once, each individually ambiguous. Their correlation stack resolved them into a coherent attack – the genuinely hard part – and then it failed to raise the criticality or reach the on-call team. When the composition works while the judgment about what it meant doesn’t, you can’t fix that by adding rules.
So let’s be precise about two jobs the industry sells as one.
- Correlation assembles many events into a few candidates. It's a volume problem, cheap and recall-biased, because anything it misses is invisible downstream.
- Triage decides what a candidate is and whether to wake someone. It's a judgment problem, and it's expensive per item.
Most "AI for the SOC" does one and claims to do both. Correlation without triage that works produces coherent incidents that no one prioritizes correctly. That's what happened at Hugging Face. Triage without correlation is an expensive model staring at single alerts with no idea they're the same story.
Mitiga is deliberately built as two tiers, and the unit that gets worked is the incident over the alert. Panoramic Awareness feeds the first tier: signals assembled into one object instead of a queue of fragments. AI Triage is the second with the graded judgment that decides this object is critical and someone must move now. That second tier is the step Hugging Face's stack got wrong.
Service accounts are the right population to bet on, and the difference is stark. Human behavior is wide, irregular, and drifting, so user baselining disappoints. A service account performs the same small set of tasks a million times, without variation. A conversion worker does not enumerate its permissions, query cluster metadata, or authenticate as the node it runs on. Not rarely – never. The signal is novelty, amplified by density. One new behavior is usually a deploy. Five in twenty minutes with no deploy is an attack. We're strong here, and we're candid about the edge we're sharpening, making that incident object form over short windows, for identities that aren't people, fast enough to feed the criticality call.
4. Something has to act
The first three produce a conclusion. Something still has to change the outcome, the least-solved pillar in the industry, for reasons that aren't technical.
Our role is specific, and we're clear about it: Mitiga decides what is worth acting on, how to act based on the conclusion, what the action is, and what that action would cost. The acting itself belongs to the response layer a modern SOC already runs, orchestration and agentic SOC tooling included.
That isn't a hedge. It's the correct architecture. The system that decides whether and how to act and the system that executes should be separate, and ours is the one that makes that decision.
At machine speed, some containment has to be autonomous, and organizations are going to have to accept that. Speed isn't the reason, since thirteen hours is plenty of time to wake someone. The reason is that the human path has five serial steps, and each fails. Detection fires, gets scored correctly, and pages someone. Then that person forms a view, and someone with authority approves. Hugging Face didn't fail because a human was slow. They failed at step two. Every handoff is a place where an intrusion becomes a postmortem, and you cannot staff your way out of a step that never happens.
The catch is that autonomous response on production workloads is genuinely dangerous. That’s why teams buy it, configure it, and leave it in report-only mode. A bound service-account token lives and dies with its pod, so revoking it means deleting the pod, and if the entry was an app flaw, the replacement pod comes back compromised. You can't challenge a service account or force it to re-authenticate. You can only kill it, restrict it, or watch it.
So, decide by consequence and reversibility, not speed. Resetting a user's credential is a narrow, recoverable action, so there's no reason for a human to be in that loop. Scaling a production deployment to zero is neither narrow nor recoverable, and pre-authorizing it isn't a decision that security makes alone. Most actions fall somewhere in between, and you need to sort them before an incident, not during one. The organizations that contain this class of attack will be the ones that decide now what can happen automatically and approve it in advance. This ask may be uncomfortable, but it’s no longer optional.
Where that leaves us
This attack ran across cloud, SaaS and identity in a single chain. The only thing that was ever going to catch it was something watching all of them together, over a window short enough to matter, on identities that don't behave like people. That's runtime security for modern infrastructure and Panoramic Awareness feeding AI Triage – and it's the problem Mitiga was built for, long before agents made it urgent. Nobody is sitting at four out of four today, us included, and anyone who tells you otherwise is selling.
We'll take the next published intrusion and do the same again, modelling it against our platform, verifying the model against the product, fixing what the gap exposes, and publishing what we find.
That's the standard we're holding ourselves to, and it’s the one the moment demands.
Let them come.
Our thanks to the Hugging Face security team. This analysis is only possible because of what they published in detail.
Frequently asked questions
What happened in the Hugging Face agentic attack?
In July 2026, an autonomous AI agent ran an intrusion inside Hugging Face's production infrastructure with no human directing it. Hugging Face detected it, shut it down, and published a technical timeline reconstructing about 17,600 attacker actions.
How fast did the agent move?
The campaign ran for about five days. The decisive stretch, from first in-cluster reconnaissance to cluster admin across clusters, took about thirteen hours.
What makes an attack agentic?
No person plans it. An autonomous system pursuing a goal picks the targets and the escalation path. The techniques themselves, like metadata theft, permission enumeration, and container escape, are familiar.
How do you detect an agentic attack on a service account?
Look for novelty in non-human identities, weighted by density. One new behavior from a service account is usually a deploy. Five in twenty minutes with no deploy is an attack.