New AI Decision Models Arrive in SOCs: What It Means
In weeks, decision models for SOC platforms have appeared. We analyze what they are, why they matter to an SMB, and how to evaluate them without falling for the hype.
4 min read

In this article
There are movements in the world of cybersecurity that, due to their pace, go unnoticed by most SMBs. This is one of them. In just one month, a new category of artificial intelligence models aimed at decision-making within SOC (Security Operations Center) platforms has been born. And although at first glance it sounds like something reserved for large corporations, it is worth understanding what is happening because it will eventually reach the tools we already use.
What exactly happened
According to The Hacker News, TypeSafe AI launched Jev on September 15 and labeled it as a "System One" model, referring to Kahneman's idea of fast and intuitive thinking. Shortly after, OpenAI announced its own Decisions API during DevDay and opened a public beta on October 6. In parallel, Cribl released cribl-decision, an open LoRA adapter that can be run locally. And there are more players, such as Laya, moving in the same direction.
The relevant thing is not each announcement separately, but the pattern: in a matter of weeks we have gone from having nothing to having several alternatives competing for the same slot. That slot is the layer where AI not only detects or classifies, but decides: prioritizes alerts, suggests responses, discards noise and, in some cases, executes actions.
Why this matters more than it seems
A modern SOC, even that of a medium-sized SMB that outsources part of its monitoring, lives overwhelmed by alerts. The promise of these models is to reduce that noise and accelerate response. So far, so good. The problem appears when that decision stops being a suggestion and becomes an automatic action on real systems.
If a model decides to block an account, isolate a server or close a port, the operational impact is immediate. And if that decision is wrong, the SMB not only loses time: it can lose service, customers or data. It is a terrain we have already seen in other contexts, such as when we analyzed the powerful Gemini 4 Argon agents and their permission problems: power without control is paid for dearly.
The detail of "System One"
The reference to Kahneman is not accidental. A System One model prioritizes speed and intuition over deep analysis. In a SOC that is attractive because speed matters, but it is also dangerous: quick decisions are the ones that make the most mistakes when the context is ambiguous. And in cybersecurity, the context is almost always ambiguous.
The alternative, a more deliberative approach, takes longer but makes fewer serious mistakes. The key will be how both are combined and, above all, who has the final say.
What we recommend to an SMB or an IT team
There is no need to rush to adopt any of this tomorrow. But it is worth preparing. These are the lines we are working on with our clients:
- Define what decisions AI can make and which it cannot. A clear document, even if it is one page, avoids scares. Blocking a suspicious IP is not the same as disabling an executive's account.
- Demand traceability. If a model decides something, what it saw, what it concluded and why must be recorded. Without that, auditing an incident is impossible.
- Test locally when possible. The existence of open adapters such as cribl-decision allows experimentation without sending sensitive data to third parties. It is an interesting path for teams with limited resources.
- Review integration permissions. These models connect to SIEM, EDR and ticketing. Each connector is a door. Applying least privilege is not optional.
- Do not confuse trust with validation. It is a mistake we have already pointed out in the forensic field: the fact that a model is often right does not mean it is validated for your specific environment.
A context that gets complicated
This movement comes at a delicate moment. The attack surface keeps growing: OT/IoT convergence, attacks on repositories such as the recent one on GitHub, failures in widely deployed software. Automating decisions in that scenario can be a relief or a risk multiplier, depending on how it is done.
The question is not whether your SOC will use decision models, but who will assume responsibility when the decision is wrong.
Our recommendation is pragmatic: start by understanding what decisions you make manually today and which would be candidates for automation with supervision. Leave irreversible actions out, at least for now. And when you evaluate a tool, ask yourself not only what it does, but what happens when it fails.
The category has just been born. In six months there will be consolidation, probably some loud crash and learnings we do not have today. Reaching that point with your homework done will make the difference between riding the wave or suffering it.
Source: The Hacker News. Analysis and adaptation: ForgeNEX.
Keep reading
- ThreatsDay: Adobe RCE, DNS Wallet Theft, and Container Escape16 October 2026
- OT and IoT: the convergence that multiplies industrial risk16 October 2026
- Microsoft knew about data theft for AI, according to lawsuit16 October 2026
- Gemini 4 Argon: powerful agents, but watch the price and permissions15 October 2026
- AI in forensics: confidence is not validation15 October 2026