FalkorDB in Practice: Building a Self-Verifying Security Incident Agent with a Graph Database

Most AI Agent demos stop at giving an answer, but the AegisGraph project aims to execute actions in production—where a mistake means someone gets woken up at 3 a.m. At the Graph Hacks hackathon (co-hosted by WeMakeDevs and FalkorDB, Track 01: Agents that act on connected data), the team built AegisGraph and drew one core conclusion: whether an Agent can act safely depends almost entirely on the structure of its context. Flat vector snippets aren't enough—a knowledge graph is the answer.

What a security incident is really asking

A WAF alert indicates that forged Bearer tokens are being accepted by auth-token-service, pointing to jwt-crypto-core. The on-call engineer needs to answer three questions at once: Which customer data can the attacker reach from here? Without crippling the checkout flow, what can be cut off to stop the attack? Who should fix this code?

Each answer lives in a different system. Package import relationships hide in code repositories, service-to-service traffic is recorded in the service mesh, and data access permissions are managed by cloud IAM. The real answer is a multi-hop path across all three layers: CVE → Package → Function → Service → Service Mesh → IAM Role → Database. In the demo topology, this path is 5 to 8 hops long, and six such paths lead to 3 critical PII databases.

A vector store can find text that "sounds like a JWT vulnerability," but it cannot tell you that legacy-billing-bridge sits on all six paths at once.

CVE (Common Vulnerabilities and Exposures) is a unique identifier for publicly disclosed software vulnerabilities—for example, CVE-2021-44228 corresponds to Log4Shell. WAF (Web Application Firewall) is a firewall deployed in front of applications to detect and block malicious HTTP traffic; when it alerts that "forged Bearer tokens are accepted," it means the authentication step may have been bypassed. A Bearer token is a common access credential in OAuth 2.0 that anyone holding it can use without proving identity—so once forged, an attacker can impersonate a legitimate user to call services. An IAM Role (Identity and Access Management Role) is an identity entity in cloud platforms that grants temporary permissions to services or users; the ASSUMES_ROLE relationship means a service gains access to resources like databases by assuming that role. Together, these concepts form the analytical basis for "who is where and what can they touch" in a security incident.

One graph to unify code, runtime, and identity

The team modeled three layers as a single FalkorDB property graph:

• Code layer: (:Vulnerability)-[:AFFECTS]->(:Package)<-[:IMPORTS]-(:Function)<-[:MAINTAINED]-(:Developer), plus (:Function)-[:CALLS]->(:Function)
• Runtime layer: (:Service)-[:DEPLOYS_CODE]->(:Function) and (:Service)-[:ROUTES_TO]->(:Service)
• Identity and data layer: (:Service)-[:ASSUMES_ROLE]->(:IAMRole)-[:CAN_ACCESS]->(:Database)

The entire blast radius condenses into a single OpenCypher query:

MATCH (v:Vulnerability {id: $cve_id})-[:AFFECTS]->(:Package)<-[:IMPORTS]-(f:Function)<-[:DEPLOYS_CODE]-(origin:Service)
WITH DISTINCT origin
MATCH attack = (origin)-[:ROUTES_TO*0..3]->(pivot:Service)-[:ASSUMES_ROLE]->(role:IAMRole)
               -[:CAN_ACCESS]->(db:Database {contains_pii: true})
WHERE ALL(r IN relationships(attack) WHERE coalesce(r.status, 'ACTIVE') = 'ACTIVE')
RETURN pivot.name, role.name, db.name, [n IN nodes(attack) | n.name] AS path

This query answers both "what data can the attacker touch" and "which service path is the hub" at once. legacy-billing-bridge matters not because its code has a vulnerability, but because of its position in the graph—an insight vector retrieval cannot provide.

Property Graph is a graph data model in which both nodes and edges can carry key-value properties (such as status: 'ACTIVE'), making it well suited to expressing complex relationships with semantics. OpenCypher is the open standard for graph query languages, describing paths with pattern-matching syntax—for example, (a)-[:REL*0..3]->(b) denotes a variable-length path from a to b of 0 to 3 hops. Multi-hop queries mean traversing relationships multiple steps across a graph rather than doing a single table join, which is exactly what's needed to trace attack paths across the code, runtime, and identity layers. FalkorDB is a property graph database that supports OpenCypher, known for low latency and sparse matrix computation, making it suitable for quickly executing path queries like blast radius in Agent scenarios.

The sandbox graph: making the Agent prove before it acts

The "Look Before You Leap" in the title captures the soul of this project: the Agent cannot directly execute remediation in production, but first simulates it in a FalkorDB sandbox graph. The sandbox graph is a clone of the production graph; the Agent performs the proposed cut action in the sandbox (for example, removing an IAM role or isolating a service), then re-runs the blast radius query to verify that the attack path has been severed and that critical business paths remain connected.

This "prove first, execute later" model turns the Agent from a probabilistic text generator into a verifiable decision system. Every action has graph-based evidence before execution, rather than relying on the language model's confidence.

Why graph structure is a prerequisite for safe Agent action

Several lessons for building production-grade Agents can be distilled from AegisGraph's practice.

Context structure determines action quality

An Agent's action safety doesn't depend on how big the model is, but on whether the context fed to it preserves the real relationships between entities. Flattened text loses the topological information of "who depends on whom," and multi-hop security analysis relies precisely on that topology. Graph databases natively support path queries and relationship traversal, which relational databases and vector stores cannot efficiently replace.

Vector retrieval recalls content by encoding text into high-dimensional vectors and computing similarity; it excels at semantic matching but cannot guarantee topological relationships between entities. For example, it can find documents "related to the JWT vulnerability" but cannot answer "which service sits on all six attack paths at once." Relational databases support JOINs, but deep variable-length path queries require recursive CTEs, and neither performance nor expressiveness matches graph databases. Graph databases natively store relationships as first-class citizens, with path traversal as a core operation, giving them a structural advantage in scenarios like security analysis and dependency analysis. Understanding this distinction is key to seeing why AegisGraph chose a property graph rather than a vector store or relational database as the Agent's context foundation.

The verification loop matters more than a single inference

Sandbox simulation is essentially counterfactual "what if" reasoning on the graph. After the Agent's proposed remediation is executed in the sandbox, the same graph query verifies the effect, forming a closed loop. This pattern can be generalized to any high-risk operation scenario: shadow execution first, then validation against expectations, and only then production.

Cross-system correlation requires a unified graph

Data from the three layers—code, runtime, and identity—is naturally scattered across different systems. Modeling them into the same property graph makes cross-system multi-hop queries possible. FalkorDB's property graph model and OpenCypher support make this unified modeling feasible in engineering terms.

Boundaries worth watching for real-world adoption

One caveat: this approach depends on the completeness and freshness of the graph data. If synchronization of code dependencies, service routes, or IAM policies lags, path analysis on the graph will be distorted. Moreover, maintaining consistency between the sandbox graph and the production graph is itself an engineering challenge, especially in high-change production environments. As a hackathon project, AegisGraph shows the direction, but production adoption still requires solving real-time data pipelines and graph version management.

For teams building security Agents or any Agent that needs to act in high-risk environments, AegisGraph's core lesson is worth remembering: let the Agent prove its fix on the graph before letting it act.

One-line Summary

AegisGraph unifies code, runtime, and identity in a property graph, letting the Agent prove fixes in a sandbox before executing.

Paragraph Summary

AegisGraph is a security Agent project built at the Graph Hacks hackathon, whose core claim is that an Agent's ability to act safely depends on the structure of its context, not model size. It models three layers—code dependencies, service runtime, and cloud IAM identity—as a single FalkorDB property graph, using one OpenCypher multi-hop query to answer both "which PII data can the attacker reach" and "which service is the hub node," and identifying legacy-billing-bridge, which vector retrieval cannot find. The Agent does not execute remediation directly in production; instead, it first simulates cut actions in a sandbox graph and re-runs the blast radius query to verify the effect, forming a "prove first, execute later" loop. The article concludes that the approach depends on the completeness and freshness of graph data, and that maintaining consistency between sandbox and production graphs is the main engineering boundary for adoption.