SentinelGraph: Building an AI Cybersecurity Investigation Agent with FalkorDB

Parnika S M — Sun, 18 Oct 2026 17:53:08 +0000

From scattered security signals to explainable investigations—with graph traversal, evidence paths, historical context, and human-reviewed actions.

Every Alert Is a Clue

A suspicious login. An unusual process. A server communicating with an unfamiliar IP address.

Individually, these events may tell us very little. But what if the same device, account, or internal server connects multiple alerts?

That is where a security investigation gets interesting.

My teammate and I built SentinelGraph, a graph-powered cybersecurity investigation agent using FalkorDB, FastAPI, and Next.js. It explores relationships between security alerts, retrieves connected evidence, surfaces multi-hop paths, and presents proposed response actions for human review.

Instead of treating every alert as an isolated event, SentinelGraph investigates the relationships around it.

The central idea is simple:

Don't just show the alert. Explore the connections that help explain it.

SentinelGraph is a demonstration project using synthetic security data and simulated response actions.

1. The architecture: From alerts to investigation

SentinelGraph brings together a security alert queue, an investigation workflow, a graph database, and a visual interface.

At the centre of the system is FalkorDB, which stores the relationships that connect alerts, devices, evidence, incidents, and historical investigation memory.

The main components are:

FalkorDB: Stores connected security entities and supports graph queries and relationship traversal.
FastAPI: Exposes backend endpoints for investigation and related operations.
Next.js and React: Provide the interface for exploring alerts, evidence, and investigation results.
Graph visualisation: Helps analysts inspect relationships and follow evidence paths.
Human-reviewed response workflow: Presents proposed actions for review rather than silently executing real remediation.

The point of this architecture is not simply to draw a network of nodes. It is to use the relationships stored in the graph to support the investigation itself.

2. Why use a graph for cybersecurity?

Security data is naturally connected.

A single alert might reference a device. That device might communicate with a server. The server might appear in another alert. An earlier incident might contain similar evidence.

Looking at each event separately can hide these relationships.

A graph represents entities as nodes and their connections as relationships. This makes it possible to explore how evidence is connected across multiple steps.

For SentinelGraph, this means we can investigate questions such as:

Which other alerts are connected to this device or server?
Is there a path linking two seemingly separate security events?
What evidence supports the proposed relationship?
Which candidate alerts are not connected through the explored graph?
Is there relevant context from a historical incident?

FalkorDB provides the connected-data layer that makes these questions practical to explore.

The important distinction is that a connection is a lead for investigation, not automatic proof of an attack.

3. Following the evidence: A suspicious sign-in

Let's look at one of SentinelGraph's investigation examples.

The selected alert is ALR-2026-10-0011, representing a suspicious sign-in.

Rather than stopping at the alert itself, the investigation explores the entities associated with it and follows a multi-hop path through the graph.

One of the surfaced paths is:

ALR-2026-10-0011 → dev:fin-ws-1042 → dev:srv-payments-01 → ALR-2026-10-0012

This path connects the suspicious sign-in alert to a workstation, then to a payments server, and finally to another alert.

Why does that matter?

Because the second alert may provide context that the first alert cannot provide on its own. The shared path gives an analyst a concrete lead to examine rather than forcing them to compare isolated events manually.

The graph also makes the relationship easier to inspect. Instead of relying on an unexplained statement that two alerts are related, an analyst can see the entities and intermediate connections that form the path.

This is the kind of investigation where graph traversal adds value: it exposes the route connecting pieces of evidence.

A path alone does not establish that an incident has occurred. Its significance still depends on the underlying evidence, the nature of the relationships, and the analyst's judgement.

4. When an alert does not connect to the others

A useful investigation system should not only surface connections. It should also help explain when a connection has not been found.

Consider another example in SentinelGraph: ALR-2026-10-0013, associated with an XMR miner on a marketing laptop.

In this investigation, no other alert is connected through the explored internal entities within four hops.

That is a different result from the suspicious sign-in example.

Rather than inventing a relationship to force the alert into a larger incident, SentinelGraph presents the investigation outcome alongside excluded candidates, observed facts, and evidence gaps.

This distinction matters.

An alert that has no discovered connection within a particular search scope is not necessarily harmless or unrelated to every other event. The connection might exist outside the explored depth, through an entity that has not been recorded, or in evidence that is not available to the system.

For this reason, the result should be interpreted narrowly: no qualifying connection was found within the explored scope.

This is one of the principles behind explainable investigations. A system should communicate not only what it found, but also the limits of what it searched.

5. What graph queries contribute

Cypher is the query language used to describe patterns in graph data. A query can specify a starting node, the relationships to explore, and the paths to return.

For example, the following is an illustrative Cypher query showing the general idea of exploring paths from a particular alert:

MATCH (a:Alert {id: 'ALR-2026-10-0011'})
MATCH p = (a)-[*1..3]-(e)
RETURN p
LIMIT 25

This example starts from an alert and looks for paths of one to three relationships, returning paths for inspection.

It illustrates the graph-querying concept; it is not presented as the exact production query used by SentinelGraph. Actual query patterns depend on the graph schema, relationship types, filtering requirements, and investigation logic.

The broader idea is what matters: a graph query can retrieve connected context rather than requiring every relationship to be manually joined together in application code.

For a cybersecurity investigation agent, that connected context becomes the foundation for presenting evidence and explaining candidate relationships.

6. Evidence before conclusions

An AI-powered investigation tool should not merely produce a confident-sounding summary. It should help users understand why a conclusion or recommendation is being presented.

SentinelGraph brings together connected paths, observed evidence, candidate groupings, exclusions, and evidence gaps to make investigations easier to inspect.

This supports a more careful workflow:

Start with a selected alert.
Explore relevant relationships in the graph.
Inspect the paths and evidence surfaced by the investigation.
Evaluate which other alerts may be related.
Review the resulting explanation and any remaining evidence gaps.
Consider the proposed response actions.

This workflow does not eliminate uncertainty. It makes that uncertainty easier to investigate.

A relationship between two alerts may be meaningful, incidental, or insufficient to establish a shared incident. The interface should help analysts evaluate that distinction instead of hiding it behind a single score or summary.

That is why explainability is not just a visual feature in SentinelGraph. It is part of how the investigation results are presented.

7. Historical context and human-reviewed actions

Current evidence is not the only useful source of context.

Previous incidents can contain information that helps an analyst understand a new alert. SentinelGraph includes historical incident memory as part of its investigation workflow, allowing relevant past context to inform the investigation.

The system also presents proposed response actions.

However, recommending an action and executing it are different things.

SentinelGraph keeps the response workflow behind a human review step. An analyst can evaluate a proposed action before approving or rejecting it.

For a cybersecurity tool, this distinction is important. An incorrect recommendation should not automatically become a disruptive action against a real system.

The project uses synthetic security data and simulated response actions. It demonstrates an investigation and review workflow rather than claiming to provide production-grade automated incident response.

8. The technology behind SentinelGraph

Our implementation combines several technologies, each serving a distinct purpose.

Technology	Role
FalkorDB	Graph storage and connected-data queries
Cypher	Expressing graph patterns and relationship traversal
FastAPI	Backend API and investigation workflow
Next.js	Application framework for the frontend
React	Building the interactive interface
Graph visualisation	Exploring relationships and evidence paths

The most important architectural decision is that the graph is part of the investigation process itself.

FalkorDB is not included merely to display a network diagram. The relationships stored in the graph provide connected context for exploring alerts, tracing paths, and retrieving relevant historical information.

The frontend makes those results accessible, while the backend coordinates the investigation workflow.

9. What we learned

Building SentinelGraph reinforced a few important lessons for us.

Connected data is only useful when it answers a question

A graph can contain many nodes and relationships, but displaying all of them does not automatically help an analyst.

The investigation needs to begin with a useful question and surface the relationships relevant to that question.

A visible evidence path is better than an unexplained claim

When a system identifies a possible relationship, showing the path that supports it gives the user something concrete to inspect.

This makes the result easier to understand and challenge.

Missing evidence must remain visible

Not finding a connection is different from proving that no connection exists. Search depth, graph coverage, and available evidence all affect the result.

Communicating those limits is essential for avoiding overconfident conclusions.

Human oversight still matters

Even when a system can identify relevant relationships and propose actions, consequential responses should remain reviewable.

The goal is to help an analyst make a better-informed decision, not to remove the analyst from the process.

10. Limitations and what comes next

SentinelGraph is a demonstration, not a complete enterprise security platform.

Its investigations operate on synthetic data, and the connections it can discover depend on the entities and relationships represented in the graph. A missing relationship or an incomplete dataset can limit what the system finds.

Likewise, a discovered path does not by itself prove malicious activity, and an unexplored path does not prove that two events are unrelated.

Future improvements could include:

Testing against larger and more varied security datasets.
Improving graph-query efficiency as the number of entities and relationships grows.
Evaluating how reliably the investigation logic identifies useful connections.
Adding stronger validation of evidence and investigation results.
Expanding historical incident retrieval and the evaluation of proposed actions.
Improving the handling of incomplete evidence and uncertainty.

These are important next steps if a demonstration is to evolve into a system that security analysts can rely on.

Final thoughts

SentinelGraph began with a simple observation: security alerts become more useful when we can understand how they connect.

By using FalkorDB to explore relationships, trace multi-hop evidence paths, and retrieve historical context, we built a demonstration of how connected data can support a more transparent cybersecurity investigation workflow.

The most interesting part is not simply that an agent can produce an answer. It is that an analyst can inspect the relationships behind that answer, understand what the investigation found, and decide what to do next.

The graph is not the conclusion. It's the evidence path that helps an analyst reach one.

Explore SentinelGraph

Source code: https://github.com/parnika0110/SentinelGraph
Live demo: https://frontend-production-717c.up.railway.app
Backend health check: https://backend-production-f51e.up.railway.app/health
Demo video: https://youtu.be/PiiVW7jK-Ck?si=ueAFPYuMRhMmAd5r

The project uses synthetic security data and simulated response actions for demonstration purposes.

Acknowledgements

Built collaboratively with my teammate for Graph Hacks 2026, exploring how FalkorDB can power AI agents that reason over connected data.

We also used AI-assisted development tools during the process.

DEV Community: Parnika S M