Unit 42 just published a real incident report: a human attacker used frontier AI models and purpose-built agentic frameworks to compress roughly two weeks of methodical intrusion work into under 10 hours. No zero-day. No exotic exploit. Just AI doing, at machine speed, exactly what attackers have always done by hand.
Unit 42, Palo Alto Networks' threat intelligence and incident response team, responded to a real ransomware case in which the human attacker openly told negotiators they had used frontier AI models and attack-specific agentic frameworks to carry out the intrusion. The agents didn't just assist with one step — they handled reconnaissance, exploitation, lateral movement, and exfiltration across the full chain, monitoring results and adapting their next move in something close to real time.
The scale is what makes this worth taking seriously: work that would typically demand a coordinated, multi-week effort from several skilled human operators was compressed into under 10 hours, spanning more than 50 separate MITRE ATT&CK techniques. And in a detail that's almost theatrical, the attacker had their AI agents compile an 80-page technical security audit of the victim's own environment and leave it behind — a genuinely thorough accounting of exactly how the network had been broken into.
Nothing about this attack required a novel exploit or elite tradecraft. Every individual technique — breaching a public API, harvesting hardcoded secrets, abusing a secrets manager, hijacking a CI/CD pipeline — has been a known, documented attack pattern for years. What changed wasn't the attacker's sophistication. It was their speed and their ability to run many coordinated steps in parallel without getting tired, distracted, or slowed down by manual work between stages.
The attacker got in through a public-facing API endpoint — a classic, well-documented entry point, not a novel one. From there, an automated reconnaissance agent mapped the internal microservice architecture largely on its own. This is the stage where AI's speed advantage first shows up: a human operator doing careful manual reconnaissance takes real time to avoid tripping alarms; an agent iterating through the same process can move dramatically faster while still following a broadly similar approach.
Sub-agents swept through the organization's own code repositories specifically looking for hardcoded tokens and service passwords — the single most common, most preventable class of credential exposure in modern software development. Nothing about this step needed AI to be technically possible; it needed AI to be done exhaustively, across every repository, without a human getting bored partway through.
Using the tokens harvested in the previous stage, the attacker reached the organization's secrets management system directly and extracted administrative credentials — effectively seizing root-level control. This is the stage where the earlier, seemingly minor failure (a hardcoded token somewhere in a repo) compounds into full infrastructure compromise.
With elevated access, the attacker hijacked the organization's CI/CD tooling through custom workflows to exfiltrate cloud access keys, and attempted to plant a persistent backdoor directly inside the Terraform infrastructure-as-code configuration. This is also the one place in the entire chain where a conventional, non-AI-specific control genuinely held: hard branch-protection rules blocked the backdoor attempt outright. It's worth sitting with that — the strongest defense in this whole incident wasn't anything AI-aware at all.
In the final stage, the attacker used the stolen cloud keys to seize the victim's own AI compute endpoints and repurpose them as infrastructure for the attack itself — turning the target's own AI investment against them, and quietly shifting the financial cost of running the attack onto the victim's own cloud bill.
Unit 42's investigators identified concrete, observable signs that AI orchestration was behind the operation: parallel calls to multiple frontier AI models, structured Markdown files used to pass state and instructions between agent sessions, and custom scripts with tells consistent with AI-generated code — including leftover UI elements that a human developer building the same tooling by hand almost certainly wouldn't have included. These are genuinely useful, concrete detection signals for defenders to actually watch for, not abstract theory.
It would be easy, and dishonest, to read a headline like "AI-orchestrated ransomware attack" and conclude that only AI-specific security tooling could have prevented it. The real breakdown is more useful, and more humbling:
| Stage | What actually would have helped | AI-specific, or conventional? |
|---|---|---|
| 1. Infiltration & mapping | Patching/hardening the exposed public API, network segmentation | Conventional — application & network security |
| 2. Secrets harvesting | Automated secrets scanning in CI, eliminating hardcoded credentials entirely | Conventional — DevSecOps hygiene |
| 3. Privilege takeover | Least privilege on the secrets manager itself, short-lived credentials | Conventional — IAM/PAM |
| 4. Pipeline exploitation | Branch protection, mandatory multi-party review — and this is exactly what worked here | Conventional — DevOps pipeline security |
| 5. AI infrastructure hijacking | Runtime behavioral monitoring of AI endpoint usage, anomalous-identity detection | AI-specific — runtime governance |
Four of five stages are squarely conventional security failures that predate agentic AI by decades — a public API, a hardcoded secret, an over-privileged secrets manager, an under-protected pipeline. An AI red-teaming tool, including HexTyx's own scanner, is built to answer a different question: can your own deployed AI agent be manipulated into misusing its legitimate access. That's not what happened in stages one through four of this incident at all — the attacker's AI was the offense, not the target's AI being tricked into cooperating.
Stage five is the genuine exception, and it's worth naming honestly rather than glossing over: the moment stolen credentials were used to invoke the victim's own AI compute as post-compromise infrastructure, that's precisely the kind of anomaly AI runtime governance is designed to catch — a sudden, unusual pattern of AI endpoint usage from an unexpected identity or context, the same "is this action consistent with what this agent was supposed to do right now" question that sits at the center of runtime authorization generally. Whether that detection actually happens depends entirely on whether an organization is monitoring its AI infrastructure with that level of behavioral scrutiny in the first place — most organizations, at this point, simply aren't.
Overclaiming that an AI security scanner would have stopped a CI/CD pipeline hijack isn't good positioning — it's dishonest. The real lesson is narrower, and more useful: AI-specific defenses matter most exactly where AI-specific attack surface exists, and nowhere else.
Staying inside that same honest boundary: here's concretely what a layered AI security architecture — pre-deployment scanning plus a runtime governance layer, what we call a runtime immune system — would need to do to catch stage five specifically, and only stage five.
Before deployment, a scanner like HexTyx's own would be testing a genuinely different question than this incident raises — whether an organization's AI agents can be manipulated by a malicious user or document into misusing their own legitimate access. That's real, valuable coverage for prompt injection and tool abuse, but it's not the mechanism at work in stage five, where the attacker never touched the AI's reasoning at all. They walked in the front door with a stolen key.
At runtime is where the actual relevant coverage lives, and it comes down to one specific, checkable question, asked continuously rather than once: is this identity, making this call, from this context, at this volume, consistent with what it's actually authorized to do right now? A gateway like Aegis sitting in front of an organization's AI endpoints would be watching exactly that combination — identity, context, intent, destination, and behavior together — not any single signal in isolation. The stolen-key pattern in this incident has a specific, catchable shape: a service identity suddenly invoking models from an unfamiliar context, at a volume or cadence that doesn't match its established baseline, doing something no legitimate workflow for that identity has ever done before. None of that requires understanding what the AI itself is "thinking" — it's the same kind of behavioral-anomaly detection that would flag a compromised human account suddenly downloading an entire database at 3am, applied to a non-human identity instead.
The honest caveat still applies in full: this only works if that layer is actually deployed and actively watching the specific endpoints the attacker reached, before the attack happens — not something retrofitted afterward. A runtime immune system doesn't prevent the initial breach in stages one through four at all. Its job starts exactly where conventional perimeter and pipeline defenses end: the moment a compromised credential tries to use AI infrastructure in a way that doesn't match its real, established pattern of use.
Every stage of this attack exploited a failure that conventional security practice has warned about for years — exposed APIs, hardcoded secrets, over-privileged service accounts, weak pipeline controls. AI didn't create new categories of weakness here. It made the cost of neglecting old ones arrive in hours instead of weeks. An organization with genuinely good hygiene across those fundamentals would have been substantially harder to compress into a 10-hour timeline, AI attacker or not.
A response plan built around human-speed detection and human-speed containment is increasingly mismatched against an attacker who doesn't need to sleep, doesn't get bored during repetitive reconnaissance, and can run dozens of parallel probes simultaneously. Automated, pre-authorized containment playbooks — the ability to revoke credentials, kill sessions, and freeze pipelines automatically the moment specific behavioral thresholds are crossed — matter more now than a purely human-reviewed incident response process ever did.
Structured Markdown passed between sessions, custom scripts with characteristics that don't match typical human authorship, and coordinated parallel activity across otherwise-unrelated systems are all concrete, observable signals — not abstract risk categories. Security teams that know to look for these specific patterns have a real, current advantage over ones that don't yet know what AI-orchestrated activity actually looks like in their own logs.
The final stage of this incident is the one every organization deploying AI at any scale should sit with directly: your own AI compute and API access can become the attacker's infrastructure, running at your expense, hiding inside traffic that otherwise looks legitimate. Treating AI endpoints, service accounts, and API keys with the same governance rigor as any other privileged identity — least privilege, short-lived credentials, real behavioral monitoring — isn't optional hardening anymore. It's the one part of this specific incident that genuinely falls inside AI-specific security's job description.
This incident is really two stories happening at once. The first is an old, familiar one: an organization with a public API, some hardcoded secrets, and an over-privileged secrets manager got breached, the way organizations with those exact weaknesses have been getting breached for a decade. The second is genuinely new: the attacker didn't just automate one step, they ran an entire adaptive, multi-stage operation with AI making real-time decisions at every stage — closer in shape to agentic AI security concerns than to traditional malware. Both stories are true simultaneously, and an organization that only prepares for one of them is still exposed to the other.
AI didn't invent a new way to breach this network. It just did the old way faster than any human team could.
That's simultaneously reassuring and genuinely alarming. Reassuring, because it means the defenses that have always mattered — patched public services, no hardcoded secrets, least-privilege identities, real branch protection — still work, and still matter more than any AI-specific control on their own. Alarming, because the margin for error just got dramatically smaller. A gap that used to give a defender two weeks to notice and respond now gives them ten hours, and the next version of this attack will likely be faster still.
The honest response isn't panic, and it isn't rushing to buy an AI-specific tool for a problem that conventional security hygiene already solves. It's making sure the fundamentals are genuinely solid — and treating an organization's own AI infrastructure as the privileged, monitored asset it now actually is.
Test whether your deployed AI agents can be manipulated — and whether anomalous use of your own AI endpoints would actually get caught.