AI Agents Cut a Two-Week Breach Down to Ten Hours: Eight Assumptions Collapse

Ben Lorica of Gradient Flow has put together a breakdown of recent attacks involving AI agents, and the numbers are concrete. In one breach, work that human operators would have needed about two weeks to do, by estimate, took less than ten hours. In the Hugging Face incident, investigators managed to reconstruct about 17,600 agent actions carried out over four and a half days. The attackers mostly exploited ordinary weaknesses. What changed was their persistence.

Old holes, a different tempo

The cases described involve neither a new class of vulnerabilities nor clever workarounds of model safeguards. The agents found what has sat in typical infrastructure for years: excessive permissions, long-lived keys, poorly isolated environments. The difference is who is doing the probing.

A human operator gets tired, switches to other tasks, and weighs whether the payoff is worth the effort. An agent does none of that. It tries one option after another, and the cost of each additional attempt approaches zero. Defenses used to count on the fact that chaining small flaws together was too labor-intensive. Now that labor cost has almost vanished. This is our interpretation, but it fits the numbers well: compressing two weeks into ten hours points to the economics of the attack, not to magic.

Numbers from the analysis

• About two weeks of human operator work took less than 10 hours.
• About 17,600 agent actions were reconstructed in the Hugging Face incident.
• Those actions stretched over 4.5 days.
• Lorica lays out eight practical takeaways for security teams.

The scale of the log is also worth noting. You can reconstruct 17,600 steps only if they were recorded and could be linked into a single picture. Apparently, telemetry became not a supporting tool of the investigation but its foundation.

Eight assumptions that stop working

The Habr retelling does not cover every point, but it names the key markers. First: the metric "how long from detection to containment." When an attacker works in hours rather than weeks, this is the window you need to measure. Time to first alert says little on its own if the response takes a day.

Second: protecting the agent's harness. That means everything surrounding the model: tools, permissions, memory, call routing. This is where the agent gains the ability to act, and it is the part that is easy to underestimate when you focus on "model safety."

Third: temporary credentials. A long-lived token in a compromised agent turns into permanent access, while a short-lived one limits the damage by its lifespan alone.

Fourth: a security boundary outside the model. You cannot count on the model to refuse unnecessary actions by itself. Restrictions must be imposed at the level of the network, permissions, and execution environment, that is, where they cannot be talked around or bypassed with a prompt.

For the remaining four takeaways, read Lorica's original.

Where a team should start

The check takes one working day, not a quarter.

1. Measure the real time from detecting an anomaly to isolating the affected system. If it is measured in days, that is your main risk. 2. List all agents and the credentials they use. Find keys with no expiration and replace them with temporary ones. 3. Turn on full logging of agent actions, including tool calls, so that you can reconstruct the chain of steps during an incident. 4. Treat the agent's harness as a production system: reviews, updates, egress traffic restrictions. 5. Move restrictions out of the prompt and into infrastructure: access permissions, network policies, isolated environments.

This does not replace protecting the models themselves. But if two weeks of work can be done in ten hours, the safety margin has to come from response speed and from how little an agent can do, even when someone else is controlling it.