Grounding the AI SOC: The Context Graph Problem

David Melamed is Head of Emerging Technologies at Torq. He joined through Torq’s acquisition of Jit, which he co-founded and led as CTO since 2020, building agentic security on a production Context Graph. A cloud security veteran with 20+ years of experience, David previously held senior technical roles at Cisco (via the CloudLock acquisition) and MyHeritage.

I spent a couple of years at Jit building security agents, and the lesson that stuck wasn’t about the models. It was about what the models stand on. 

The SOC’s problem was never a shortage of reasoning. It’s a flood of noise with no shared memory. In the SANS 2025 Detection and Response Survey, 73% of teams named false positives their single biggest detection challenge. The average breach still took 241 days to contain, per IBM’s 2025 Cost of a Data Breach report. Drop a smarter agent into that, and you get faster wrong answers.

That gap is the real story of the agentic SOC, and it’s an engineering problem, not a model one. Everyone now claims their AI agents are “grounded in context”; far fewer can say what that context costs to keep correct. Having built one in production, I can tell you what good looks like — and what it takes to build.

What CISOs Should Demand From the Layer Underneath the Agents

Strip away the vendor language, and good grounding is simple: a living model of your environment that an agent can reason on, and you can audit. Four properties separate the context you can trust from context that quietly goes wrong.

1. Current, not a snapshot. Context decays: ownership changes, services get decommissioned, exceptions expire. A graph that was right at ingestion is wrong by the next alert. The test isn’t whether the data were fresh when you loaded them; it’s whether they’re true when the decision is made.
2. Traceable. For any recommendation, the system should show what it knew, when it knew it, and where it knew it. That’s why 90% of leaders in Torq’s 2026 AI SOC Leadership Report said explainable AI decisions matter most.
3. Decision-capturing, not just topological. That a user connects to a device is inventory. Why your senior analyst closes an alert the SOP says to escalate is judgment, and judgment is what walks out the door when they leave.
4. Isolated. This layer encodes your most sensitive truth: who’s privileged, what’s exempt, where the gaps are. It has to stay yours.

The field bears this out. Practitioners in that same survey rated generative AI tools their least satisfying category of tooling: adoption is real, trust lags. Yet IBM found that teams using AI and automation extensively had average breaches of $3.62 million, compared with $5.52 million for those that didn’t. Grounded AI pays off; ungrounded AI disappoints.

How Torq Grounds Its Agents in a Context Graph

In the Torq AI SOC Platform, that layer is the Context Graph: a live model of your environment every agent reasons on, not a static store each agent re-derives. Torq’s acquisition of Jit — the team I led — brought in a context graph already running in production, moving Torq from a platform that enriches alerts to one that acts on the full story of a case.

The Context Graph doesn’t just inventory what exists; it encodes what it means. Craig and John have the same laptop, and the same alert fires on both. But Craig is a contractor with read-only marketing access; John is a finance director with access to the M&A data room. Same signal, different verdicts. 

The critical part here is the decision layer: every verdict, exception, and SOP deviation is stored as a queryable object, not buried in a case note nobody reads. Run it long enough, and the graph reflects how your SOC actually operates, not the runbook from two years ago.

How the Context Graph Works Under the Hood

Four engineering choices decide whether a context graph is trustworthy or just decorative: how it keeps time, how it represents meaning, how it records decisions, and how agents read it without hammering your source systems. None of them is solved by a bigger model.

1. Bitemporal Time: Replayable Context Graph Verdicts

Every fact carries two clocks: when it was true in the world (valid time) and when the graph learned it (transaction time). That bitemporal model is what makes a verdict replayable. An agent reconstructs the graph as of the moment the alert fired. It reasons against what was true then, not today’s view projected backward onto a two-week-old event.

Facts expire on their own: an exception with a valid-to date in the past stops shaping verdicts the moment it lapses, with no cleanup job required. Where a source streams changes, the graph updates within seconds; where it doesn’t, scheduled reconciliation diffs the source and patches what moved. The goal is to maintain one current, materialized view of the environment rather than re-derive it from scratch on every alert.

2. Typed Meaning, Not Generic Links

The edges carry semantics. Not a vague “related to” but rather “approved by,” “governs,” “grants access to,” “depends on” — the actual operational relationship between two nodes. Policies, access controls, and retention rules live in the graph as queryable nodes too, not as prose buried in a wiki. 

That lets an agent traverse a real question — who can approve an exception for this asset, which policy governs this data, what gets exposed if this identity is compromised — as a graph query with known semantics, instead of inferring it from free text and hoping. Typed structure is what turns a diagram into something an agent can plan over.

3. Decisions as First-Class Nodes

This is the part most platforms never build, because it’s a data-model problem, not a feature you can bolt on later. Every verdict, exception, override, and escalation becomes a node in its own right. Each carries who or what made the call, the context available at the time (linked to the as-of state of the graph), the SOP it followed or broke from, and the outcome. 

That captures the delta between the written process and what your team actually does — the institutional knowledge that normally lives in senior analysts’ heads and Slack threads, and leaves with them. An agent that only knows your playbook is brittle; one that also knows when your seniors override it, and why, is one the team can work alongside. It’s also what the next agent recalls: a new alert gets triaged against the decisions your SOC already reached on ones like it.

4. Read the Graph, and Keep It Yours

Re-querying the SIEM, EDR, and IAM from scratch on every alert is slow, costly, and punishing to the systems you depend on. Torq’s AI agents reason from one shared, current, normalized layer, so investigations compound instead of restarting at zero, and every action traces back through the reasoning chain to the decision behind it. 

And because that layer encodes your most sensitive operational truth — who is privileged, what is exempt, where the gaps are — isolation is an architecture decision, not a config flag. Each tenant’s graph is its own store, learning stays per customer, and your data never enters a shared pipeline.

Where Context Fits in the Agentic SOC

The grounding layer, not the model, is where the real work of the AI SOC happens. You can swap the reasoning engine next quarter. What compounds over time is the graph that knows your environment, remembers your team’s decisions, and stays true as both change — and it’s the foundation most platforms skip, because it’s hard to build and harder to keep correct.

This is the first post in our series on Context, Memory, and Learning in the AI SOC. The next will introduce recall memory: how Torq pulls the most similar past cases to reach an automated verdict on a new alert, triaging it from what your SOC has already decided.

See what 450 security leaders said they want from AI in the SOC — and how to tell the platforms that can deliver from the ones that can’t.