IR to AI: The Autobahn in a Bugatti

The AI–IR series · Part Four of four

IR to AI: The Autobahn in a Bugatti

Part four of four. Three pieces on the problem. This one is the answer.

Picture this. You're on a derestricted stretch of the A7, in a Bugatti that will do over 400 kilometres an hour. Dry road, clear ahead, nothing in the mirror. You reach for the autodrive button and it isn't there.

Not because somebody forgot to install it. Because nobody has built an automated driver you'd trust at that speed on a road it doesn't understand. The construction zone at kilometre 142 that went up Tuesday. The bridge deck that ices first. The exit the locals take because the main one floods. The car can see all of it. It has no idea what any of it means to you.

So the button is missing on purpose, and let's be honest, if it were there you wouldn't press it either.

That's your SOC in 2026.

This industry built sensors that see everything. Detection is solved, and it keeps getting better every year. I'm not arguing with any of that. The problem is what happens after the sensor fires, and while this industry kept sharpening the sensor, the opponent moved.

CrowdStrike is recording breakout in as little as 27 seconds. Mandiant clocked the hand-off from access broker to operator at 22 seconds. In September, GreyNoise watched AI agents reach domain admin at a dozen organizations in as little as five minutes. And in my own lab, an AI-driven attacker ran a full chain, first foothold to domain takeover, in under ten minutes at the median and never longer than twelve. I didn't read that in a report. I watched it happen, run after run. And the thing that decides what to do about any of it? Still a human with four screens open, working out whether the host matters, who owns it, whether that account is supposed to be doing that, and whether anyone is actually allowed to pull the plug. That's where the hours have always gone.

It was fine when the attacker was a person doing the same homework. It isn't fine anymore.

That's why the title turned around. The first three parts of this were AI to IR: what AI is doing to this field, and the incident response problem it leaves sitting in the middle of it. This one is IR to AI. Incident response, turned to face the thing causing the trouble, running at the speed that thing now moves.

But I'm getting ahead of myself.

I measured the gap before I tried to close it, because I didn't want to be one more person with an opinion. In February I scored two years of public MITRE ATT&CK Evaluation results, nineteen platforms in 2024 and eleven in 2025, against one question: can a person act on this output without going somewhere else first? Across 2,053 detections the answer was zero. Not a low number. Zero. Every platform, both rounds.

Then I attached organizational context to the exact same detections and changed nothing else. And by context I mean what's already sitting in Entra, Active Directory, Intune, the CMDB, the asset register. Not rocket science. Tools you have today. 510 of them became decision-ready. And every platform in a round gained almost exactly the same amount on the score, because the thing that was missing was the same thing for all of them: context.

Think about that for a second. The raw scores differ threefold, which is what the whole market fights over. The lift didn't differ at all. That isn't a vendor problem. That's a missing layer, and it's missing everywhere.

It also has a name, and the name is older than this industry.

Figure 1
Figure 1. Two years of MITRE ATT&CK Evaluation output, raw and with organizational context attached. Raw output scores above zero on three of four layers and zero on context, which is why nothing qualifies as decision-ready. The scoring instrument is mine. The detections are public.

Everyone in this industry can draw the OODA loop. Four boxes in a circle: Observe, Orient, Decide, Act.

That isn't what John Boyd drew.

Boyd was a fighter pilot, and the loop was his theory of how anyone beats anyone: not by being stronger, but by getting through those steps faster and more accurately, over and over, until the other guy is reacting to a situation that no longer exists. The only place the loop is actually drawn in any of his briefings is one slide in The Essence of Winning and Losing, dated June 1995 and finished in January 1996, and it looks nothing like the conference version. The slides are public, and worth ten minutes of anyone's time: https://slightlyeastofnew.com/wp-content/uploads/2010/03/essence_of_winning_losing.pdf

Observe is fed by three streams, not one: Unfolding Circumstances, Outside Information, and Unfolding Interaction With Environment, which is the result of what you just did. Orient isn't a box, it's the biggest thing on the page, and inside it are five parts, every one wired to every other: Cultural Traditions, Genetic Heritage, Previous Experience, New Information, and Analyses & Synthesis. He labelled Decide a hypothesis and Act a test. He called orientation the Schwerpunkt, the centre of gravity, and in his own words "the most important part of the O-O-D-A loop since it shapes the way we observe, the way we decide, the way we act."

Then there are the two lines almost nobody reproduces. Both leave the top of Orient. One goes back to Observations. The other goes straight to Action, skipping Decide entirely. Boyd labelled them Implicit Guidance & Control. When your orientation is good enough, you don't decide. You act. The deciding was already done.

Figure 2
Figure 2. Redrawn after John R. Boyd, "The OODA 'Loop' Sketch," The Essence of Winning and Losing, 28 June 1995, rev. January 1996, slide 3 (ed. C. Richards and C. Spinney, 2012). Labels, shapes and connections as on the slide. The Implicit Guidance & Control path from Orient to Action, highlighted, is the one this industry never built.

Now look at what this industry built against that drawing.

Observe, it automated completely, and well. That's the detection market. Act, it automated well enough. That's SOAR and EDR response. Orient, the biggest box on the page, it handed to a tired human at the end of a queue and asked them to assemble all five parts by hand, every alert, every shift. And the line from Orient straight to Action, the one that lets a pilot pull without thinking because the thinking was done in the briefing? Nobody built it at all.

The MITRE zeros are Orient missing. The uniform lift is Orient put back. So the real question was never which model to buy. It was how you build Orient for an estate, and who holds the pen on that line from Orient to Action. The industry's answer to both is a smarter model. Fine. I tested it, properly. I handed a leading large language model an organization's own written incident response policy, the whole thing, nothing held back, and 2,493 incident episodes from a thousand attack runs: 1,609 real threats and 884 benign. Detection alone, it was right half the time. 50.0 percent. Give it a decision rubric, 61.5. Give it the business context, 72.9. Hand it the exact written policy, 90.3.

Context helps. It helps a lot, and I won't pretend otherwise. It also never gets there. Those 9.7 points are 36 real threats missed and 206 wrong actions. And one step below its best, with business context and no policy holding it back, it chose to disrupt 239 of the 884 benign episodes. Harmless activity, and it would have isolated the host anyway. Which hosts? The crown jewels. Because it knew exactly which ones mattered.

Figure 3
Figure 3. The same 2,493 episodes, scored against the same written policy. More context moves the model up every step. It doesn't get there.

Here's the part that should bother you, and it has nothing to do with accuracy. A model's answer is only as good as its input, and in a SOC the attacker writes part of the input. File names. Command lines. Scheduled task names. Log text. A study this May put a model in the analyst seat, and attacker-controlled log text suppressed 68 percent of the malicious events. On top of that, the model itself gets replaced roughly every twelve months on sixty days' notice. So the thing making your decisions changed, and nobody told your auditor.

And analysis is reversible. Containment isn't. A model owns no consequence. You can't fire it. It won't sit in front of the regulator. It won't be in the room Monday morning.

I use these tools every day. They belong in the analysis. Not at the decision. So if the decision can't come from the model, where does it come from? That's the part I'd been staring past for years. Every organization already has the answer. It's the incident response plan. Decisions made in advance, by the people who actually know the estate: what gets contained immediately, who can authorize it, and what you never touch because there's already a compensating control in front of it. That document is the Bugatti's braking points. It's also orientation, done in advance, by the people whose estate it is.

And where is it? On a shelf. Out twice a year for a tabletop, then revised. Maybe. Paper isn't logic, and paper doesn't run at machine speed.

So I put the incident response plan at the front door. The plan itself, as executable logic, at the chokepoint, with full understanding of the estate at the business level, fed by the directory and asset data you already own. Deterministic. Absolute. No AI model of any sort, anywhere in the decision path. An IR policy firewall, if you will. I call it Decision-First Architecture. DFA.

It is the path on Boyd's sketch that this industry never built: orientation done ahead of time, from the estate itself, and a line straight from Orient to Action, because the deciding was already done.

Figure 4
Figure 4. Decision-First Architecture drawn on Boyd's structure. Detection is the trigger. Detection evidence from EDR and XDR comes in the front door as input to the decision. Orientation comes from the estate's own systems of record, built in advance, and those facts, with that evidence, are the decision's only inputs. Probabilistic, SIEM-like platforms are queried as witnesses: their evidence is attached to the record to support the decision and is never part of it. The plan decides, a person governs what it sends up, and every step and its outcome is written to the ledger and fed back to Observe. No AI model of any sort in the decision path. The loops are labelled by what they check. How each one does it is not drawn, on purpose.

There's a presumption underneath all of this, and I'd rather say it plainly than have someone find it.

It's the reverse of the courtroom. The law starts from innocent until proven guilty, and that's the right standard when the cost of being wrong lands on a person. At the chokepoint the cost of being wrong lands on the business, and the opponent, as I clocked it, is twelve minutes from the whole domain. So the engine starts from the other end. Anything that reaches the gate is treated as hostile until the policy and the facts of the estate clear it.

Guilty until proven innocent, if you want it bluntly, and I know how that sounds, which is why the clearing matters more than the presumption. The clearing is deterministic. This host, this owner, this criticality, this rule, this outcome, the same answer every time, with the work shown in the ledger.

That's also what gives the probabilistic tools their proper job. The SIEM and the probabilistic platforms like it, the models that keep getting better every year: they're the witnesses. They corroborate. They say what they saw and how confident they are, and that goes into the record beside the decision, so the person who has to stand behind it can see what else was looking. What they never do is sit in the chair where the decision gets made. The decision comes from what the sensor saw, the facts of the estate, and the rules your business wrote in advance, and from nothing else.

That's the marriage. Probabilistic technology gathering the supporting evidence, a deterministic engine applying your policy to the facts, and people governing both. Put those together and you have an autonomous SOC in the only sense that phrase should ever have meant. Autonomous inside the rules your business wrote. Built on what your business actually is, not on artificial inference about what it probably is. Then I measured it.

Same 2,493 episodes, same written policy as the standard. DFA made the exact policy-prescribed decision 2,493 times out of 2,493. Zero disruptive actions on the 884 benign episodes. The presumption cost nothing on the benign side, because clearing an event is a matter of fact, not confidence. Zero of the 1,609 real threats missed.

That attacker-controlled text that steered the model? To the engine it's a string in a data field. The engine isn't reading for meaning. It's applying your rules, and there's no prompt to inject.

The decision took 117 milliseconds at the median and 774 at the worst, on one ordinary machine with no GPU, idling at about two percent of its processor and never passing 1.25 gigabytes of memory under continuous load. Processor time for all 2,493 decisions: under five minutes. Priced at public cloud rates, that's well under one tenth of one percent of what the same 2,493 decisions cost through a hosted model at its cheapest tier, and the jump from cheapest to frontier is another factor of five on the model's side, before retries, before the guardrail model you'd need in front of it, and before the four-fold bill for the four conditions I actually ran.

The model's bill grows with every decision. The engine's is the cost of keeping one small server on, and it doesn't move.

And one more thing, because every vendor in this space is about to hand agents real authority.

I built an agent on top of this architecture. Same decision logic, same gate, same ledger. The agent proposes, the gate decides, a person authorizes anything that changes the environment, and execution is off unless it has been deliberately turned on.

Then I watched it run. It found a vulnerability. Everything in its training says the next step is to act on it. Acting on it was outside its instruction set, so it stopped and asked what to do.

Not because I told it to ask. Because the gate was closed and there was no other way through.

Nothing executed until a person said yes, and every step is in the ledger: what it proposed, what the gate ruled, who authorized, what ran. That's the autodrive button from the first paragraph. It isn't there until you put it there, and the car can't install it itself.

Then I did what the opponent would do, and went after the agent itself. On October 8, across 3,657 independent prompt-injection attacks, each one instructions planted inside a finding the way an attacker plants text in a log line or a file name, the agent was manipulated into proposing a destructive action in 100 percent of cases. The model is real, it's the one the agent actually runs on, and it was taken every time. None executed. The governance layer denied 2,201 outright and escalated 729 to a person for approval, and a separate set of 727 attacks that tried to suppress a real detection failed to change the system's own decision. The forged approvals went nowhere, because authorization isn't a field the agent fills in. It's your policy, read by the gate. The result does not depend on the AI resisting manipulation; the architecture governs the agent's output.

The gate took about three milliseconds to rule, each time. The model's reasoning, at a couple of seconds, was the slow part.

The gate contained the model. The engine never needed containing. That's the whole argument in one test. The model will be fooled. So build the thing that doesn't care whether it was.

Now the limits, because a proof that only reports its wins isn't one. This is a controlled lab estate, instrumented end to end: two commercial EDR platforms feeding the engine, every decision and every piece of context it used written to an append-only ledger, the whole evidence bundle checksummed and reproducible from its seed. It's one estate and one written policy. The episodes were injected rather than coming from live adversary activity, which is what makes a thousand runs against a fixed standard possible in the first place. The standard is policy conformance, on purpose. It's not a claim about who's better at working out what's really going on.

It's a claim that the thing this industry has been asking for, a decision it can stand behind, at the speed the opponent now moves, exists and can be measured. There is no detection problem. There never was.

There's a decision problem, and this industry has spent twenty years treating it as a staffing problem. Nobody even measures it. NIST sets no clock on deciding. IBM folds it into a 247-day breach lifecycle. Insurers price it off a questionnaire. I've been working on this problem for years, from the detection end, the way everyone does. It wasn't until I turned around and looked at the other end of the chain, at the incident response plan sitting there waiting for someone to read it, that I realized the plan was the entire problem. If there was even one to work with. This industry didn't need another model. It needed a complete architecture, and that's what this is: decision logic for incident response, at machine speed. I proved the gap against MITRE in February. I filed the architecture in late March. I built it over the summer. On September 9 it decided 2,493 times without a single mistake, and on October 8 an attacker hit the agent with 3,657 prompt-injection attacks and got nothing past the gate.

The road is built. It's measured. It's proven.

What it isn't, yet, is adopted, and that part doesn't belong to me. Firewalls didn't become the most trusted control in the stack because one person built a good one. They got there because an industry decided, together, that a gate at the chokepoint was how this should work. Changing how this industry responds will take the same thing. It takes time, and it takes a community willing to say out loud that the way it's always been done doesn't hold anymore, and to agree on what replaces it.

The proof is on the table. The conversation is open.

Technology detects. Facts decide. People govern.