Breakout TimeThe Real Barrier to Machine-Speed Defence
Machine-speed attacks require machine-speed defence. It’s that simple.
Put the best trader in the world up against a high-frequency trading algorithm and ask them to compete on speed. The human loses before they have even registered that the price moved.
Cyber defence has the same problem. You cannot match machine-speed attacks with humans operating at a speed determined by caffeine, office noise, and the number of “important” meetings sitting in their calendar.
Humans are the latency.
Machine-speed defence means taking them out of decisions that involve competing against machines.
And this is where things get awkward.
The obvious answer is to let machines investigate, decide and act.
Except the moment you try to do that, you expose an inconvenient truth. Every generation of SOC analysts has been quietly compensating for a fundamental weakness in the way security gets done. They have been carrying your organisation and nobody realised.
I can say with a high degree of confidence that your security policies are not ready to direct agents.
Let me show you why.
It is 02:00 and your customer database is leaving the building
One of your privileged database administrator accounts has started exporting a large volume of customer data from production to a system it has never touched before.
Your security agent is watching it happen.
It has already done the investigation.
The account is privileged. The destination is unusual. The volume is abnormal. The activity came from an administrative host. Nothing similar has happened in the last six months.
You probably want it stopped.
Except there is a major database migration happening tonight.
Fine.
Check the change record.
There is one.
It is approved.
Unfortunately, the destination in the change record is not the destination your customer data is currently heading towards.
Now what?
Kill the export?
Disable the DBA account?
Isolate the server?
Keep watching?
Ask somebody?
That last answer is what we normally do.
And that is exactly why this is not machine-speed defence.
The machine has already done the security investigation. The thing stopping it now is not telemetry, correlation or reasoning.
It does not know what you want it to do.
Machine-speed defence is really policy enforcement
Agents are goal-driven systems.
That matters more than it sounds.
In security, the goal is not simply “Stop attacks”.
If it were, this would all be much easier. Disable every suspicious account. Isolate every suspicious server. Block anything unusual.
You would have excellent containment metrics and possibly no functioning business. Bravo.
Your organisation has already made choices about which risks it accepts, which systems matter most, which interruptions are tolerable, who is allowed to do what, and when security is allowed to intervene.
We do not usually describe those choices as goals.
But that is effectively what they are.
Security policy encodes the organisation’s goals for managing risk.
Once you remove the human from the decision, this becomes very obvious.
Your machine-speed defensive system is, in effect, a security policy enforcement system.
The investigation tells it what is happening.
Policy tells it what should happen next.
That is the part we are not ready for.
“Check whether it is authorised” is not enough
The obvious instruction is: “Check whether the activity is authorised.”
Great.
What does authorised mean?
Does an approved migration allow any database administrator to export the data?
Does the source database have to match the change?
Does the destination?
Does the DBA need to be explicitly named?
What if the migration runs an hour late?
What if the original destination fails and the infrastructure team switches targets halfway through?
What if that change was approved in Teams but nobody updated the ticket?
A human can cope with this.
Your analyst sees the approved migration, recognises the database team, messages somebody and discovers that the target changed twenty minutes ago because the original one failed.
They close the alert.
Perfectly reasonable.
They probably did not read your privileged-access policy first.
They may not know where it is.
That does not stop them making the decision.
This is where the real problem starts.
Most SOCs run on policy-as-lore
SOC analysts make security decisions every day without consulting formal security policy.
They still somehow know what to do.
They know the infrastructure team uses a tool that looks suspicious but appears every patching weekend.
They know a particular service account looks horrifying in the logs but belongs to an essential overnight process.
They know you technically can isolate a certain production server, but doing so without calling the service owner first would be career-limiting.
Where is that policy?
Some of it is in IAM.
Some is in the CMDB.
Some is in the change system.
Some is in runbooks.
Some comes from old incidents.
Some was explained in a Teams conversation eighteen months ago.
Some exists entirely inside the heads of experienced analysts.
Some of it may be walking out the door.
SOCs do not operate on policy-as-code.
They operate on policy-as-lore.
And, for the most part, it kind of works.
Humans are exceptionally good at taking incomplete records, local knowledge, precedent, conversations and vague rules and turning them into a decision.
We call that experience.
For a machine, it is missing state and missing rules.
That is why a senior analyst can resolve something in five minutes while a new hire new spends forty minutes working out who to ask.
The senior analyst is not just better at reading logs.
They know the lore.
That becomes a serious problem when you want the decision in seconds.
Machine-readable is not decision-complete
There is an obvious response to this.
Make the policy machine-readable.
Good. You should.
But do not confuse representation with decision-making.
Take a perfectly normal policy statement: “Privileged access must only be used for authorised business purposes.”
You can put that in YAML, JSON, Rego or anything else you like.
The machine can parse it perfectly.
It still has no idea what to do.
Who is authorised?
Authorised by whom?
For which systems?
For which actions?
For how long?
Which system proves that authorisation?
What happens when IAM and the change system disagree?
How fresh does that information need to be?
What happens when the required information is unavailable?
And if the policy has been violated, what is the machine actually allowed to do about it?
That is the difference between machine-readable and decision-complete.
A decision-complete policy contains enough information for the machine to reach the operational decision without handing the difficult bits back to a human.
For our database migration example it might need something more like:
An approved migration is currently active.
The source database is within its scope.
The destination is within its scope.
The identity performing the export is authorised for it.
The activity falls within the approved time window.
No current security restriction overrides that approval.
Now the machine has something it can evaluate.
We did not make the AI smarter.
We made the decision explicit.
Policy-as-code solves the representation problem.
Machine-speed defence requires you to solve the decision problem.
The speed comes from making decisions earlier
Go back to the database export.
The alert fires.
Only then does the analyst start finding the information needed to make the decision.
Who owns the database?
Is there a migration?
Who approved it?
Which destination was approved?
Is this DBA authorised?
What happens if we stop the transfer?
Who is allowed to make that call?
The machine can collect the security evidence in seconds and still end up waiting while a human works through those questions.
That is where much of the latency actually lives.
If you want the decision in seconds, you need to settle more of those questions before the incident.
Define what counts as an authorised migration.
Define which system proves it.
Define how closely reality must match the approval.
Define how current that approval needs to be.
Define what happens when information is missing.
Define which actions security is allowed to take without asking anyone.
Then the event happens and the machine evaluates decisions you have already made.
That is where the speed comes from.
Not because AI develops some supernatural understanding of your company.
Because you stop asking a human to resolve the same ambiguity every time something suspicious happens.
Your runbook probably contains more lore
You may think your runbooks already solve this problem. Guess again.
Open one.
You will probably find something like:
1. Determine whether the activity is authorised.
2. Check for an approved change.
3. Assess business impact.
4. Contain if appropriate.
That is entirely reasonable guidance for a human.
It is also nowhere near decision-complete.
What counts as authorised?
Which change states count?
How closely must the observed activity match the ticket?
How do you assess business impact?
When is containment appropriate?
The difficult decisions are still hidden inside normal English.
A runbook tells a human where to apply judgement**.**
It does not remove the judgement.
Making the runbook machine-readable does not resolve the problem either.
You now have a machine-readable instruction saying: “Contain if appropriate.”
Wonderful.
The agent still needs you to decide what appropriate means.
And then the change system goes down…
Our database migration is still running.
The source database matches the approved change. Check.
The administrator matches. Check.
The destination does not. Uh oh!
The agent tries to check whether the change was updated.
The change platform is sadly unavailable.
The agent’s last copy of the ticket is six hours old.
What should it conclude?
There is a dangerous shortcut here.
This:
I cannot confirm this activity is still authorised.
quietly becomes:
This activity is unauthorised.
Those are not the same statement.
If your IAM feed goes down, every administrator does not suddenly become an attacker.
If your change platform stops responding, every maintenance process does not suddenly become malicious.
Once machines start enforcing policy, that distinction matters, a lot.
You need a third outcome:
ALLOW
DENY
ABSTAIN
Abstain is a security control.
The machine is saying: “I do not have enough reliable information to make this particular decision safely.”
It can keep investigating.
It can collect more evidence.
It can escalate.
It may still take low-impact actions that do not depend on the missing information.
What it should not do is manufacture certainty because ServiceNow suddenly stopped returning its calls.
That means freshness itself becomes part of the decision.
How stale can an approval be before you stop trusting it?
How current must privilege information be before a machine disables an account?
How old can asset information be before automatic isolation is allowed?
Your AI vendor cannot answer those questions.
You have to.
Fine. The account is compromised
While the export continues, the agent finds something else.
The DBA account authenticated from a host it has never previously used.
That host triggered a credential-theft detection ten minutes earlier.
It is now probing other production systems.
Let us remove the uncertainty.
Assume the agent is right.
The account is compromised.
Can it disable it?
Maybe.
You still have two separate questions to answer:
1. Has security policy been violated?
2. What are you authorised to do about it?
The machine can know an attack is happening and still not have permission to stop it.
Perhaps terminating the database export halfway through risks corrupting the migration.
Perhaps the administrator account is also supporting an emergency recovery process.
Perhaps this system is so critical that isolation requires approval from the service owner.
Whether those are sensible boundaries is beside the point.
They are your boundaries.
Even when the agent knows it is an attack, it still needs to know whether you have authorised it to act.
Machine-speed defence therefore needs delegated authority.
What may the machine kill?
What may it isolate?
Which identities may it disable?
Under which conditions?
How much uncertainty is acceptable?
When must it abstain?
Which decisions do you deliberately keep for people?
“Human in the loop” is not an answer.
It is often just a polite way of saying we have not worked this out yet.
This is where generic security agents hit the wall
A vendor can give you an extremely capable agent.
It can query your EDR.
Inspect identity history.
Correlate network and endpoint events.
Follow an attack across cloud and on-premise systems.
Reconstruct what happened faster than your analysts.
Excellent.
What it cannot ship in the box is the answer to our database migration.
It does not know that the migration is happening.
It does not know what tonight’s approval actually covers.
It does not know whether a Teams message counts as emergency authorisation.
It does not know how stale your change data may become before the machine must abstain.
It does not know what happens to the business if it kills the export.
And it does not know what authority you have delegated to security.
Those are not missing AI features.
They are properties of your organisation.
The investigation machinery can be generic.
The decision model cannot be.
You can let the agent learn what your analysts normally do.
That may be useful.
But now you are teaching it policy-as-lore by observation, complete with undocumented exceptions, inconsistencies and bad habits.
Or you can make it ask a human whenever things become unclear.
Congratulations.
Your machine-speed defence is now waiting for somebody to reply on Teams at 02:00.
Do not turn lore into bureaucracy-as-code
There is a horrible possible conclusion to all this.
Someone decides the answer is to formally specify every legitimate thing every person and machine in the company is allowed to do.
Please don’t.
You will create bureaucracy-as-code and still fail.
People improvise.
Systems break.
Emergency changes happen.
Attackers do things you did not anticipate.
Some decisions genuinely need judgement.
Keep humans for those.
The goal is not to eliminate runtime judgement.
It is to stop wasting runtime judgement on decisions you make repeatedly.
If analysts always ask whether the same activity is covered by an approved change, expose that information to the agent.
If the same exception is approved every month, decide what the rule actually is.
If every investigation requires someone to ask who owns a system, then fix the system that should already know the answer to the question.
Turn the useful parts of policy-as-lore into decision-complete policy.
Leave the genuinely weird cases to people.
Pull 100 investigations on Monday morning
I would not start by giving an agent permission to isolate production servers.
Start with 100 completed investigations.
For each one, ask:
What did the analyst need to know that the security telemetry did not tell them?
Maybe it came from IAM.
Maybe a change ticket.
Maybe asset ownership.
Maybe Teams.
Maybe the analyst just knew.
Then ask: “Could we have known this before the incident?”
If yes: “Can we express the decision precisely enough for a machine to evaluate it?”
Then: “Is the underlying data fresh enough to rely on?”
And finally: “If the machine reaches the answer, have we authorised it to act?”
Those questions will expose your real machine-speed defence backlog.
Some of it will be telemetry.
Some will be integration.
Some will be data quality.
I.e. engineering work.
However, a lot of it will be decisions that have lived as lore for years because humans were good enough at filling in the gaps.
Sooner or later the drive for machine-speed defence will inevitably expose the underlying issue for all to see.
The real barrier is not machine speed
We already have fast machines.
Detections fire in seconds.
We collect absurd quantities of telemetry.
Agents can investigate faster than humans ever will.
That is not the hard part.
The hard part is getting from: “Something bad appears to be happening.”
to: “Given what we know right now, this is the action we have already decided an agent should take.”
That is a policy-enforcement problem.
The telemetry tells the machine what happened.
The agent reasons about what it means.
But ultimately, policy tells the machine what the organisation wants done about it. See, I told you it was about goal setting, didn’t I?
In conclusion. Policy needs to be machine-readable and it needs to be decision-complete.
It needs to tell the machine what matters, where the facts come from, how fresh they need to be, when uncertainty means abstain, and what authority you have actually delegated.
And before you can do any of that, you have to find the real policy.
Not the PDF. The policy your SOC actually runs on.
The exceptions, precedent, operational knowledge and unwritten rules your analysts use every day.
The policy-as-lore.
Until enough of that becomes decision-complete, humans stay in the critical path.
Not because the machines are too slow.
Because the organisation has not yet told them, precisely enough, what it wants them to do.