· · security-operations detection-engineering ai soc

The Eager SOC

One event, two intents. A single neutral event card, a service account reading every object in the directory at 2am, forks at a node marked "intent?" into a green "benign: the weekly inventory job" and a red "malicious: a stolen account mapping the org." A faint scatter of other events fills the background. The same log line. The event never carries the intent, so someone has to attribute it.

A service account signs in at two in the morning and reads every user object in your directory, four thousand of them. Nothing in that sentence tells you whether to care. It is the asset-inventory job that has run every Tuesday night for a year. Or it is someone who phished a helpdesk account an hour ago and is now mapping your org to decide where to go next. Same account, same query, same four thousand objects, same timestamp to the minute. The log line is identical either way. What separates the two is the intent behind the action, and intent is the one field no sensor writes down.

That gap is the whole job. Security looks like a data problem and turns out to be an intent problem. I have argued before that security is theoretically simple, because every investigation is one correlation question, whether a handful of events, tied together by an identity or an IP or a span of time, add up to malice. On a whiteboard that is trivial. In production it is a war against entropy, because admins do the things attackers would love to do, healthy systems behave like compromised ones, and benign activity scales faster than any rule or SIEM ever will. The events are all recorded. Their purpose is what you are after, and the telemetry leaves it out.

So the discipline comes down to one task, performed a million times a day: read a set of events and attribute intent. The dashboards, the correlation rules, the threat feeds are all in service of that.

Watch an investigation actually run

Follow the 2 a.m. read. A detector flags it, and an analyst, or lately an agent doing the same job, starts pulling. First the sign-in: where did it come from, was MFA satisfied. That looks ordinary, so next the device: the enrolled laptop, or something nobody has seen before. Then the account’s own history: has it ever done this. Then the neighbors: did the same source touch other accounts tonight. Then, if none of that settles it, a call to the admin.

Look at the shape of that work. Every step is a pull, and every pull is a round trip to a different system. The investigator fetches one artifact, reasons about it, decides what to fetch next, fetches that, reasons again. The investigation is a serial loop of pull-and-think, slow because the pulls happen one after another and the thinking between them is the costly part. Most nights it ends where this one does, at “benign, the inventory job,” which means the whole careful sequence was spent to confirm that nothing happened.

That is why investigation is rationed. The detector in front of it is cheap and shallow: it matches a pattern a human froze into place months ago and holds no opinion about intent. The investigation behind it is deep and expensive, minutes and real money per case, so you can only afford to run it on the thin slice of events the detector flagged. Everything the detector let through goes unjudged, because there was never budget to judge it. The dumbest component in the stack decides what the smartest one is allowed to look at.

Why it was built to pull one thing at a time

The serial, reactive loop is not a mistake. It is the correct design when thinking is the expensive step. If every judgment costs an analyst’s attention or a long chain of model calls, you spend as few as you can: pull the lightest artifact first, ask whether it is even worth pulling more, and stop the moment you can defend stopping. Fetch lazily, because the thing that consumes what you fetch is costly.

That cost just moved. A new kind of model, what its makers call a System One model, renders a decision instead of prose. You hand it a block of state and a typed question, and it returns a calibrated probability in a few hundred milliseconds for a fraction of a cent. Calibrated is the load-bearing word. A 0.2 from a calibrated model should be wrong about one time in five, which is what lets you treat the number as a probability rather than a vibe. Whether that calibration actually holds is the fight the back half of this piece picks. Jev, the first of these to ship, generates no text at all; it scores the options in a single pass and returns.

It is not alone. Within two weeks OpenAI shipped a Decisions API and Databricks a decision function called ai_decide, so this is a category forming, not one lab’s bet. They don’t agree on what “calibrated” means, though. Jev trains its probabilities against real outcomes, while the general-purpose options mostly have a language model report a number about itself, which is a different thing entirely. Hold onto that difference. Whether any one of them wins is beside the point. That a fast, calibrated decision now costs almost nothing is the part that matters here.

Pull everything, then decide

When the evaluator is almost free, pulling one artifact at a time stops being the smart move. You no longer need to fetch a little and ask whether to fetch more. You can gather everything the decision could need, all at once, and spend one decision on the whole bundle.

That is the flip. Instead of a detector that fires and triggers a slow, reactive investigation, you gather the context for an event up front, in parallel, assemble it into one state, and run a single decision over all of it. The sign-in, the device, the history, the peers, the asset’s sensitivity, fetched together rather than one after another, handed to the model in one pass. Out comes a calibrated intent estimate: 0.04 for a read that matches the standing inventory pattern, or 0.5 for an account that has never done this while three of its peers lit up in the same hour, which is the signal to put a human on it.

Two architectures side by side. Left, "Reactive, today": an event hits a detector, then a serial staircase of pulls (sign-in, device posture, account history, peer activity, call the admin), each a round trip, ending in a benign verdict, marked slow and costly and affordable only on flagged events. Right, "Eager, proposed": the event draws on a standing pre-joined context store, five context chips are pulled in parallel into one bundle, a single System One decision runs over the bundle in about half a second, and returns a calibrated intent probability, on every event. The old architecture minimized decisions because decisions were expensive. The new one maximizes context per decision because decisions are cheap.

Because the decision is cheap, you run it far wider than the thin slice a detector flagged, on every meaningful bout of activity in the stream. “Every” still has a budget. A fraction of a cent across hundreds of millions of raw log lines is real money, so the unit is a session or an entity’s hour taken above a mechanical dedup, not the firehose itself. A decision stops being the rare thing you spend on an alert and becomes the ordinary thing you spend across the environment. The detector doesn’t disappear; it just stops being the gate that decides what gets thought about.

The obvious objection is that none of this is new. SOAR already auto-enriches alerts, and a UEBA model has scored pre-assembled behavior on every event for years. Both are real, and both hit the same wall from opposite sides: the trained model runs on everything but only answers the questions someone already built and labeled it for, while a human or an LLM can answer a new question but can’t run on every unit. What changed is not that pulling-then-deciding became possible, but that one decision became cheap to run and to author at the same time. So you can put a new intent question to every unit of activity without training a model for it, which is the thing neither enrichment nor a human queue could do.

The part that is not free

Pulling full context for every event only works if the context is already there to pull. Fetch it live, one query per source per event, and you have rebuilt the serial investigation with extra machinery. The architecture assumes the opposite: that the context is standing and pre-joined, the device posture and the identity graph and the recent history and the peer activity already assembled and waiting in one place. This standing, shared memory is what a context lake is, and it is what makes the proactive pull affordable. Full disclosure: a standing context layer like this is what we build at Simbian, which is part of why I am convinced the hard part lives in the context and not the model. The model is the cheap part. Having everything it needs already in front of it is the expensive part, and the investment moves from running investigations to maintaining the context that lets you skip them.

The decision really is almost free. Score every entity-hour in a ten-thousand-person org, on the order of a million decisions a day at a fraction of a cent each, and you are spending something like a hundred dollars a day, a rounding error next to a single analyst’s salary. The inference was never going to be the cost.

What costs is the queue it produces. Put a score on a million units a day and even a well-calibrated model hands back a large pile of middling ones, the 0.3-to-0.6 range where it genuinely can’t tell. Routing those to a human is the alert queue coming back one layer up, because the false positive rate was always a statement about human capacity, not detection accuracy. The eager architecture doesn’t abolish that constraint. It changes what the queue is made of, from alerts a rule happened to fire to units ranked by how much they should worry you, and it is only a win if that ranked middle is smaller and better ordered than the false positives it replaces. You still work down the list until you run out of people.

So the bill doesn’t disappear; it moves off the decision and onto the context you maintain and the queue you create. A few more things keep the rest of the scheme honest.

You cannot pull everything. A security investigation has no natural end; there is always one more artifact, one more day of history, one more system to check. “Pull everything” is really “pull a chosen bundle,” and the decision is only as good as whether the fact that would have changed it made it into the bundle. If the log that shows the helpdesk account was phished an hour earlier is not wired in, the model looks at a tidy standing pattern and returns a confident 0.04. The bundle sets the ceiling, and you drew its edges.

Part of the bundle is written by the attacker. The command line, the service name, the scheduled-task description, the comment in the script are fields the adversary controls, and a model that reads meaning can be moved by meaning. A detector matching bytes could not be talked out of firing. A judge that understands a note claiming the action was “approved by IT” can be. You made the smart part of the stack persuadable by the person it is judging.

Nobody ever tells you the 2 a.m. read was benign. The analyst closed it “inventory job,” but no one came back later to confirm nothing bad happened. “Benign” has no proof; it is just where the pull stopped. So the calibrated number is only as honest as the outcomes you can observe, and in security you mostly cannot. Worse, some of these models were never calibrated against an outcome at all; a self-reported confidence is a number about the model’s own state, not about what happened in your network.

Calibration has a second crack, and it is worse. “Calibrated” is a promise about a population, not about this bundle. A model whose 0.2s come out wrong one time in five across everything it was scored on can still be far off on a bundle unlike anything in that set, and it reports the miss in the same confident voice as a hit. The bundles least like the calibration data are the novel attacks, because tradecraft nobody has seen is out of distribution by definition. So the confidence is steadiest on the benign routine you never needed help with, and shakiest on the new intrusion you built the system to catch. Whether this bundle is one the number can be trusted on is a separate question the number cannot answer, and producing a bundle that scores a confident 0.04 is what the attacker is trying to do.

If any of this pans out, the leverage sits in the least exciting part of it. Not the model, which keeps getting cheaper, but the standing context underneath it, the pre-joined memory the decision reads from. That is the part you would have to build, and the part that never gets an announcement.

Whether it adds up to a better SOC, I can’t tell you. A near-free decision lets you score everything instead of the sliver a detector flags, and that is a real change. It also hands you a larger pile of maybes, a judge the attacker can write to, and a number you can trust least on the attacks that matter most. Maybe those are tractable. Maybe they are the old problems in a new coat. What changed for certain is narrow: the decision got cheap, and the judgment it was standing in for never did.