Qevlar AI
AI made the SOC faster. The next step is a SOC that learns from every investigation and gets stronger over time. This article is a practical, staged plan for security leaders.
A year ago, the standard way to talk about AI was productivity. The pitch was that it made engineers 20% faster, added copilots to existing workflows, and shipped more software.
Security bought the same story: AI would triage alerts faster, close cases faster, clear the queue faster.
That framing is already dating itself.
Treating AI as a productivity multiplier takes the way you already work and bolts a more powerful engine onto it. The process underneath stays the same. You go faster, but you go faster through a system that was never designed to get better at its job. And in a SOC, faster through a broken process means you never address the root cause contributing to limited outcomes.
The shift separating the teams pulling ahead from the ones standing still is intelligence. We’re talking about a system that investigates deeply on its own, learns from every case it closes, and does the next one better. A SOC built this way keeps getting stronger after everyone has gone home.
Think about what a single investigation actually produces. There is a set of facts about your environment: that a particular detection is noisy here, that a service account signing in at 2 AM is expected, that a CVE on a given asset has moved from theoretical to actively exploited, that a login pattern which looks alarming is routine for one specific user.
That is real intelligence, generated fresh, dozens or hundreds of times a day.
In most SOCs it goes nowhere. The ticket closes and the knowledge stays trapped in the case that produced it. If your best analyst quit last month, and everything they knew about your environment walks out with them, the next analyst will have to start from zero, and the same alert will be investigated for the fifth time.
This is institutional amnesia, and it is the tax on every SOC. It happens because SOCs were built to process alerts, with no scalable mechanism to learn from them. That design made sense when investigations were expensive and analysts were the bottleneck. Frontier AI models changed that math. The investigation itself is no longer a scarce resource. The scarce resource is the ability to operationalize what every investigation uncovers systematically, without a person having to do it.
The clearest way to describe the shift comes from outside security. The pattern is a recursive, self-improving loop with five parts:
.gif)
A sensor layer that takes in signal from the outside world. In a SOC, that is your alerts, logs, and telemetry, the raw material of every investigation.
A decision layer that holds the rules: what the system can conclude on its own, what it must escalate to a human, what it has to log.
A tool layer the system can call: the queries, enrichments, and integrations that let it actually investigate rather than just describe.
A quality gate: the checks, reviews, and human sign-off that keep a bad judgment from silently shipping.
A learning mechanism that watches where the loop worked and where it did not, then feeds the lesson back to the top so the next pass is better.
Run those five steps with a human supervising rather than hand-cranking each one, and the system compounds. It gets more accurate, more calibrated, and harder to fool over time, on its own schedule, including overnight.
Teams running AI triage today mostly sit at the first rung: the SOC is faster, but it resets after every case. Getting from there to a SOC that self-improves is a progression, and each stage delivers value on its own while setting up the next.
.gif)
Speed alone solves the time bottleneck, but it doesn’t allow the system to improve on its own. The foundation of a compounding SOC is investigation that goes past the alert boundary, because that is what generates real intelligence about your environment.
The difference shows up in a real case encountered by Qevlar AI. A CrowdStrike alert catches a suspicious executable on a finance endpoint. The file is quarantined, the endpoint looks clean, and the instinct is to confirm the verdict and close the ticket. Enrichment would do exactly that, and it would be correct and dangerously incomplete.
Treating that alert as a starting point rather than a conclusion, Qevlar's investigation engine followed the observables outward: from the file, to a zip archive downloaded minutes earlier, to the user identity authenticated during the drop, to a VPN sign-in from a Tor exit node using a stolen session token that bypassed MFA, to the phishing email that delivered it, to a campaign that had hit 40 employees over several days. Seven observables that were not in the original alert. What looked like a closed ticket was an active account takeover with an attacker already inside. Two proprietary engines did work generic tools miss: TrueSignal flagged the archive as malicious when VirusTotal returned only 3 detections out of 72, and QevlarEye's semantic analysis confirmed the phishing email. The whole chain took about three minutes.
.gif)
Identity is where this depth matters most. Credential abuse shows up in 39% of breaches, but no team has time to investigate sign-in behavior on every alert, so alerts get triaged at face value and attackers move laterally. Qevlar’s Identity Hunt closes that gap: on every investigation involving a user, it builds a per-user behavioral baseline from roughly 30 days of authentication logs, runs rule-based detection for patterns like brute force, IP cycling, and impossible travel, then weighs the evidence and returns a verdict with attack pattern and reach. It runs automatically, even when the alert was never about identity in the first place.
What the team gets at this stage: verdicts you can trust, the full blast radius of an attack instead of a single quarantined file, and investigations rich enough to be worth learning from.
Real attacks rarely arrive as one critical alert. They arrive as a handful of low and medium ones scattered across email, identity, endpoint, and cloud. According to Qevlar’s internal research, across investigations in more than 1,500 companies, 34% of alerts in the low and informational buckets turned out to be malicious once investigated end to end. Handled one ticket at a time, a multi-stage attack stays fragmented across separate queues, and the SOC reassembles it by hand, usually after the fact.
The loop's sensor layer gets sharper when it works at the level of the incident rather than the individual alert. Because each alert is investigated end to end first, the correlation has a full set of observables to match against, not just raw payloads.
What the team gets at this stage: campaigns caught that single-alert triage fragments, prioritization tuned to the actual threat and the actual environment, and a queue built from real incidents rather than raw alert volume.
Now the learning mechanism engages. When an analyst disagrees with a verdict, they are telling you something true about the environment. Today that signal dies in a comment box. Closing the loop means the analyst explains the call in one sentence, and the system extracts the observables, the reasoning, and the verdict implication, then writes it back as structured, scoped context. Every future investigation touching the same host, user, or process inherits it automatically. The judgment does not evaporate. It goes to work.
The governance point is essential and non-negotiable. Analysts do not lose control; they gain leverage. Every context item is inspectable and editable before it goes live, and nothing reaches a live verdict without an admin reviewing and approving it.
Qevlar’s ITSM integrations extends the same idea to work you have already done: closed cases in your case-management system become live decision context, so verdicts reflect your team's actual definition of malicious rather than a generic one.
What the team gets at this stage: the same false positive stops coming back, verdicts get more consistent, and knowledge survives shift changes and departures.
Once corrections are flowing, the system has enough signal to spot patterns no single case would reveal. Reading across hundreds of closed investigations, it finds behaviors that keep resolving the same way and drafts them as context for review. The scanning no analyst has time for happens on its own. Institutional knowledge that used to depend on one experienced person remembering to write it down now gets proposed automatically, as a draft, for a human to approve or reject.
And before anything ships, the reviewer sees its blast radius: every alert from the recent past the rule would have matched, replayed through the full investigation pipeline, with a per-alert verdict diff showing exactly how conclusions would change and why. The "will this break something?" fear that usually stalls this kind of automation is answered with evidence before deployment, not discovered after.
What the team gets at this stage: the SOC compounds its own institutional knowledge with no dedicated context-engineering time, and every change is validated against real history before it goes live.
A mature loop does not stop at investigation. The same intelligence flows outward. Into detection engineering, where patterns across investigations become tuning recommendations that cut noisy detections off at the source. Into response, where each closed investigation ends with a prioritized, outcome-specific set of next steps against the right entity, so resolution is as structured as triage. Into vulnerability management, where the SOC's evidence of active exploitation connects to your CVE list, so the SOC and vulnerability teams finally prioritize risk from the same picture instead of two disconnected ones.
What the team gets at this stage: improvement is no longer confined to the investigation queue. The whole security function gets sharper with every case, and teams that worked in silos share one compounding source of truth.
For each type of alert, the system tracks an alignment score: how consistently its verdicts have matched what your analysts decide. That score is a measured track record, built case by case. Once a category of alert has earned enough trust, the system surfaces it as a candidate for automation, and only then can a human choose to let it run end to end: remediation, stakeholder communication, and ticketing handled without a person in the loop for that bucket.
The order matters, and it is the opposite of how legacy automation works. Traditional SOAR asks you to write playbooks up front and trust them before they have proven anything. Here, trust comes first and automation follows it. A human decides which buckets have earned autonomy, configures the automation, and can pull it back at any time. The high-volume, well-understood work runs on its own overnight. Everything the system has not earned trust on still comes to a person. In Qevlar AI’s case, if alignment goes down, we warn you and help build the context needed to rectify it.
What the team gets at this stage: the routine, proven work handles itself around the clock, and analyst attention is freed for the cases that have not earned automation, which are exactly the ones that need a human.
When the loop runs across every function with humans supervising rather than driving, the center of gravity of the analyst's job moves. The routine, repetitive, high-volume work is handled, and keeps improving on its own. What is left is the work that genuinely needs a person: novel situations, ambiguous high-stakes calls, the judgment no baseline can encode, and the governance of the loop itself.
This is the honest version of the destination. The analyst stops being the conduit every piece of information has to pass through, and becomes the point where the system's intelligence makes contact with the hard, human, high-consequence decisions. That is a better job, and a stronger SOC.
There is a simple test for where your SOC actually stands. Is your defensive posture measurably stronger today than it was six months ago, as a direct consequence of every investigation your team ran in between?
If the honest answer is no, then all that investigation work produced knowledge that evaporated the moment each ticket closed. The queue is just as long, the context just as thin, and the next alert starts exactly where the last one ended.
The raw material for a posture that heals and improves continuously is already sitting in your SOC. It is in every case your team closes. The only question is whether your architecture lets it compound, or throws it away one ticket at a time.
That is the shift worth making: towards a SOC that learns.
On July 30, at 5 PM (CET) / 11 AM (EST) we will show you how Qevlar AI can help your SOC shift to the self-improving stage. Sign up here: https://www.qevlar.com/after-ai-triage
