Turning connected security data into explainable attack-path insights
Security incidents rarely happen in isolation. A compromised workstation, an exposed service account, and a server with excessive access privileges might appear to be separate issues. But when these entities are connected, they can reveal a potential path an attacker could take toward a critical system.
That is the idea behind TRACEFORGE, a graph-powered security intelligence platform I built for FalkorDB Graph Hacks 2026, Track 01: Agents That Act on Connected Data.
The project explores how graph databases can help security teams understand relationships between assets, investigate potential attack paths, and make better-informed defensive decisions.
The Problem: Security Risks Hide in Relationships
Modern environments contain workstations, servers, identities, applications, and service accounts. Understanding each asset individually is useful, but it does not always reveal the bigger picture.
Consider a simplified scenario:
- An attacker gains an initial foothold on a workstation.
- That workstation can reach another system.
- A service account has access to an application server.
- The application server is connected to a critical server.
Each relationship might look harmless on its own. Together, they could form a potential attack path.
Security analysts need a way to explore these connections, identify paths toward critical assets, and understand why a particular route deserves attention.
TRACEFORGE was designed to explore this problem using graph-based security intelligence.
What Is TRACEFORGE?
TRACEFORGE is a security intelligence dashboard prototype designed to help security analysts and security operations teams:
- Explore relationships between connected assets.
- Identify candidate attack paths toward critical systems.
- Discover graph entities and inspect observed relationship types.
- Present graph-derived information through a dashboard.
- Provide a foundation for evidence-based investigations and defensive simulations.
The goal is to make complex relationships easier to understand and give analysts a clearer starting point for investigating potential risks.
Why FalkorDB?
I chose FalkorDB because the central problem in TRACEFORGE is about relationships and traversal, not just storing individual records.
A conventional data model can store workstations, accounts, and servers in separate tables. However, exploring multi-step connections across those entities can require several joins and additional application logic.
With a graph database, entities can be represented as nodes and their connections as relationships. This makes it natural to ask questions such as:
What possible paths connect an initial foothold to a critical server?
FalkorDB serves as the graph data layer for TRACEFORGE, allowing the backend to query connected security entities and return results for analysis and visualization.
Modeling the Security Environment as a Graph
The graph represents a simplified security environment.
Nodes represent entities such as:
- Workstations
- Service accounts
- Application servers
- Critical servers
- Other security-relevant assets
Relationships represent connections between those entities. Examples in the project include:
USESAUTHENTICATES_TOACCESSESREACHES
These relationships allow the backend to explore how one entity connects to another.
For example, a path might look like:
Workstation A → Service Account → Application Server → Critical Server
This is an illustrative example of the kind of route the platform is designed to investigate. Whether a path represents a genuine security risk depends on the accuracy and meaning of the underlying relationship data.
That distinction matters: a graph can reveal connectivity, but the application still needs reliable evidence and appropriate analysis to interpret what that connectivity means.
How FalkorDB Fits into the Architecture
TRACEFORGE uses a simple architecture that separates graph storage, backend processing, and dashboard presentation.
1. FalkorDB — Graph data layer
FalkorDB stores the connected entities and relationships used by the prototype. It provides the graph-query capabilities needed to explore connections and candidate paths.
2. Backend API — Query and response layer
The backend communicates with the graph database and exposes HTTP endpoints for the frontend.
Two important endpoints in the current prototype are:
-
/graph— retrieves graph nodes and relationships for inspection. -
/paths— accepts source entities and a target, then returns candidate paths found by the backend.
A /health endpoint is also used to check backend availability.
3. TRACEFORGE dashboard — Visualization layer
The frontend calls the backend endpoints to display graph inventory and attack-path results. This separation allows the UI to consume graph data without needing to communicate directly with FalkorDB.
The dashboard also distinguishes graph-derived information from illustrative metrics and sample records. This is important because security interfaces should not present demonstration data as if it were live telemetry.
Exploring Potential Attack Paths
One of the core workflows is querying candidate paths between selected source entities and a target.
In the demonstration dataset, the backend accepts sources such as Workstation A, Secondary Foothold, and Service Account, with Critical Server as the target.
The backend then returns the candidate paths it finds in the graph. During testing, the configured query returned three paths for this synthetic dataset.
This demonstrates how graph traversal can help answer a useful security question:
Which connected routes in the modeled environment could lead toward a critical asset?
The results can provide analysts with a starting point for further investigation. In a production system, each path would need supporting evidence, clear relationship semantics, and appropriate confidence information before it could be treated as a meaningful security finding.
Beyond Path Discovery: Toward Agent-Assisted Defense
The broader direction of TRACEFORGE is to explore how an agent could use connected graph data to support security workflows.
A potential workflow would involve:
- Querying the graph for relevant entities and candidate paths.
- Collecting evidence that supports each relationship.
- Explaining why a path may matter.
- Recommending a defensive action for analyst review.
- Testing the proposed change in an isolated simulation environment.
- Independently checking whether the candidate path remains after the simulated change.
- Recording the evidence, decision, and verification result in an audit trail.
The important principle is that finding a path, recommending a defense, and verifying a defense are different tasks.
An agent should not treat a plausible path as confirmed compromise, and a proposed remediation should not automatically become a real-world action. Analyst approval, controlled testing, and independent verification are essential parts of a trustworthy security workflow.
These are the design goals for extending TRACEFORGE beyond its current graph-query and dashboard prototype.
Challenges and Lessons Learned
Building TRACEFORGE reinforced several lessons for me.
1. Graph structure is only as useful as the data
A graph makes relationships easier to explore, but incorrect or incomplete relationships can produce misleading results. Evidence provenance and data quality are critical.
2. A candidate path is not proof of an attack
A connected route identifies a possibility in the modeled environment. It does not, by itself, prove that an attacker used the route or that every relationship is exploitable.
3. Keep the data layer separate from the interface
Using a backend API between FalkorDB and the dashboard creates a clear boundary. It also makes it easier to test graph queries independently from UI behavior.
4. Verification should be independent
If defensive simulations are added, the system should verify their outcomes by querying the resulting graph again instead of simply assuming that the proposed change worked.
5. Demonstrations should be transparent
The current prototype uses synthetic security data. Clearly labeling sample metrics, illustrative topology, and live API results helps avoid confusing a working demonstration with a fully deployed security product.
What's Next?
The next steps for TRACEFORGE are to strengthen the evidence behind graph relationships, improve the explainability of path results, and develop a more complete analyst-in-the-loop workflow.
Potential improvements include:
- Evidence-backed explanations for each relationship in a candidate path.
- Clearer confidence and uncertainty reporting.
- Analyst approval before any defensive action.
- Isolated, disposable simulation graphs for testing proposed changes.
- Independent post-simulation path verification.
- Auditable records of findings, approvals, and test outcomes.
These improvements would help move the project toward a more trustworthy security intelligence workflow.
Final Thoughts
FalkorDB provided a natural foundation for modeling connected security entities and exploring potential paths between them. Instead of looking at workstations, identities, and servers as isolated records, TRACEFORGE treats their relationships as an important part of the security picture.
The project has also helped me think more carefully about the difference between graph connectivity, evidence-based reasoning, and verified defensive outcomes.
For me, the exciting opportunity is not just discovering connections. It is using those connections to help analysts understand risk, evaluate options, and make better-informed decisions.
TRACEFORGE is an ongoing prototype, built with FalkorDB as its graph data layer, with the longer-term goal of making security investigations more connected, explainable, and verifiable.
Top comments (0)