Context is all the rage in security right now, and most discussions treat context as a data problem: collect assets, identities, and enrichments in a graph and then give it to an agent to figure it out (ie. next-gen SIEM). It’s a good start but it’s only half of the problem. Context isn’t just about data, it’s about the application of nuanced understanding and continual learning.
Context is what a team has learned about its own environment. Security teams know what behavior is normal, which hunts came back empty and why, and what a detection was intended to catch, as well as its tuning history. All of that knowledge involves real context. Unfortunately, many judgments and learnings live in someone's head, an ancient Jira ticket, or a DM, and they can disappear at handoffs between teams.
What security teams need is shared context to create truly institutional knowledge, not a just patchwork of individual knowledge that imitates it. It requires shared memory that every workflow reads from and writes to. Shared context is what lets new hires hit the ground running, prevents knowledge gaps when a senior engineer is on vacation, and keeps track of which suspicious-looking behaviors are actually normal for an individual.
Several vendors claim to offer a context graph, mostly filled with point-in-time configuration data and security tool alerts. They’re mostly collecting the noise that plagues every SOC team. What differs is how Nebulock’s memory gets filled and how it's used. We fill our memory by detecting and hunting for behaviors: the hypotheses, the findings, the paths we ruled out, the baselines we documented along the way, even the hunts that came back empty. Every workflow on the platform reads from that record and writes back to it.
Our own hunters built this record first, our TRACE Graph. The Nebulock DE/TH team ran hypothesis-driven hunts across customer environments, and our threat hunting agent follows the methodology they developed. Two years and 375M+ agentic investigations later, that human-driven expertise shapes how our agents hunt, detect, and investigate.
Nebulock’s TRACE Graph is the heart of our Agentic Cybersecurity Engineering platform, and it’s what creates truly valuable shared context across every security practitioner in an organization. In our TRACE Graph announcement , we explained what’s stored in this system of records (both inputs and outputs). In this post, we’re going to look at why this is so important.
Context powers everything TRACE Graph starts as a baseline for normal and then creates context with every action taken by security teams and their agents. Hypotheses are stored and used as the foundation for future investigations. When a path is ruled out or a hunt returns a negative verdict, that’s stored so every team member shares the same hunt memory. Nebulock’s depth of context means hunt memory doesn’t live with individuals or in closed tickets, and it’s persistently applied to every new workflow bringing real-world feedback to every decision.
Context gaps grow as systems begin to fragment. Every detection has an origin and every future update has its reason. In Nebulock, every detection starts with the context of previously run hunts, and every detection has Detection Versioning to explain tuning changes. If a rule is adjusted because a retrohunt was returning false positives, that becomes shared context for future hunts and detections. If a graph doesn’t share context across security roles (ex: threat hunting, detection engineering, and the insider risk team), it is creating blind spots somewhere in your security practice. The more you automate, the wider these gaps become.
Bolting AI agents onto existing security solutions doesn’t solve the context problem, it only makes it worse. AI can power through piles of data quickly, but if findings aren’t part of a shared memory, SOCs aren’t better for it. Agents without context will triage the same alerts over and over, but do nothing to prevent future attacks and human analysts will learn nothing from them.
Detection engineering agents don’t just do repeated work, they also create work. Without understanding hunt context, without understanding the extent of a detection’s current visibility, and without understanding the history of a rule’s revisions, an agent cannot author high quality rules. Instead, they force lengthy human review and update cycles that can take longer than humans just writing the rule themselves. But with full organizational and environmental context, these agents could be writing rules a senior engineer could simply review and put a stamp of approval on after a simple look at the retrohunt data.
Context loops and frameworks Context must be a continuous loop. Every finding must be fed into every decision or else context is only partial. At Nebulock, our DE/TH team developed and open-sourced two powerful frameworks so that any security team can continually build contextual memory, no matter what security solutions they use. These frameworks articulate how we view context as a discipline and underpin our approach.
Agentic Threat Hunting Framework (ATHF) ensures that teams capture the context of their hunts, organize it, and reuse it across future hunts. It operates on a four-part LOCK pattern that gives orgs a single loop that keeps humans and AI aligned, reduces repeated work, and turns every hunt into a repeatable process.
Agentic Detection Engineering Framework (ADEF) builds detection memory by complementing every rule with a companion markdown journal that logs its purpose, characterization, tuning history, and scheduled review dates. It operates on a five-stage FORGE lifecycle that ensures every decision made during the detection engineering process can be fed back into the larger security context.
Each of those frameworks has its own context, and without a way to share the findings of each, there would just be more fragmentation (albeit very structured fragmentation). This is where the GATES Method comes in. GATES is the bridge from hunt to detection, taking the context back and forth between the frameworks. To be clear, while these frameworks are built into Nebulock and the TRACE Graph, anyone can use these open source frameworks in their own workflows. We encourage you to.
When context is a loop, hunts establish what normal looks like and detections built from them keep the same reasoning. Triage then judges alerts on that same context and analyst findings then augment that context for future hunts. In Nebulock, all findings are shared and then learned from, making all workflows stronger.
TRACE Graph gains and shares context with every workflow in Nebulock This valuable context provided by TRACE Graph is why our agents have a better recall for environmental normality than a traditional tier one or tier two human practitioner (and far beyond a skilled MDR practitioner jumping between customers). It also ramps up faster, building context-aware baselines in hours or days, not the weeks or months it takes humans to build a nuanced understanding of a security ecosystem.
Use cases where more context is needed There are more than a few security use cases where shared context is very necessary.
Insider risk Today, weak signals sit in a UEBA tool, HR context sits elsewhere, and a hunter's conclusion about an employee rarely reaches detection or triage. These gaps provide ample opportunity for citizen hackers to slip through, and why teams are starting to move off of UEBA tools.
With a shared context, each actor (human or agent) has a baseline, and a verdict about that actor is available to every workflow. Being able to conclusively attribute activity back to an actor, and not just the user account or hostID reported by access logs or activity telemetry, is the difference between false positives on normal behavior and false negatives on adversarial activity. It’s also why Nebulock was able to identify an insider who copied 748 source files to USB without tripping a rule.
Hunting from intelligence Teams often accidentally re-hunt behavior they already ruled out because earlier work and conclusions are lost in Slack threads, or worse no conclusion was reached. ATHF's LOCK cycle starts with Learn, which checks the report against what exists in the environment, what normal looks like, and previous hunts on the same behavior, including ones that found nothing.
The Nebulock hunting agent, Vespyr , follows this same methodology, collecting, journaling, and referring to hypotheses, pivots, and the paths that have been ruled out. This makes the agent as much a part of sharing context as human team members.
Intent-aware detections Detection rules usually keep their logic but not the reason they were written, so the next engineer or agent may repeat a change that already failed. ADEF's FORGE cycle starts with Find and Observe, so a detection begins from a hunt and a baseline, and each later change records its reasoning.
In Nebulock, a hunt might pass its hypothesis to our detection agent, and every detection maintains robust versioning so context is there from the start and through the life of the rule. For teams not on Nebulock, the open-source connection between ATHF and ADEF is currently in design preview.
Triage Without shared context, triage becomes loaded with unnecessary repetition and noise that slows response times. If alerts keep unnecessarily firing, context tells teams and agents which detections to adjust and how to adjust them. If real alerts are being buried, context raises them up for prompt investigation.
In Nebulock, our alert triage capability uses the same TRACE Graph-based memory as every other workflow, so verdicts on third-party generated alerts make use of the same shared context.
Where is this all going? More of the SOC’s ‘toil’ today will be done by agents (triaging, hunting, drafting detections) while the role of the human operator will shift towards that of an architect. Set goals, review outputs, make key decisions and evaluate performance over time. This only works if both read the same record. An agent needs to know what the team already ruled out, and an analyst needs to see why the agent reached its verdict. Shared context is where that handoff happens, and it’s the audit trail for it too. The better this record gets, the faster and more effective both the human and agentic systems become.
Not all context is the same Context is not a synonym for data. If it was, those legacy SIEMs and old fashioned MDR services would have already solved this problem.
How many times this quarter has your team made the same call twice? How many times did different team members go down the same path to find similar results? Maybe most importantly, has anyone noticed these duplications of effort? If the answer is, “I honestly don’t know,” you’re not alone.
Adversaries don’t just live in detection gaps and visibility gaps, they also live in context gaps. If one team is investigating a potential attack that another team already has information on, that lack of shared memory creates time for damage and loss.
Real context is living memory that informs every decision and learns from every action. True context makes the combined knowledge and learnings of every human security practitioner and AI agent accessible to the entire SOC. Real context is what Nebulock, TRACE Graph, and our open-source frameworks are built on.
Reach out to see a demo of what real context can do for your SOC.
