AegisGraph
A security incident response AI agent built on a graph database that uses a knowledge graph for multi-hop reasoning to locate attack paths and execute remediation actions.
Timeline (last 90 days)
The AegisGraph project was built at the Graph Hacks hackathon (co-hosted by WeMakeDevs and FalkorDB, Track 01: Agents acting on connected data).
The AegisGraph team concluded that whether an agent can act safely depends almost entirely on the structure of its context, and that a knowledge graph outperforms flat vector fragments.
In the demo topology, attack paths crossing the code, runtime, and identity layers are 5 to 8 hops long, and six such paths lead to 3 critical PII databases.
AegisGraph models the code layer, the runtime layer, and the identity and data layer as a single FalkorDB property graph.
AegisGraph uses a single OpenCypher query to answer both which data an attacker can reach and which service path is the hub.
In AegisGraph's demo topology, legacy-billing-bridge is critical because it lies on all six attack paths, not because its code has vulnerabilities.
The sandbox graph is a clone of the production graph; after the agent executes the proposed remediation actions in the sandbox, it re-runs the blast-radius query to verify whether the attack paths are cut and whether the critical business paths remain connected.
The "prove first, execute later" pattern turns the agent from a probabilistic text generator into a verifiable decision system.
The AegisGraph approach depends on the completeness and freshness of the graph data; if synchronization of code dependencies, service routing, or IAM policies is delayed, the path analysis on the graph will be distorted.
Maintaining consistency between the sandbox graph and the production graph is itself an engineering challenge, especially in a production environment with frequent changes.
1 more timeline events
All Facts (11)
For Agents that need to act in high-risk environments, the core lesson is: have the Agent first prove its fix on the graph, then let it act.
50%UnverifiedThe AegisGraph team concluded that whether an agent can act safely depends almost entirely on the structure of its context, and that a knowledge graph outperforms flat vector fragments.
50%UnverifiedIn the demo topology, attack paths crossing the code, runtime, and identity layers are 5 to 8 hops long, and six such paths lead to 3 critical PII databases.
50%UnverifiedAegisGraph models the code layer, the runtime layer, and the identity and data layer as a single FalkorDB property graph.
50%UnverifiedAegisGraph uses a single OpenCypher query to answer both which data an attacker can reach and which service path is the hub.
50%UnverifiedIn AegisGraph's demo topology, legacy-billing-bridge is critical because it lies on all six attack paths, not because its code has vulnerabilities.
50%UnverifiedThe sandbox graph is a clone of the production graph; after the agent executes the proposed remediation actions in the sandbox, it re-runs the blast-radius query to verify whether the attack paths are cut and whether the critical business paths remain connected.
50%UnverifiedThe "prove first, execute later" pattern turns the agent from a probabilistic text generator into a verifiable decision system.
50%UnverifiedThe AegisGraph approach depends on the completeness and freshness of the graph data; if synchronization of code dependencies, service routing, or IAM policies is delayed, the path analysis on the graph will be distorted.
50%UnverifiedMaintaining consistency between the sandbox graph and the production graph is itself an engineering challenge, especially in a production environment with frequent changes.
50%UnverifiedThe AegisGraph project was built at the Graph Hacks hackathon (co-hosted by WeMakeDevs and FalkorDB, Track 01: Agents acting on connected data).
50%