Disclaimer: Opinions expressed are solely my own and do not reflect the views or opinions of my employer or any other affiliated entities. Any sponsored content featured on this blog is independent and does not imply endorsement by, nor relationship with, my employer or affiliated organisations.
A few weeks ago I wrote How Not to Kill Your AI SOC. The short version: an AI SOC is at least three technologies. Deterministic code, ML, and language models. If you route work to the wrong tier, it breaks in ways no accuracy number will show you.
This week two things landed that push the same argument.
Alex Beaver published The Asymptote of the AI SOC is Determinism. It’s the best write-up I’ve read on why better AI makes deterministic automation more important, not less. Read it.
And TypeSafe released Jev, a new frontier model whose whole design is “put a fast decision inside deterministic code.”
So yes, we needed a new frontier model to confirm we should write code first. I’ll take it.
Product Updates
Armor Detect by Arambh Labs
Armor Detect is a detection engineering agent that runs the full lifecycle, from coverage gaps to tuning.
Coverage and Creation
Finds your MITRE ATT&CK coverage gaps. Creates production-ready detections from plain English and adapts the rules to your actual telemetry.Validation and Tuning
Backtests every detection against historical data before deployment, then ships it through CI/CD. Once live, it keeps tuning noisy or ineffective rules.Detection engineering as an autonomous loop, not a never-ending backlog.
Intezer Workflows and Custom Agents
Intezer already investigates 100% of alerts and escalates fewer than 2% for human review. Two new releases cover after the verdict.
Intezer Workflows
Response automation native to the AI SOC, instead of a separate SOAR, tested before they run live. Triggers on an analyst’s click or autonomously on verdicts. Describe it in plain language and Intezer’s MCP builds it.Custom Agents
Build your own agents on top of the ones Intezer ships. Each one runs your custom instructions, a trigger event or schedule, and the tools it can use. Teams run them for incident reports, tuning recommendations, threat hunting, case routing, and shift handoffs. Every run shows reasoning and tool calls, and Dry Run mocks write actions before go-live.
The asymptote
Alex’s argument comes from automation economics. Automation means paying more up front so each run costs less. That math works best for work that is frequent, stable and rule-based. Sounds like most of a SOC.
What stopped us before was the up-front cost. Engineers are expensive, and every exception needed a human to write it. So a lot of automation never got built, and agents looked like a good middle ground. Cheaper per case than an analyst, and they scale with alert volume.
But AI coding tools are killing that up-front cost. A good engineer with a coding agent builds playbooks much faster than before. So work that wasn’t worth automating deterministically suddenly is. And for repeatable work, a GPU running inference won’t beat a CPU running code on cost.
His conclusion: as more of an agent’s work becomes repeatable, it moves into deterministic code. Not to 100%, because agents still handle what code can’t. But that’s the direction.
He has a line from real POCs that every practitioner will recognize. He spent more time prompt-engineering the agent than it would have taken to build the logic deterministically. Been there.
This is the same loop I described in the last blog. If the LLM handles the same edge case again and again, codify it. Alex’s version just explains why that loop wins over time.
The step you couldn’t write in code
There’s a gap in that picture, though. Some SOC steps are repeatable but fuzzy.
Is this email trying to steal credentials? You answer this thousands of times a week, so it’s repeatable. But you can’t write a regex for it. So today it either goes to a rule or to an LLM call at frontier prices.
This is where Jev fits. Alex calls it the first model in a long time he can see being useful. Classification turns unstructured data into structured data, and that’s the most practical thing AI does for us.
Jev in 60 seconds
Jev is what TypeSafe calls a System One model. You give it a state (an alert, an email, a log line, a ticket) and a set of questions. It returns typed answers with probabilities. It doesn’t reason or generate text.
There are three question types, and each one maps to something your analysts do every day:
Choice picks one option from a list. What type of alert is this?
Score rates something against levels you define. How bad is this for our environment?
Noul asks a yes/no question and returns the probability the answer is yes. Does this email ask for credentials?
TypeSafe says it’s 40x to 200x faster than frontier LLMs on these kinds of queries, with 70 to 500ms response times. Input costs $0.042 per million tokens, and output is free. Those are their benchmarks, not SOC data.
The important part: it’s a model that lives inside deterministic code. It doesn’t replace the code. So it fits the asymptote instead of fighting it.
Walking an alert through it
Take a user-reported phishing email.
Step 1: Deterministic. Parse the email. Extract URLs, sender, attachments and headers. Run reputation lookups, check SPF/DKIM/DMARC, and check your allow lists. The correct operation is known, so no AI needed.
Step 2: Jev. Ask a batch of yes/no questions in one call. Does it ask for credentials? Does it impersonate an internal team or a known vendor? Does the link text match the destination? Is it a newsletter the user subscribed to? The questions run in parallel, so asking 15 instead of 5 barely changes response time.
Step 3: Thresholds in your code. Jev returns probabilities, and your code decides what they mean:
answers = response.answers
creds = answers["asks_for_credentials"].noul
newsletter = answers["is_subscribed_newsletter"].noul
if newsletter > 0.9 and creds < 0.1:
close_as_benign(alert) # deterministic close
elif creds > 0.9:
escalate_and_enrich(alert) # deterministic escalation
else:
send_to_llm_investigation(alert) # the ugly middleStep 4: LLM for the middle. Only the alerts Jev isn’t sure about go to reasoning. That’s where the LLM checks who else got the email, builds a timeline, and weighs evidence that points in two directions.
Step 5: Deterministic enforcement. Purges, blocks and account disables run through code with approval gates.
Deterministic code carries the volume. Jev handles the fuzzy but repeated calls. The LLM gets what’s left, which, if Alex is right, should shrink over time.
Other places I’d put it
Alert routing. A Choice across your use cases (phishing, identity, endpoint, cloud, DLP) sends each alert to the right playbook/agent.
Checking the LLM’s work. Does the agent’s summary support its verdict? Score it before anything acts on it.
Detection tuning. Log every probability. If a detection fires 3,000 times a month and almost all of it gets scored confidently benign, that detection goes on the tuning list.
Your pipeline has to be ready for it
Everyone is racing to ship agentic features. Not many are fixing the deterministic engine underneath.
That matters a lot for Jev. Its whole value is that it returns typed answers you can trust in code. If your SOAR passes loose JSON blobs between steps, you lose that value at the first hop. And a 100ms decision doesn’t help much if the playbook around it needs a container cold start to run.
So before you get excited about a fast model, check your plumbing. A good model on a bad foundation still performs badly.
Who is this actually for
This is a narrow tool, and I think that’s fine.
Most SOC teams won’t call Jev directly. Someone has to write the questions, set the thresholds, wire it into the pipeline, and test it on real data. That fits three groups:
AI SOC vendors, where cost and latency per alert hit their margins
Agent builder and SOAR platforms, which could offer it as a step type
In-house teams with real security engineering capacity
For a three-person SOC, it’s something your vendor might use under the hood, not something you pick up on Monday.
What it doesn’t fix
Type-safe is not correct. Jev can’t return an invalid type. It can still return a wrong answer in a valid type, and a confident 0.95 on the wrong thing still closes the alert. Calibration is TypeSafe’s main claim, and that’s what I want to test on security data.
It doesn’t baseline anything. It only sees the state you give it. “Is this login unusual for this user?” still needs a baseline from the ML tier. Garbage state in, well-calibrated garbage out.
Don’t build an agent with it
Your timeline is full of Jev agents doing tasks at crazy speed. Alex puts it well: no, your “Jarvis” isn’t going to run entirely on Jev. A lot of the demos use it outside what it’s built for.
It has no reasoning and no text generation. It’s a decision inside code, not an analyst.
So, did you kill your AI SOC yet?
If you haven’t, here’s another chance not to.
I’m still testing Jev, so no results yet. I’ll be back with numbers.
Jev won’t investigate anything, won’t baseline your users, and won’t respond to incidents. It answers small questions fast and tells you how sure it is. In a SOC that’s a narrow job. But it’s the job that runs ten thousand times a day, and right now a lot of AI SOCs are paying frontier prices to do it.
The goal is still not to put AI everywhere in the SOC. It’s to know where not to put it.
Check out our SecOps Market Landscape tracker and evaluation frameworks