The most unsettling number in cybersecurity right now might be 10 hours.
Not 10 days. Not 10 weeks. 10 hours.
In a recent Unit 42 investigation, researchers responded to an enterprise intrusion where a human threat actor used frontier AI models and attack-specific agentic frameworks to automate large parts of the attack. The result: more than 50 MITRE ATT&CK techniques compressed into less than 10 hours, work that would normally take a human operator roughly two weeks.
The attack didn't stop at getting a foothold. The AI agents mapped the internal environment, searched source repositories, obtained root credentials, triggered unauthorized CI/CD activity, and targeted cloud AI infrastructure.
If you work anywhere near a CI/CD pipeline, a source repo, or a cloud deployment key, that list should sound uncomfortably familiar. This wasn't an attack on some abstract "enterprise network." It moved through the exact systems most engineering teams touch every day.
Attacks Used to Be Sequential. Now They're Parallel.
Defenders have long thought about intrusions as a chain: initial access, discovery, credential access, lateral movement, persistence, exfiltration. The steps were never the hard part for attackers. Time was. Reconnaissance takes time. Finding a usable credential takes time. Understanding an unfamiliar environment takes time.
AI agents change that math. Instead of one operator working through each step by hand, several agents can work through different parts of an environment at once, one testing credentials while another maps cloud resources while a third pokes at a CI/CD pipeline. The attacker stops moving through the kill chain step by step and starts running several branches of it simultaneously.
Picture the difference. A traditional intrusion looks roughly like: compromise, investigate, find credentials, move, repeat. An agentic one looks more like a fan-out: compromise, then in parallel, map the environment, search repositories, test credentials, identify cloud resources, poke at CI/CD, hunt for privileged access — all running at once instead of in sequence.
That parallelism is the real shift, and it's specifically bad news for anything resembling modern software delivery, where a repo, a CI runner, an API token, and a cloud deployment target are all sitting a few hops apart from each other.
The Part of This Story Developers Should Actually Care About
Most write-ups on this kind of intrusion focus on the SOC's problem. But look again at what the agents actually did: searched source repositories, created activity around CI/CD, obtained credentials, and moved into cloud infrastructure. That's not a SOC-only story. That's a software supply chain story.
A few uncomfortable questions worth sitting with if you maintain a pipeline:
How long does a leaked CI/CD token stay valid? If a token doesn't expire quickly and isn't scoped tightly, an agent that finds it has plenty of runway to use it.
Does your CI system log and alert on unexpected pipeline triggers, or would an off-schedule build just blend into normal noise? An automated attacker doesn't need to trigger a deploy at 3 AM to look suspicious if your pipeline runs constantly anyway.
Are your repo access tokens scoped to what they actually need, or does "make it work" access accumulate the same way over-permissioned service accounts do everywhere else? An agent doesn't need a superuser credential if a moderately-permissioned one gets it 80% of the way there.
Would unusual repository access even stand out? A read on a repo nobody usually touches is exactly the kind of low-noise signal that traditional monitoring wasn't built to catch, because it doesn't look like "an attack." It looks like someone browsing code.
None of these are new problems. They're the same access-hygiene questions security teams have been asking about human credentials for years. What's changed is the speed at which something can find and use a weak answer to any one of them.
Why the SOC's Bottleneck Is Now a Race Against Compute
Most SOCs already run into a familiar wall: too many alerts, too many dashboards, too few analysts. Add an automated attacker to that picture and a new asymmetry shows up. A human analyst might spend 20 minutes deciding whether an authentication anomaly matters. In that same 20 minutes, an automated attacker can be testing several other paths in parallel. The defender's bottleneck is human attention. The attacker's bottleneck is increasingly just compute, and compute scales a lot faster than headcount.
That's the actual problem underneath the AI-vs-AI framing people reach for. It's not really "attackers have AI so defenders need AI." It's that a tool watching only endpoint telemetry can't understand an attack moving through identity, cloud, source code, CI/CD, and AI infrastructure in the same hour. Neither can a tool watching only network traffic, or only identity. Each one has a piece of the story. The attacker doesn't care which product owns which alert. It cares about the relationships between systems, so that's what the defense has to see too.
Six Events, Six Alerts, or One Attack
Here's a version of how that plays out. A developer account authenticates from an unusual location. A few minutes later, that same identity accesses a repository it doesn't normally touch. Shortly after, a new API token gets created. Then a CI/CD pipeline kicks off unexpectedly. Not long after that, a cloud workload starts talking to a new external destination. And finally, a privileged account performs an administrative action nobody scheduled.
Looked at individually, that's six alerts, each with a plausible innocent explanation. Looked at together, in that order, in that timeframe, it's one attack. That gap between six isolated alerts and one understood attack is exactly where most SOCs are still losing time.
What an Attack Graph Gives You That an Alert List Doesn't
An alert list tells you something happened, somewhere, at some point. An attack graph asks a different set of questions: who initiated it, which identity was involved, which device was used, what changed afterward, which systems were touched, what credentials appeared, what network connections followed, which cloud resources got accessed, what happened next.
That second model is a lot closer to how these intrusions actually unfold, because attacks are relationships between events, not a pile of isolated ones. This is also why SIEM isn't going away even as the conversation shifts toward AI-driven detection. When an attack moves this fast, historical and cross-domain context is worth more, not less. The problem was never that SIEM collects too little data. It's that collecting data and understanding relationships between events are two different jobs, and most SOC workflows still treat the first one as if it were the second.
Detection Alone Buys You Very Little Time
Here's the part worth sitting with: detecting an event in seconds doesn't help much if it then takes two hours to figure out that the event is connected to five other things. A fast detection followed by a slow investigation is still, functionally, a slow response, and an automated attacker doesn't need much of that gap to keep moving.
That reframes what a security platform actually needs to be good at. Detection is table stakes. The harder, more valuable capability is compressing the distance between an event happening and someone (or something) understanding what it's actually connected to.
This Is the Problem Seceon Is Built Around
I'll be upfront: I work with Seceon, so weigh this accordingly.
What drew me to their approach specifically is that it doesn't try to solve this with a smarter alert. It's built so that an identity anomaly, an endpoint event, a network connection, and a cloud action can be evaluated together instead of separately, because that's the only way a six-alert sequence like the one above gets recognized as one attack instead of six tickets in six different queues. The AI part isn't the interesting bit on its own. What it has access to see, and whether it can connect that across identity, endpoint, network, and cloud, is what actually determines whether it's useful during something moving this fast.
The Analyst's Job Is Changing, Not Disappearing
None of this makes the human analyst less relevant. If anything, it raises the value of good judgment, because the routine work, opening repetitive alerts, manually cross-referencing dashboards, reconstructing an obvious attack chain by hand, is exactly the kind of thing that should get automated away. What shouldn't get automated away is deciding whether a high-confidence containment action is actually the right call, threat hunting for the stuff automation won't catch, and understanding what an incident actually means for the business behind it.
The goal was never to remove the analyst from the loop. It's to remove the waiting around the analyst.
The Real Takeaway
The significance of the Unit 42 investigation isn't just that AI was involved in an attack. It's that AI compressed a workflow that would normally require serious human effort and time into something that fit inside a single work morning. More than 50 techniques. Multiple layers of an enterprise. Credentials, repositories, CI/CD, cloud infrastructure. All inside a dramatically shorter window than defenders have historically had to work with.
That's not really a story about AI being scary. It's a story about the amount of time available for detection and response getting smaller, in systems a lot of engineering teams touch every single day. The attacker doesn't need to be smarter than the SOC. It just needs to be faster, and right now, speed is the thing most security architectures aren't built for.
FAQ
What is an agentic AI attack?
An agentic AI attack is an intrusion where a threat actor uses autonomous or semi-autonomous AI agents to carry out parts of the attack, reconnaissance, credential testing, lateral movement, without manually executing each step. This lets a single human operator run an intrusion at a speed and scale that would normally require a coordinated team.
How did attackers use AI in the Unit 42 investigation?
According to Unit 42's reporting, a human threat actor used frontier AI models and attack-specific agentic frameworks to automate large parts of an enterprise intrusion, compressing over 50 MITRE ATT&CK techniques into under 10 hours, including mapping the environment, searching source repositories, obtaining credentials, and triggering unauthorized CI/CD activity.
Why is CI/CD a target in AI-driven attacks?
CI/CD pipelines typically hold or generate credentials, deployment keys, and access to source code and cloud infrastructure, all in one place. For an automated agent searching for a fast path to privileged access, a pipeline with loosely scoped tokens or under-monitored triggers is a high-value target.
Can traditional SIEM tools detect agentic AI attacks?
SIEM remains useful for centralized, cross-domain visibility, but detecting an agentic attack usually requires correlating identity, endpoint, network, and cloud signals together rather than reviewing them in separate consoles. A SIEM that only stores logs without helping connect those signals across domains will still miss the pattern.
Does AI-driven attack automation mean human analysts become less important?
No. It shifts what analysts spend time on. Routine work like triaging repetitive alerts or manually reconstructing an attack chain becomes a better fit for automation, while human judgment becomes more valuable for validating high-confidence response actions, threat hunting, and understanding business impact.
Top comments (0)