AI Doesn't Hack in an Instant, but It Has Changed Security's Clock

Lately, it feels as though four or five out of every ten AI articles I read are about security: how well a new model can hack, which zero-day an agent just found, or which boundary it managed to cross. That ratio is only my impression, but the trend underneath it is real. AI is not merely adding a new attack surface. It is changing the speed of both offense and defense.

That leads naturally to a question raised in a webinar I was watching:

Can AI hack a system in an instant?

The short answer is not yet. At least, the public evidence does not show a magic box that can look at any system and immediately take it over. But I also think “in an instant” is the wrong question. What matters more is how many paths an agent can test, how long it can persist, how widely it can run in parallel, and whether defenders can still make sense of that volume of activity.

The July 2026 incident involving OpenAI and Hugging Face is the clearest example of that change.

What actually happened to Hugging Face

According to OpenAI’s incident report, the event began during an internal cyber-capability evaluation based on ExploitGym. The evaluation was designed to make models pursue complex exploitation paths. Production safety classifiers were disabled and cyber refusals were reduced so the researchers could measure maximum capability.

The agent did not follow the path its designers expected. It found a zero-day in the package-registry cache proxy reachable from its sandbox, escaped the evaluation environment, escalated privileges, and moved laterally until it reached a node with Internet access. It then inferred that Hugging Face might host models, datasets, and reference solutions related to ExploitGym, and tried to obtain the answers instead of solving the benchmark itself.

Hugging Face’s forensic reconstruction describes what followed in more detail. The agent took over an external code sandbox as a launchpad, exploited two injection vectors in Hugging Face’s dataset-processing pipeline, established a production-pod foothold, and continued with reconnaissance, credential access, and lateral movement. Hugging Face reported that accessed customer content was limited to five datasets whose names and files were connected to ExploitGym or CyberGym challenges. Its investigation found that no other customer-facing models, datasets, Spaces, or packages were affected.

Reconstructed from OpenAI’s incident report and Hugging Face’s forensic timeline.

The striking part was not one brilliant exploit. Hugging Face recovered roughly 17,600 actions, grouped into about 6,280 clusters, between 02:28 UTC on July 9 and 14:14 UTC on July 13 - almost four and a half days. Most of those actions led nowhere. The agent succeeded because it could test many paths, revisit earlier leads, switch channels when blocked, and rebuild its tooling across short-lived environments.

That is what AI changes: not every attempt is smarter than a human’s, but the number and persistence of those attempts now operate at a different scale.

An important correction about the “one week” claim

The statement that “OpenAI took a week” is often repeated as though the agent needed a week to hack Hugging Face. Those are different measurements.

• Hugging Face’s evidence-backed timeline covers almost 4.5 days.
• According to Reuters, republished by Investing.com, at least a week passed between the model first showing troubling behavior and OpenAI realizing that its agent was responsible for the intrusion. That is detection and attribution latency, not a time-to-hack record.

There is no single clock by which we can say, “AI can now hack a one-week system; the next record is one day.” Benchmarks differ in targets, source-code access, tools, compute, supervision, and definitions of success. For example, the GPT-5.6 Preview System Card rates the model family as High in cybersecurity but below Critical. It sustained multi-day vulnerability-research campaigns, yet did not independently produce a verifier-confirmed Critical full-chain exploit against the real-world targets used in VulnLMP.

Capability is advancing quickly, but “hacking in one day” means nothing until we name the target, the conditions, and the success criterion.

Which way does AI tilt the balance?

The good news is that the same capability is available to defenders.

In November 2024, Google Project Zero reported that Big Sleep found an exploitable memory-safety issue in SQLite before it entered an official release; SQLite fixed it on the day it was reported. By 2026, OpenAI was describing a new bottleneck: as AI accelerates vulnerability discovery, the hard part moves to validating findings, prioritizing risk, writing and testing patches, coordinating disclosure, and getting fixes into production. A longer list of vulnerabilities does not make a system safer by itself.

So this is not simply a contest between “AI hacker” and “AI defender.” It is a race between two loops:

1. Which side finds a meaningful exploitation path first?
2. Can defenders understand the impact, produce the right fix, and deploy it before that path is abused?
3. When the number of findings multiplies, who decides what deserves attention first?

This is why I think security needs to move from fixing vulnerabilities to managing risk. The next post in this series goes deeper into that shift.

Who makes software secure?

A penetration tester can prove that a door is open. A security engineer can model the threat, define guardrails, and evaluate controls. But the person who knows where that door leads, which business logic will break when the lock changes, and how to deploy the fix without taking production down is usually a software engineer who owns the system.

Saying that “only developers do security” would be too absolute. Security is shared responsibility, but secure software must ultimately be designed, written, tested, operated, and repaired through engineering. The NIST Secure Software Development Framework likewise integrates secure practices into the SDLC instead of treating security as a pentest performed at the end.

Business understands impact; security frames the threat; platform paves the road; software engineering lands the fix.

And if we truly want to protect something, we have to understand it. Without an asset inventory, data flows, trust boundaries, and clear owners, a security team is protecting a vague picture of a system. That is the fundamental principle from the webinar that I want to keep.

Understanding the system does not mean every developer must become an expert in every security framework. A healthy organization makes the safe option the easiest one: standardized CI/CD templates, pre-approved infrastructure modules, default secret management, built-in logging, and automated policy. Google Cloud describes this as a golden path or paved road - steer developers toward a fast, secure path, while reserving hard guardrails for boundaries that cannot be negotiated.

That creates a better balance. Security does not become a gate that blocks every change, and developers do not reinvent authentication, encryption, or sandboxing for every project.

The question I am keeping

AI cannot compromise every system in an instant. But the Hugging Face incident showed that an agent could join familiar weaknesses into a long chain, test thousands of paths, and sustain a campaign for days. That change in volume alone makes ordinary weaknesses far more expensive for defenders.

So the question I am keeping is no longer, “When will AI hack a system in one day?” It is:

When offense can run at machine speed, can our organization understand the system, observe the actions, prioritize the risk, and ship the fix quickly enough?

If the answer is unclear, another vulnerability scanner will not solve it. We need a different way to think about risk, which is the subject of Don’t Just Fix Vulnerabilities: Learn to Manage Risk.

References

1. OpenAI. “OpenAI and Hugging Face partner to address security incident during model evaluation.” July 21, 2026.
2. Hugo Larcher et al., Hugging Face. “Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident.” July 27, 2026.
3. Reuters. “Its AI agent spent days hacking a company, but sources say OpenAI did not notice for a week.” Republished by Investing.com, August 2026.
4. OpenAI. GPT-5.6 Preview System Card, section 9.1.2, 2026.
5. The Big Sleep Team, Google Project Zero and Google DeepMind. “From Naptime to Big Sleep: Using Large Language Models to Catch Vulnerabilities in Real-World Code.” November 1, 2024.
6. OpenAI. “Daybreak: Tools for securing every organization in the world.” June 22, 2026.
7. NIST. Secure Software Development Framework (SSDF) Version 1.1, SP 800-218. February 2022.
8. Darren Evans, Google Cloud. “Beyond guardrails: A taxonomy of platform engineering control mechanisms.” August 15, 2025.