The Rise of AI Decision Models in Cybersecurity: Why Context Still Dictates Success

The artificial intelligence landscape is shifting at a breathtaking pace. In the span of a single month, an entirely new category of AI model has gone from nonexistent to ubiquitous across the tech sector. On September 15, TypeSafe AI released Jev, branding it as a "System One" model in a direct nod to Daniel Kahneman’s framework of fast, intuitive human thinking. Shortly thereafter at DevDay, OpenAI announced its own Decisions API, opening a public beta on October 6. Concurrently, developers began publishing open-source alternatives, such as Cribl’s cribl-decision LoRA adapter designed for local execution, alongside other open-source tooling like Laya.

Unlike traditional generative AI architectures that compose open-ended paragraphs of text, these specialized decision models bypass text generation entirely. Security engineers and automated pipelines feed them a specific state alongside a set of typed questions. In response, the models deliver a discrete choice, a numerical score, or a definitive yes-or-no verdict accompanied by a calibrated probability.

For security operations center (SOC) teams drowning in alert fatigue, this development represents some of the most welcome news of the year. However, industry experts caution that much of the ongoing technical conversation is currently focused on the wrong layer of the architecture.

Why a SOC Should Be Excited

Three distinct properties make these newly minted decision models a remarkably natural fit for automated alert triage within enterprise security environments.

First, these models yield a hard numerical metric that organizations can readily automate against. When an automated pipeline asks a decision model whether a specific incoming security alert is benign, it receives back a calibrated probability score. Security teams can establish clear automated thresholds: alerts with a benign probability above 0.97 can be safely closed automatically, while those falling below 0.60 are treated as high-priority incidents and immediately escalated to human analysts. Anything sitting in the intermediate grey area can be routed for a closer look. TypeSafe has even suggested enforcing stricter thresholds for irreversible actions, a principle that maps neatly onto the distinction between closing a ticket, adding a comment, or forcibly disabling a compromised user account.

Second, the operational economics have shifted dramatically. Jev, for instance, has been priced at approximately $42 per billion input tokens, delivering response latencies ranging between 70 and 500 milliseconds. Consider a mid-sized enterprise that encounters roughly 450,000 security alerts annually. Even when feeding several thousand tokens of contextual data into the model for every single alert, the total annual model expenditure lands around one hundred dollars. Consequently, the long-standing economic argument for cherry-picking alerts and investigating only high-severity events has effectively evaporated.

Third, every single verdict generated by these models becomes a structured, easily auditable record. Because the output space is strictly fixed in advance and carries its own inherent probability score, security teams can log every automated decision, replay the event timeline later, and compare the model’s judgment against actual historical outcomes. This structured trail is infinitely easier to audit than evaluating paragraphs of free-form, generated reasoning from a general-purpose chatbot.

Of course, a critical caveat remains. When security vendors claim these models "cannot hallucinate," they simply mean that the output will always strictly conform to the predefined schema. A perfectly well-formed, schema-compliant answer can still be entirely wrong.

A Calibrated Guess Is Still Just a Guess

The foundational rule of computing remains stubbornly intact: garbage in yields garbage out.

Model calibration is fundamentally a promise about a statistical distribution. When a well-calibrated model assigns a 90 percent confidence score to a prediction, it means that across a vast historical dataset of inputs matching that exact profile, the model is correct roughly 90 percent of the time. The crucial question, therefore, is what that specific input actually entails. If the input data consists solely of a generic alert title and a baseline severity field, the model is only calibrated regarding alerts that share that exact title and severity level. It possesses zero inherent awareness of the underlying host machine, its network topology, or its recent activity.

This limitation carries profound real-world consequences. Industry data covering over 25 million alerts triaged across customer environments reveals a striking pattern. Out of millions of incoming signals, tens of thousands of alerts underwent live memory scans directly on the endpoint. Thousands of those scanned machines harbored active, malicious infections. Crucially, more than half of those infected machines had already been automatically reported as safely mitigated by standard Endpoint Detection and Response (EDR) platforms.

Consider what a decision model observes when evaluating an alert generated under those conditions: malware detected, threat successfully quarantined, and a low overall severity rating. A perfectly calibrated model should logically close the alert with high confidence, because the vast majority of historical alerts matching that exact profile are indeed benign false positives. The model performed its designated job flawlessly; the underlying input data provided to it was simply incomplete or misleading.

Severity metrics suffer from a similar flaw at scale. Approximately one percent of genuine, highly dangerous security incidents traced back to alerts cataloged at the absolute lowest severity levels. In an enterprise environment processing 450,000 alerts a year, that translates to roughly 54 real, active threats slipping through the cracks—amounting to about one active security incident missed every single week. Cribl’s own model documentation addresses this transparently, noting that such models can exhibit overconfidence and remain acutely sensitive to how prompts and candidate choices are worded.

What Evidence Actually Looks Like

In many ways, investigating a cybersecurity alert mirrors a criminal forensic investigation. An investigator can describe a crime scene to a general-purpose chatbot in broad, abstract terms and receive a plausible theoretical narrative. Alternatively, they can bring in the DNA lab, analyze fingerprints, review hard forensic evidence, and examine witness statements. No one questions which of those two approaches will reliably identify the correct suspect.

Security investigations operate under the exact same principles. This methodology—often referred to as Security Context Engineering—revolves around a core mandate: transforming a raw, unverified alert into a comprehensive set of verified facts before any human analyst or automated model makes a definitive call.

When evaluating core investigative questions, raw alerts typically provide minimal surface data. For instance, when asking what process executed on a system, a standard alert might simply flag "Suspicious PowerShell." Comprehensive forensic evidence, by contrast, exposes the full process tree, the parent process, the complete command-line arguments, and the exact script file residing on disk. When asking what the execution actually accomplished, an alert usually offers only a file hash and a generic reputation score. Forensic analysis reveals what the executable actually did when actively detonated in a secure sandbox, detailing its network connection attempts and the secondary files it dropped onto the system.

Furthermore, relying solely on EDR platforms to confirm whether a threat is still present on a machine can be dangerously misleading. While an EDR might report a status of "mitigated," live memory scans frequently uncover injected code, living-off-the-land binaries, or stealthy fileless payloads residing entirely in volatile RAM. Similarly, identifying a user through a simple username offers little insight compared to mapping out where they authenticated, from which specific device, and whether that access pattern aligns with their established historical baseline.

The most prevalent malicious families recovered from endpoint memory—such as specialized offensive tools designed specifically to operate without touching the disk—are engineered precisely to evade file-based quarantine statuses. Collecting this depth of evidence automatically, for every single incoming alert, and completing the process in under a minute remains the primary engineering hurdle for modern SOCs.

The Hardest Context Is What "Normal" Looks Like

While forensic evidence clarifies what physically transpired on a given machine, it cannot automatically determine whether that behavior is expected or permissible within a specific corporate culture.

Identity-related alerts highlight this persistent visibility gap. Across enterprise telemetry, the vast majority of identity alerts are routinely classified as likely benign. For instance, impossible travel alerts are confirmed as actual account compromises in only a tiny fraction of cases, with routine corporate VPN usage driving a substantial portion of the false positives. A standard AI model cannot inherently know that a specific financial analyst routinely logs into corporate resources while traveling, or that a recurring security alert on internal build servers fires harmlessly every single time the DevOps team deploys a software update. That institutional knowledge typically resides exclusively inside the minds of veteran security analysts, leaving the organization vulnerable when those individuals transition out of the company.

This organizational context is uniquely difficult to manage for two primary reasons. First, it cannot simply be purchased off the shelf, as it is entirely unique to each individual corporate environment. Second, it constantly decays; digital assets, user roles, and internal tooling shift week by week. A static baseline snapshot loaded during employee onboarding becomes stale within a single quarter.

Consequently, organizational context must function as a continuous feedback loop. Security systems must learn from historical casework and observe how human analysts resolve specific edge cases. They must pull live, dynamic context mid-investigation when technical forensic data alone proves insufficient. Finally, systems must continuously compare every automated verdict against its real-world outcome, writing those lessons back into the organizational memory to ensure that a statistical confidence score remains accurate in practice rather than merely looking good on theoretical industry benchmarks.

A Forensic Approach to Alert Triage and Investigation

Organizations grounded in reverse engineering and incident response often adhere to a foundational operational rule: collect the deep forensic evidence first, and only then render a decision. Implementing this philosophy requires combining several layers of deterministic analysis and organizational memory.

Code-level evidence collection involves comparing every piece of binary code executing in system memory against extensive databases of trusted and malicious signatures, catching both known malware variants and novel code reusing known threat components. Coupled with automated live memory forensics triggered whenever an alert lacks sufficient context—or when indicators point toward fileless attacks or process injection—security platforms can uncover hidden threats that standard monitoring tools miss entirely.

This technical rigor must be paired with robust organizational memory systems designed to answer environment-specific questions. By maintaining both procedural knowledge regarding how a security team investigates and closes detections, and declarative knowledge mapping out company assets, user behavioral baselines, and SIEM schemas, platforms can learn dynamically from past case histories.

By unifying deterministic forensics with decision models that streamline the final evaluation step, organizations can scale their triage capabilities across millions of alerts while maintaining high accuracy and minimal escalation rates. Regardless of which specific AI model sits at the end of an automated pipeline, the engineering effort must remain focused where it matters most: building comprehensive evidence collection and capturing organizational knowledge. Frontier models will continue to evolve rapidly, but the internal context fed into those models remains uniquely yours.