Teaching a Machine to Think Like an Incident Researcher

Every security incident starts as a story: a suspicious login, a user accessing sensitive data, or a weak signal buried inside thousands of noisy alerts. In today’s SOC, that story is hidden at an almost impossible scale considering the tens of thousands of alerts a team handles. Once an attacker gains a foothold, every minute matters because they can move laterally, expand access, and widen the blast radius before an analyst reaches the case.

This pressure is driving the growth of AI SOC systems designed to perform meaningful investigative work before a human analyst opens the case. And it’s the challenge guiding the Triage Agent: an autonomous AI agent Varonis built to investigate end-to-end alerts, surface the cases that matter most, and give analysts the context they need to act quickly.

For Varonis, triage is about understanding the data through context: What sensitive information was accessed, by whom, whether the access was appropriate, and whether the activity represents normal work, insider misuse, or malicious exfiltration. This crucial information turns an alert into an actionable security decision.

Why we built the Varonis Triage Agent

Traditional triage relies on rules, hardcoded automations, and traditional machine-learning systems, all of which are an important foundation. But an agent can go further by selecting which evidence to gather next, adapting as new facts emerge, and connecting related findings into a broader incident. 

Our challenge was not simply to rank alerts faster, but to have the agent investigate them with the context and adaptability of an experienced responder. 

Varonis’ context advantage

An agent is only as useful as the context it can reason over. In security, context determines meaning. The same action can represent normal work, careless behavior, or an active attack depending on several different factors like the identity involved, the sensitivity of the data, the user’s permissions, their historical behavior, and the surrounding activity. 

Varonis already had that context within its Data Security Platform (DSP). The agent could investigate identities, permissions, entitlements, behavioral patterns, sensitive data exposure, and related events instead of reasoning over an isolated alert. We also had a large repository of evidence from past incidents that offered real outcomes against which to evaluate the agent.

In other words, we weren’t teaching the system through abstract security theory alone. We could compare its assessments with years of real investigations, identify where its reasoning failed, and use those failures to improve it. But rich security data was not enough. Before the agent could investigate it, that data had to become consistent and available for querying. 

How the agent investigates

Much of the work involved normalizing events from collaboration platforms, email, identity services, networks, and VPNs into a unified schema. This allowed the agent to reason over, for example, “a sensitive file was shared externally” without knowing which system emitted the signal.

The agent also has access to behavioral baselines, including precomputed summaries of how a user typically behaves and which destinations and volumes are expected. This lets it ask, “Is this normal for this user?” without rebuilding the baseline for every alert. A curated catalog explains what each table contains and how to query it.

Handling infinite context

Varonis has an enormous amount of useful context, but useful is not the same as relevant. Loading all available context into the agent for every alert makes the system slower, more expensive, and less accurate because important signals get buried.

To address this, we organized investigations into investigation scenarios, such as data exfiltration, privilege escalation, phishing, and identity attacks. Each scenario identifies the sources, behaviors, and tables most likely to matter, so the agent starts with relevant context and expands only when the evidence calls for it.

This dynamic approach allowed us to match context for more than 300 scenarios without writing tailored instructions for each one. Think of investigation scenarios as providing a focused starting point without turning the investigation into a rigid script.

Forging the mind of an incident researcher

Once we had the data, the next challenge was teaching the agent how to investigate. Answering a question is one problem. Working through an open-ended security case is another.

A good incident researcher forms an initial hypothesis, gathers evidence, looks for contradictions, and changes direction when the facts do not fit. Each finding influences the next step. That became our design target: not an alert explainer, but an agent that follows the reasoning process of an experienced incident researcher.

The central tension we discovered was structure versus flexibility. Too little guidance produced shallow investigations, while too much created the same rigid playbook we were trying to overcome. The agent needed to gather enough evidence, consider alternative explanations, avoid treating every anomaly as malicious, and recognize when reassuring context was not enough to dismiss a real threat.

Building this required close collaboration between security researchers, who contributed investigative methodology and attacker mindsets, and data scientists, who built the orchestration and tool-calling infrastructure. We benchmarked early versions against real outcomes from our MDDR team, evaluating both the verdict and whether the investigation gathered enough evidence to justify it. Those failures became the roadmap.

How we improved the agent

Every run was traced as a step-by-step transcript. Using labeled outcomes, we could test the agent against cases where the answer was already known. Wrong verdicts were especially useful because the trace showed where the reasoning went off course.

The fixes rarely involved changing the model. They involved changing what the agent knew and how it was guided: Sharpening investigative guidance, improving how a table was described, or tightening a prompt so the agent did not jump to certainty too early.

The hard part was restraint. Every mistake invited another instruction, but too many instructions narrowed the agent until it could only follow a predefined path. 

The takeaway: A good tip nudges the investigation — it does not script it. For example, the agent repeatedly flagged file downloads as suspicious without checking whether the files belonged to the user. A hard rule such as “access to your own files is benign” would have created a blind spot when an owner shared sensitive files externally. Instead, we added one nudge: “Before treating file activity as suspicious, establish the relationship between the user and the resource.”

The agent began checking ownership routinely, dismissing benign self-access while still escalating genuine exposure based on the evidence.

Another useful technique was comparing two runs on the same alert, one correct and one incorrect. The difference often came down to a single move: one run checked the source of a suspicious burst, while the other assumed it. That fork showed us exactly what to reinforce.

A real investigation, end to end

It began as an alert few analysts would have rushed to open: A sales employee had pulled thousands of sensitive data files in a short window from an unfamiliar external IP. Large downloads can accompany migrations, backups, and quarter-end reporting, and this detection is among the platform’s highest-volume and noisiest. Rule-based and traditional machine-learning scoring placed the alert below the high-priority threshold. In a queue of tens of thousands, it would have waited.

The agent did not treat the download count as the verdict. It selected which evidence to examine, tested benign explanations, and changed direction as new facts emerged. It started with identity: a known employee in a non-technical sales role, not an administrator or service account. That proved nothing on its own, but it made programmatic collection of thousands of financial documents difficult to explain as routine.

Raw events showed that the downloads came from a Node.js client rather than a browser or managed productivity app, indicating scripted collection. The files spanned thousands of locations the user did not own, and many were labeled confidential or highly confidential. The question changed from “Was there a spike?” to “Why is a sales user scripting the collection of sensitive financial material they do not own?”

A 30-day baseline sharpened the contrast. Before that day, the user’s peak activity was only a handful of files. Network intelligence identified the source as an anonymous consumer VPN endpoint hosted in data center infrastructure. No other user in the environment touched it during the window, ruling out shared corporate egress and tying the concealed origin to this account.

No single fact decided the case. Volume can be legitimate work. A new IP can indicate travel. A scripted client can be sanctioned automation. The combination is what mattered, and what allowed the agent to determine, “The combination of automated collection, concealment of origin, and targeting of highly sensitive financial data provides concrete evidence of mass data exfiltration.”

The agent classified the activity as malicious and critical while recording its limitation: authentication telemetry was unavailable, so it could not distinguish between stolen credentials, a hijacked session, or a deliberate insider.

From isolated alerts to connected incidents

The most consequential move came from looking beyond the ticket it was handed. The agent searched 14 days of detections on the same identity for impossible travel, external sharing, and uploads to personal cloud storage. None appeared. What did appear were two more alerts for the same download rule on the same day: an earlier burst of roughly 440 files and a later one of more than 11,500.

Together, the three windows totaled more than 17,000 downloads. A moderate spike below the priority threshold was one phase of sustained extraction escalating throughout the day.

The agent did not simply group alerts by user. It tested related attack behaviors, distinguished absent signals from contradictory evidence, and assembled the matching activity into a single timeline. This adaptive investigation and incident reconstruction, rather than any single indicator, was the agentic advantage.

The MDDR analyst opened the case with all of that evidence already gathered, confirmed the volume and consumer VPN source, and escalated it for customer action. The final disposition was a true-positive malicious external threat.

The human still owned the decision, but instead of three disconnected tickets, they received one reconstructed incident.

What it took to make the agent useful

This was never simply a model or prompting project. The model, orchestration, tools, and data foundation all mattered. But the system only became useful when those pieces were grounded in the investigative methods of experienced security researchers and tested against real outcomes.

Security researchers identified the questions and relationships a human investigator checks by reflex. Data scientists translated those lessons into tools, context, guidance, and repeatable evaluation workflows. The shared loop between those disciplines, run, inspect, correct, and measure, moved the agent forward.

The result is the Varonis Triage Agent, a product in the emerging AI SOC category that does more than process alerts faster. It begins the investigation earlier, connects evidence across the environment, and gives analysts a defensible starting point instead of a blank page.

In production, the agent has improved analyst efficiency by 35% to 100%, depending on each analyst’s baseline and experience working with it. Moving from machine-learning and playbook-based triage to agentic triage reduced the time required to escalate malicious cases by an average of 16.4 hours per escalation.

Production recall is above 96%. Because Varonis MDDR analysts manually review every trace, fewer than 4% of confirmed attacks were not prioritized by the agent. The agent has already investigated dozens of production alerts, and that number continues to grow.

An accurate agent focused on triage also changes the calculus for detection engineering. When every new detection adds to an overwhelming queue, teams often keep rules narrow to avoid flooding analysts with false positives, sacrificing coverage. With a reliable agent absorbing the additional volume, detection engineers can write broader, more sensitive rules while the agent filters noise and surfaces the cases that warrant attention.

Ultimately, the goal is not to replace human judgment. It is to move analysts away from manually gathering context and toward reviewing evidence, making consequential decisions, and containing threats before the damage spreads.

This post was co-authored by Hadas Shalev. Thank you to Oren Tevet, Yonatan Haldarov, and Amit Daniel for their contributions on the topic.