Back to Blog
Cybersecurity

AI Agents Breached an Entire Network in Under Ten Hours, and Never Touched a Zero-Day

Origami TeamEditorial Team
7 min read
AI Agents Breached an Entire Network in Under Ten Hours, and Never Touched a Zero-Day
Like what we publish? Pin Origami as a preferred source on Google.Add as a preferred source on Google

AI Agents Breached an Entire Network in Under Ten Hours, and Never Touched a Zero-Day

On September 2, 2026, Palo Alto Networks Unit 42 published the details of an investigation into an enterprise network breach. The number that carried the report: the attacker started at a publicly accessible web service and finished with root-level access across the entire environment in under ten hours, work that takes a human team roughly two weeks.

The detail that matters more is what was not involved. No zero-day. No rare tradecraft. The intrusion used more than 50 techniques already catalogued in the MITRE ATT&CK framework, meaning documented, published techniques that defenders know. What changed was not the method but the tempo. Instead of running each stage by hand, the operator directed AI agents that monitored, evaluated, acted and re-planned in a single unbroken loop that never paused and never slept.

What happened inside those ten hours

The sequence as the report describes it:

  1. Entry. A publicly accessible web service was breached, then tunnelled into the internal network.
  2. Reconnaissance. An automated agent mapped the internal microservices with no human involvement.
  3. Secrets harvesting. Sub-agents combed the code repositories for access tokens and service passwords written directly into the code.
  4. Escalation. Those tokens opened the secrets management system, which yielded master administrative credentials granting root across the environment.
  5. The pipelines. Build and deploy pipelines were hijacked through custom workflows to exfiltrate cloud access keys.
  6. The inversion. Those keys were used to turn the victim's own AI endpoints into post-compromise infrastructure for the attacker.

Read that last step again. The company's own AI subscription became a tool in the hands of whoever broke in, running on its account and on its invoice. That is a new pattern worth adding to your risk register: every API key for an AI model is simultaneously an operational asset and a spending line.

The number that concerns you is not ten hours

Ten hours is a striking figure, but it comes from a single incident. The number that should actually change your planning appears in the CrowdStrike 2026 Global Threat Report, which measures breakout time: the gap between an attacker's first access and the moment they begin moving toward other systems inside the network.

  • Average eCrime breakout time has fallen to 29 minutes, a 65% increase in speed year over year.
  • Fastest case on record: 27 seconds.
  • An 89% increase in attacks attributed to AI-enabled adversaries.
  • 82% of detections in 2025 were malware-free, meaning the attacker logs in with valid credentials rather than planting a virus.
  • A 266% increase in cloud-conscious intrusions by state-nexus actors.

What 29 minutes means in practice: a response plan that assumes someone notices the alert in the morning and the team convenes after lunch is a plan for an era that has ended. And the 82% figure says something harsher still. Your antivirus does not see the attack because the attack carries nothing for it to see. A modern breach is not a malicious file arriving, it is a legitimate account being used wrongly.

Why it worked: secrets written into the code

The agents broke no encryption and invented no vulnerability. They found passwords written where passwords should never be, inside the project files. One valid token opened the secrets manager, and the secrets manager opened everything.

This is not a problem reserved for large enterprises. Run this list against your own projects:

  • Payment gateway or messaging service keys sitting in a config file committed alongside the code.
  • A database password inside an old deployment script nobody opens.
  • Access tokens for a staff member or outside developer who left a year ago, still valid.
  • A repository that was private and became public after a migration or an account change.
  • A backup copy of a config file on somebody's laptop.

The difference between an agent and a human attacker here is not intelligence but patience and throughput. The agent reads the whole repository, every branch and every old revision in the history, misses no file, and finishes in minutes. Any secret you committed once and deleted later still lives in the repository history, and that history is exactly where it looks.

What to do this week

Five steps. The first needs no budget and no outside vendor:

  1. Scan your repositories for secrets. Secret-scanning tooling is available and built into the major code platforms. Run it against the full history, not just the current revision.
  2. Make key rotation routine, not an emergency measure. A key that has not changed in two years is a leaked key you have not discovered yet. And when you rotate after a leak, rotate it everywhere it was used, not in one place.
  3. Prepare a single revocation playbook. This is Unit 42's direct recommendation: be able to execute synchronized containment that revokes credentials, OAuth sessions, CI/CD pipelines and cloud accounts together. Revoke only half and you hand the attacker time to re-enter through the other half.
  4. Govern AI as core infrastructure. Keep an inventory of every model and key in use, set rate limits, apply least privilege, and turn on diagnostic logging. The report recommends this explicitly, and it is what turns the incident above from a silent disaster into an early warning.
  5. Require multi-party code review and branch protection. Especially on infrastructure-as-code repositories, since that is the door through which a one-line change plants a backdoor. Alongside it, watch behaviour rather than signatures: bursty API requests and rapid state shifts are the fingerprint of an automated agent.

In the Saudi context these steps are not optional good practice. The National Cybersecurity Authority's Essential Cybersecurity Controls include explicit domains for identity and access management and for change and development security, and responsibility for protecting personal data rests with the organisation under the Personal Data Protection Law. A breach that started with a key written into source code does nothing to reduce that responsibility.

The Origami view

We read this incident as the end of one idea: that security is a set of tools you purchase. The attacker here never faced down a firewall and never bypassed an antivirus, because neither was in the way. They entered with a valid key they found written down, and acted with permissions that had genuinely been granted. No product you buy fixes that. What fixes it is discipline in how code is written, how secrets are stored, and how permissions are granted and withdrawn.

One pattern we see repeatedly with clients: the most dangerous secrets are rarely in the main system. They are in the side projects, a data migration script written once, an internal reporting dashboard a contractor built, a temporary supplier integration that has been running for two years. These never enter a security review because nobody counts them as a system. The attacker draws no such distinction. When we review a client environment we start exactly here: where the keys are, who holds which permission, and what happens if one key leaks tonight. If you want a review from that angle, you will find us on the contact page.

Conclusion

The method of attack did not change. Its speed did. More than 50 known techniques ran in under ten hours because automated agents ran them without pause, and average breakout time inside the network is now 29 minutes. A defence that depends on somebody noticing in time is no longer enough. Start with the simplest and hardest question: do you know where your keys are right now, and who can read them?

Sources

#Cybersecurity#Artificial Intelligence#Access Management#Data Protection#Software Development

Frequently asked questions

Did this attack rely on a new, unknown vulnerability?+

No. The Unit 42 report states explicitly that the intrusion did not depend on a zero-day or unusually sophisticated tradecraft, but on more than 50 techniques already catalogued in the MITRE ATT&CK framework. The speed came from the operational efficiency of running AI agents in a continuous loop, not from any technical advantage in the techniques themselves.

How did the attacker reach root access so quickly?+

After breaching a publicly accessible web service, sub-agents combed the code repositories and found access tokens and service passwords written into the code. Those tokens were used to enter the secrets management system, which yielded master administrative credentials granting root-level access across the whole environment.

What is the first practical step for a small or mid-sized company?+

Scan your code repositories for secrets committed inside them, across the full repository history rather than just the current revision, because a deleted secret remains in the log. Secret-scanning tooling is built into the major code platforms and needs no budget. After that, rotate any key that has not changed in a long time.

Are antivirus software and a firewall enough?+

Not on their own. The CrowdStrike report found that 82% of detections in 2025 were malware-free, meaning the attacker enters with valid credentials and plants no file for traditional tooling to detect. Effective protection here comes from access management, key rotation, and monitoring for unusual behaviour.

Follow Origami in Google

Pin Origami as a preferred source and our articles will surface first for you in Google Search and Top Stories.

Add as a preferred source on Google

Related articles

Have a project in mind?

We build custom systems, apps and websites for your business. Tell us your idea and we will give you a straight answer on it.

One session. Twenty minutes. No commitments.