Everyone Says Context Matters. I Wanted Proof.

Amir Kessler is Director of Product Management at Torq, where he leads the Context Engine and Data Fabric, the layer that gives the AI SOC Platform the organizational context it needs to investigate and act. He joined Torq with its acquisition of Jit, where he was VP of Product. Amir has spent more than 15 years in cyber, starting in IDF intelligence and going on to lead product teams at several security companies.

Before Jit became part of Torq, we built our product on one bet: an AI agent investigating a security issue is only as good as what it knows about your organization, including who an account really belongs to, what a server connects to, and what breaks if it’s compromised.

When Torq acquired Jit in May, I brought that bet into the SOC as the foundation of the Torq Context Graph and promptly hit a wall. “Context” is one of the most overused words in AI SOC marketing. Vendor after vendor claims it, with no details on what their ‘context’ contains and no proof of what it changes. To a SOC leader, my vision sounded like everyone else’s pitch.

So here’s what ours actually is. The Torq Context Graph is a live model of your organization that sits underneath every autonomous triage verdict in the Torq AI SOC platform, and it does three jobs: 

1. Resolves the same person, device, or service across every tool in your stack into a single entity
2. Maps the relationships between them (which service account can reach which privileged group)
3. Computes the conclusions an analyst would otherwise work out by hand, like whether an account is dormant, a host is critical, or a user is a VIP 

All of it is kept current as the organization changes, and agents query it during triage instead of reconstructing it from raw logs on every alert.

That’s what separates the Torq Context Graph from most of what gets sold as context. An inventory tells you what you have, and enrichment adds a few fields to an alert. The graph tells the agent what those things mean together, before it makes the call.

Building context that holds up at enterprise scale is hard: every identity, device, and relationship must be resolved across the whole security stack and kept current as the organization changes. That’s the know-how Jit pioneered. But even a well-built graph doesn’t prove itself. I had to show where it moves the needle for an enterprise SOC. So I stopped making the argument and went looking for proof.

At one customer, the same alert kept firing: a Python script churning through batches of GIS map files. Without context, the Torq Auto Triage agent flagged it as suspicious scripting every time. With context, it came out three different ways, depending on what the graph knew about the user and host behind it. One of the three should have been escalated immediately. I’ll come back to it below.

Proof Starts With Real Alerts

We sampled 400 alerts across customer environments of different sizes and verticals and ran the Torq Auto Triage agent on each one twice: same payload, same model, same instructions. One variable: access to the Context Graph.

The rule was strict. A change in verdict or severity only counted if the graph context appeared in the agent’s reasoning. Anything else was model noise, and we threw it out. Because the Auto Triage agent queries the graph during its analysis to test specific hypotheses, every change leaves a chain-of-reasoning trail: what the agent asked and what it learned.

Nearly One in Four Verdicts Changed

23.9% of verdicts changed. That’s where the risk lives. 23.9% of alerts changed verdict or severity once the agent had organizational context. Roughly one in every four.

That 23.9% is far greater than a rounding error. It’s the slice of the alert queue where the verdict was actually in play, and it’s where a SOC gets hurt. For every alert in it, the verdict, without context, was at risk of being misclassified, requiring human oversight. When that error runs in the dangerous direction, a real threat gets closed as benign or left at the bottom of the queue. That’s how attacks get missed.

The rate varied by environment. The spread tracked one thing: how many of the alert’s users and devices the graph could resolve to known entities. Environments where the graph could identify most of them saw the most changes in verdicts.

Not Every Change Weighs the Same

Context pushed verdicts in both directions. Of the alerts whose verdict flipped between close and escalate, 53% went up to escalate, and 47% went down to close. Those two moves carry very different costs.

Lowering a verdict (e.g., to benign) shrinks the alert haystack. Raising a verdict finds the needle. Both matter, but the second is the reason a SOC exists. Every escalation that context drives is a defender one step closer to a threat that could otherwise have slipped through.

What Moved the Verdicts

Almost none of the deciding signals were a field in a single tool. Each was a join, a path, or a computed conclusion.

Each context layer answers a question analysts already ask:

• Is this expected for this actor? Resolution.
• What does it cost if we’re wrong? Insights: privilege, VIP status, criticality, posture.
• Is this already known? Relationships. Closing here means “don’t escalate twice,” not “harmless.”

The first two did most of the work together. Expected activity, low impact: Close. Unexpected activity, high impact: Escalate now. Everything in between: Review.

One Alert, Three Verdicts

The clearest case was a recurring alert on Python scripts processing map imagery. Without context, these were escalated as suspicious scripting. With context, they split three ways.

A suppression rule or an allowlist would have closed all three, including the one that should ring the Batphone. Nothing in the alert distinguishes them. Everything that does is in the Context Graph.

“Can’t I Just Point an Agent at My Data Lake?”

Your lake probably holds every source behind that table, but lacks what changes the verdict.

• Resolution. In a lake, one person is an Entra object ID, an Okta login, a CrowdStrike owner string, and a ServiceNow caller, with no reliable key between them. The agent would rebuild that match for every alert.
• Relationships. “Tied to a privileged admin group” isn’t a row. It’s a path: host → service account → group → privilege. A lake stores the hops, not the path.
• Insights. Dormant, privileged, VIP, and critical are conclusions, not fields. They must be computed in advance and kept current, not improvised within a triage prompt.
• Rebuilding all of that per alert is also expensive and unstable. The agent spends tokens and time redoing the same joins on every alert, and two runs on the same alert can land on different answers. Whether two records belong to the same person, or whether a host sits on an admin path, should be a stored yes or no that the agent looks up.

Three Questions For Any Vendor, Including Torq

These are sampled, preliminary results. We measured whether and why verdicts changed, not yet whether every new verdict was right. Scoring both runs against analyst-confirmed outcomes is next, and we’ll publish it. I’m holding us to the same standard I’d ask of any vendor.

If a vendor tells you context matters, ask them:

1. Which entities and relationships moved the verdict, and can I see them?
2. Is the context resolved and computed ahead of time, or assembled from raw data per alert?
3. What does the agent do when the data is missing?

If the answer is a claim without proof, keep asking.