Machine-speed defence: where automation wins, and where AI earns its place

If an attacker can move faster than your security team, you have a problem. Adding an AI agent to the SOC doesn't, on its own, tell you whether you've solved it.

The first thing I'd ask is where we're losing time. Telemetry might arrive late, or an analyst might be gathering evidence across five tools. Perhaps the investigation is already finished and the response is sitting in someone's approval queue. Buying more reasoning capability won't resolve all of those delays.

When I read a proposition built around “machine-speed defence” or “Zero Day SOC”, that's the detail I look for. How does it help us interrupt the attack, and what might the response disrupt? A rule, a specialist detection model, an LLM and a person can each contribute. The job determines which we need.

What has actually become faster?

Cybersecurity has dealt with automated attacks for decades. Scripts and self-propagating malware don't wait for an operator to approve every command. Polymorphic malware also predates today's LLMs, although changing a payload's representation is different from reasoning about an unfamiliar environment.

The ability to adapt during an attack does deserve our attention. A system can select tools, interpret their output, revise its approach and continue towards an objective. That can reduce the human effort needed to connect individual attack steps. It can also make capabilities available to people who would struggle to carry out the same work unaided.

The pace also changes during an attack. A command may execute almost immediately, while reconnaissance, failed attempts, decision-making and waiting for a target take much longer. Calling the whole activity “machine speed” conceals where defenders have opportunities to intervene.

The OpenAI and Hugging Face incident is a useful example. Hugging Face's July 2026 technical account describes an intrusion involving injection, credential access and lateral movement, with the reconstructed campaign extending across several days. It also describes adaptation when one approach was blocked. OpenAI's subsequent account places the incident within internal evaluations and discusses reward hacking and failures of isolation. Hugging Face technical timeline; OpenAI's incident account.

What interests me here is the combination of adaptation and familiar routes through security boundaries. To establish where a different defence would have stopped this incident, we'd need to know its configuration and what evidence it could have seen at that point. The published account alone doesn't settle that counterfactual.

Ciaran Martin makes a useful wider point: longstanding, unresolved security problems remain part of the picture as AI capabilities develop. That is a reason to examine our foundations carefully, without dismissing the change in attacker capability. From Frenzy to Freakout.

A zero-day exploit doesn't make every subsequent action invisible

Before evaluating a “Zero Day SOC” proposition, I'd ask what the term means in that particular offering.

A previously unknown vulnerability, an unfamiliar technique and a known behaviour appearing for the first time in your environment create different detection problems. We shouldn't treat them as interchangeable.

A defender may have no signature for an initial exploit and still observe the activity that follows: unexpected execution, access to credentials, a privilege change, a new connection or an unusual transfer of data. Depending on the environment and available telemetry, those behaviours may provide opportunities for detection or prevention.

Equally, none of those signals guarantees success. Legitimate administration can resemble malicious activity. Some attacks leave little useful evidence. A rule can be too narrow, a behavioural detector can misclassify activity, and a model can reach the wrong conclusion.

A useful proposition should explain which of those behaviours it can observe and interrupt. “Unknown threat detection” needs that detail behind it.

Detecting unfamiliar behaviour

Statistical and machine-learning (ML) anomaly detection give us another way to find suspicious activity. They can identify departures from expected behaviour without needing a signature for the specific exploit that caused them.

An identity accessing an unusual set of systems, an unexpected communication pattern or a change in data-transfer behaviour may provide an investigative lead. Microsoft Sentinel, for example, documents anomaly detection using historical activity and peer behaviour to establish baselines. Microsoft Sentinel anomaly detection.

That doesn't mean unusual activity is necessarily malicious. A maintenance programme, a new application or a change in someone's role can all alter legitimate behaviour. An attack may also resemble normal activity closely enough to escape detection. The result depends on what the system observes, the features it evaluates and how well its baseline represents the environment.

Suppose an engineer suddenly accesses systems they rarely use. The anomaly may be accurate, but an approved maintenance job could explain it. We still need to establish what the activity means before deciding whether to revoke access.

An LLM could retrieve the maintenance record and investigate whether it explains the observed activity. Its conclusion still needs supporting evidence, and neither it nor the anomaly detector can promise to catch every novel attack.

Separate detection, investigation and response

I find the comparison easier to follow when we separate three jobs, even if one product performs all of them.

An anomaly detector might raise the signal, an agent investigate it, and a deterministic workflow execute an authorised response. The same investigation may instead establish that the activity is legitimate and needs no intervention.

How the response workflow fits together

A deterministic playbook follows defined conditions and actions. Where the evidence and response are well understood, it can provide a direct route from a qualifying event to an authorised intervention.

Product-native automated disruption may involve more than a playbook. Microsoft Defender, for example, describes correlated evidence, specialised detectors, validation and supported containment actions. It would be misleading to reduce that capability to customer-written rules, or assume that it requires a general-purpose LLM to reason through each incident. Microsoft Defender automatic attack disruption.

An LLM-led workflow can interpret evidence and choose investigative steps through tools. That flexibility may help when the evidence is incomplete or the route through an investigation wasn't anticipated in advance. It also introduces uncertainty, tool calls and processing time that need to be evaluated.

A SOC can use direct controls for well-defined conditions and agentic investigation for unresolved questions. The important design decision is who or what can turn a recommendation into an action.

Where each approach can contribute

Here's how I'd examine coverage across an attack. This is a proposed framework, not a measured comparison or a reconstruction of the Hugging Face incident. In practice, the stages can overlap and repeat.

The last column needs testing. A convincing explanation from an LLM can still be wrong, particularly where the evidence is sparse.

There is also useful work before the incident. An LLM may help an engineer develop an investigation workflow or propose a detection rule. Once reviewed and tested, that rule may run without involving the LLM at all. That is a useful contribution from AI without adding another dependency to every live response.

Is a rule faster than an LLM?

For a known use case, with equivalent evidence and permission to act, my expectation is that a direct automated workflow will be faster and more predictable than adding an LLM reasoning loop. I haven't benchmarked that comparison yet.

But what happens when the rule doesn't fire? Its execution speed is then irrelevant to that incident. And an agent that promptly disables the wrong identity has made things worse. Both failures need to be visible in the result.

A fair evaluation would compare a deterministic workflow, an LLM-led investigation and a hybrid using the same available evidence and equivalent response permissions. The cases should include familiar attacks, variations, missing telemetry and legitimate activity that looks suspicious.

I'd separate two tests. A response-path test starts with the same qualifying detection and evidence package, then compares how each workflow investigates and carries out an authorised response. It isolates the work after that starting point; it doesn't measure detection coverage.

An end-to-end test starts with the scenario and measures the complete system's ability to detect, investigate and contain it. That includes the contribution of behavioural and ML detectors, as well as cases that never trigger. Each system should have access to equivalent raw telemetry, with the detection configuration and available context recorded.

For both tests, record whether containment was correct, whether intervention caused harm and whether escalation was appropriate. Include retrieval, retries, tool failures and confirmation that the action took effect in the timing window. The end-to-end results also need to show missed attacks. A fast result measured from an already-qualified detection tells us nothing about how long it took to reach that point.

Keep track of where the finding came from too. If an anomaly detector supplied it, that contribution belongs in the explanation of the result.

The rules should be fixed before the test, rather than written with knowledge of every test case. ML baselines should use separate training data, with their update policy recorded, so test cases don't leak into preparation. Agent instructions and model settings should also be recorded. Repeated runs matter where outcomes or timings can vary.

The conclusion should stay within the scope of those tests. We'd have evidence for choosing between those workflows in those conditions.

The business still determines the response boundary

Consider a compromised engineering identity with access to an operational environment. This is an illustrative scenario, not a production test result.

Revoking a specific session might interrupt the attacker. Disabling the identity might also affect legitimate maintenance or an application dependency. Isolating the workstation could have different consequences again.

A direct playbook needs reliable conditions and an authorised scope. An agent needs those boundaries too. Its ability to produce a more detailed explanation doesn't give it authority to accept operational risk on someone else's behalf.

This is where the mature SOC has an advantage: it has identified dependencies, agreed responsibilities and rehearsed interventions with the people who operate the service. Some actions can be delegated in advance. Others need approval based on the circumstances.

Agreeing those boundaries is part of improving response time. Otherwise, we discover during the incident that nobody knows who can authorise the next step.

What happens to MTTD and MTTR?

Mean time to detect and mean time to respond remain useful measures when their start and end points are clear. MTTR is particularly easy to misread because teams also use it for remediation or recovery. Those are different outcomes.

For an AI SOC, I'd want to distinguish first observable malicious activity, detection, investigation, authorisation, action execution, verified containment and service recovery. Some stages overlap. Measuring their timestamps makes it easier to see what actually holds up the response.

The first observable activity also depends on your visibility. Missing telemetry can make a detection interval look shorter than the attacker's real dwell time. I'd want to see those gaps alongside the reported time.

Machine-speed detection still has value when a person must authorise containment. It can start escalation earlier and give that person a better evidence package. But it cannot guarantee prompt containment if the approver is unavailable or doesn't have the information needed to decide.

I'd therefore measure time waiting for authorisation explicitly, separate pre-authorised cases from those requiring live approval, and examine long delays as well as averages. Cases that remain undetected or uncontained must remain visible in the reporting rather than disappearing from a speed metric.

There's enough here for a separate discussion of SOC metrics. The question I keep coming back to is when the attacker actually lost the ability to continue along the relevant path, and how we verified it.

Give reasoning a job worth doing

Before investing, look at a few recent incidents and find out where time was lost. If the team couldn't see the activity, improve the telemetry or detection coverage. If it couldn't obtain approval, resolve the authority and escalation arrangements. An agent may be useful where gathering and interpreting evidence is the work holding things up.

There is a further opportunity to examine candidate interventions before deployment. Dynamic attack-path modelling and digital twins could help us explore how a change affects an attacker's options and the services that depend on the environment. That deserves its own treatment, including the difference between blocking a route in a model and validating the operational consequences of a change.

I'd judge machine-speed defence by whether it gets us to an effective intervention sooner. Show me the coverage, the decision and the confirmed outcome. Then we can have a useful conversation about speed.

I've been exploring related investigation and response decisions through a simulated IT/OT scenario in my Playground. Explore the AI SOC demonstration and consider where you would use a direct rule, where you would want further investigation and where you would require approval. I'd welcome your feedback.