AI-Speed Attacks Are Forcing a Rethink of Incident Response

Byline: Nikola Petrovic

Accelerating Attacks. Our Detection Processes Are Still Running on Human Time.

In one of my previous roles, I regularly dealt with incident reports. Most of them arrived ex post. An incident happened, the immediate issue was handled, and a report followed afterwards explaining what went wrong, what the impact was and what needed to change. Unless it was a critical incident requiring an immediate hotfix, this approach was generally considered acceptable.

And to be fair, it worked.

Teams had enough time to investigate. Security could collect evidence. Engineering could reproduce the issue. Management could review the impact. Everyone came together to discuss the root cause and define the follow-up actions and lessons learned.

But I am increasingly wondering whether this model still will work for the AI economy. My instinct is telling me no.

Not because incident reporting itself is wrong. We absolutely need documentation, root-cause analysis and accountability.

The problem is speed.

Attackers can now discover weaknesses, test different approaches and adapt their tactics much faster than before.

Meanwhile, many enterprise detection and response processes still depend on alerts being reviewed manually, context being collected across different systems and several people agreeing that the situation is serious enough to act.

The attack is accelerating. The response process often is not. 

The real problem probably is the detection lag

When people talk about incident response, they often focus on containment and recovery.

How quickly can we isolate the affected machine? How quickly can we patch the vulnerability and how fast can we restore the service (most important one)?

But before any of that happens, someone first needs to understand that there is an actual incident. This is where I see one of the biggest risks: detection lag.

Detection lag is not only the period between an attacker entering a system and an alert being generated. The alert might already be there, whichs is fine, but…

The bigger delay can happen afterwards:

1. An alert enters the queue.
2. Someone reviews it.
3. The analyst tries to understand whether it is a false positive.
4. More logs are requested.
5. Another team is contacted.
6. The activity is escalated.
7. Someone asks whether containment could affect production.
8. Approval is requested.
9. Only then does the organisation act.

Every individual step might be reasonable. Together, they can create a dangerous delay. And they actually do delay.

In the past, that delay may have given an attacker several hours to work. Today, even a few minutes can matter, if not seconds.

A wake-up call for defenders

A recent example made this very tangible for me.

Anthropic reported that its Mythos Preview system had identified thousands of high-severity vulnerabilities in foundational open-source software, including software used across major operating systems and browsers. One analysis referenced an estimated 6,202 high- or critical-severity findings, while only a small portion had reportedly been addressed at that point. the important point is not whether every finding becomes a real-world exploit.

The important point is that vulnerability discovery itself is being industrialised.

Software that has existed for years, has been reviewed repeatedly and is considered reliable can now be examined again at a completely different speed and scale. We are speaking about thousands of issues detected.

The same capabilities can support defenders. That is the good part.

But we also need to assume that these capabilities will become more widely available and will not remain exclusively in the hands of responsible security researchers.

“Stable” software does not automatically mean safe software.

“Widely used” does not mean nobody will find another weakness.

And “we patched similar issues before” does not mean the next issue will give us the same amount of time to react.

That is the wake-up call. Time changed, the entire infrastructure changed, and is actually being changed.

More alerts are not the answer

The obvious response would be to increase monitoring. Add more tools. Add more rules. Collect more logs. Generate more alerts. I am not convinced this solves the problem.

Many security teams already have enough alerts. In some cases, they have far too many.

The issue is not always that suspicious activity was invisible. The issue is that the signal was buried among hundreds of other signals or lacked enough context for someone to act confidently.

A login from a new location may not be critical. A large download may not be critical. A newly created access token may not be critical. But when these events happen together, within a short period, around the same identity (another big gap to be closed with AI Agents), the picture changes completely.

Attackers do not operate as isolated alerts. They operate through sequences. Our detection needs to understand sequences as well. 

We cannot wait for complete certainty 

Enterprise security teams are understandably careful about automated action.

Locking an account, disabling a service or isolating a production machine can cause real business damage. Nobody wants the security system to create the outage it was supposed to prevent.

Because of that, organisations often wait until they have strong evidence before taking action. That makes sense when the attacker is moving slowly. It becomes dangerous when the attacker is moving at machine speed.

I do not believe the answer is to automate every security decision. That would create a different set of problems. But I do think we need to stop treating response as a binary choice between doing nothing and shutting everything down. There should be several steps in between.

For example, when an identity starts behaving suspiciously, the organisation could:

• Require the user to authenticate again.
• Revoke newly created sessions or tokens.
• Temporarily restrict access to highly sensitive systems.
• Block unusually large data transfers.
• Pause high-risk administrative actions.
• Ask for human approval before the next critical step.
• These are not necessarily full containment actions.

They are ways to slow the attacker down while the investigation continues.

That may become one of the most important defensive concepts: do not wait until you understand everything. Create friction as soon as the risk becomes meaningful.

What can defenders do tactically?

I have been thinking about what organisations can do now without starting another two-year security-transformation programme.

A few actions seem practical.

1. Measure the time to understand

Many teams measure when an alert was created and when an incident was closed. That is not enough.

We should also measure how long it took before somebody understood:

• Which identity was affected.
• What systems were accessed.
• What data was potentially exposed.
• Whether the activity was still ongoing.
• An alert that appears in ten seconds but requires three hours of manual investigation is not fast detection.

It is fast notification followed by slow understanding.

2. Pre-approve low-impact defensive actions

During an active incident, valuable time is often lost deciding who has the authority to do what.

Organisations should define in advance which actions security teams may take without executive approval. Requiring reauthentication is different from shutting down a production environment. Revoking a suspicious session is different from disabling an entire customer-facing system.

The lower-impact actions should not become stuck in the same approval process as the most disruptive ones.

3. Build detection around identities and behaviour chains

Most attacks eventually touch identity.

A user account, administrator credential, service account, API token or machine identity is used to access something valuable. Instead of only examining separate events, defenders should connect activity around the identity:

• What changed?
• What did the identity access next?
• Was a new credential created?
• Did the access pattern suddenly change?
• Was sensitive data downloaded?
• Did the identity attempt to weaken a control?

This can reveal the attack before every individual event becomes severe enough to trigger a critical alert.

4. Automate evidence collection before automating decisions

Many organisations are not yet comfortable with automated containment. That is fine.

A good first step is to automate the preparation of the decision.

When an important alert appears, the analyst should not need to open six dashboards and contact three teams just to understand the situation.

The system should automatically prepare an evidence package containing the affected identity, device activity, recent access, relevant changes, data sensitivity and available containment options. The human still decides. But the human starts with context instead of starting with a blank screen.

5. Run incident exercises where speed actually matters

Many incident-response exercises test whether people know the process.

Who calls legal? Who informs management? Who writes the report?

Those questions matter, but the exercise should also test whether the organisation can react before the fictional attacker completes the attack. Give the team five minutes, not five hours. Change the situation while they are discussing it.

Let the compromised account create another token. Let it access another system. Let it begin downloading data.

That will quickly reveal where approvals, ownership and technical visibility are slowing everyone down. 

The defence model needs to change. 

I do not believe AI suddenly makes every security setup useless.

But it changes how long we can assume that an undiscovered weakness will remain undiscovered. It also changes how quickly an attacker can move after finding that weakness.

This means our defensive advantage cannot depend only on prevention.Prevention will fail somewhere.

The advantage must come from how quickly we notice unusual behaviour, how quickly we understand its meaning and how quickly we create friction for the attacker. The traditional incident report will still be important.

We still need to know what happened and why. But an excellent report produced two weeks after the incident does not help much if the attacker only needed ten minutes.

The real question for enterprise defenders is becoming very simple:

When the next attack begins, will we recognise it and slow it down before the attacker has already moved on?

Final thoughts

My view is simple: enterprise security teams need to stop measuring success only by whether an alert was generated and start measuring how quickly the organisation understood the risk and acted on it.

The practical direction is to reduce the gap between signal and decision through better context, pre-approved low-impact containment actions and faster evidence collection.

We do not need to automate every security decision, but we do need to create friction for attackers much earlier. In an AI-accelerated environment, speed of understanding will become just as important as strength of prevention.