BlastShield AI: an evidence-first incident commander built on FalkorDB

When a cloud incident starts, the first instinct is usually to find the red service and restart it.

That is often too late, too broad, or simply wrong.

A compromised Kubernetes pod may be connected to an authentication service. That service may assume an IAM role. The role may read a secret. The secret may unlock a database. The database may replicate into another environment.

The visible failure is one node. The real incident is the path behind it.

We built BlastShield AI for the Graph Hacks challenge by WeMakeDevs and FalkorDB to answer a more useful question:

Given a compromised node, what can it reach, where can we contain it, and what evidence supports that decision?

BlastShield stores a synthetic cloud-infrastructure topology in FalkorDB, gives an AI incident commander named KIMO controlled tools to inspect that graph, and requires explicit human approval before any remediation mutation is applied.

Source code: github.com/sandman-sh/BlastShield-AI

Most incident tools are very good at answering:

That gap matters because cloud infrastructure is connected.

A dashboard may show that pod-auth-x92 is compromised. It does not automatically show whether the pod can reach an IAM role, which can read a JWT secret, which can reach the users database.

An LLM-only incident assistant has a different problem. It can summarize an incident fluently, but it may invent a dependency, use stale context, or recommend an action without proving the path behind it.

BlastShield was designed around a simple rule:

The model can explain the decision, but the graph must provide the evidence.

BlastShield models infrastructure as a typed property graph in FalkorDB.

The relationships are operationally meaningful:

This lets the application distinguish a service call from an authorization edge or a secret access path.

Incident source → FalkorDB multi-hop traversal → Candidate articulation points → Reachability comparison → Human-readable recommendation → Explicit approval → FalkorDB mutation → Audit record and agent memory Enter fullscreen mode Exit fullscreen mode The core traversal is executed against FalkorDB through the Redis protocol using GRAPH.QUERY.

MATCH path = ( source { id: $sourceNodeId }) - [ * 1.. 6 ] -> ( downstream ) RETURN downstream, length ( path ) AS hops ORDER BY hops ASC Enter fullscreen mode Exit fullscreen mode The returned paths become evidence for the incident report. They are not replaced by a generated explanation.

BlastShield does not use a fixed rule such as:

If a pod is compromised, shut down the pod. Enter fullscreen mode Exit fullscreen mode Instead, it combines several pieces of graph evidence.

The system traverses outward from the incident source and records the reachable downstream entities and the number of hops to each one.

pod-auth-x92 └── HOSTS → auth-service └── ASSUMES → iam-auth-token └── READS_SECRET → sec-jwt-private └── CONNECTS_TO → users-db Enter fullscreen mode Exit fullscreen mode 2. Find articulation points BlastShield retrieves the current topology and runs Tarjan's articulation-point algorithm.

An articulation point is a node whose removal disconnects part of a graph.

In a cloud topology, that can represent a choke point where isolation may stop a cascade without disabling unrelated infrastructure.

For each selected candidate, BlastShield measures:

Reachable nodes before containment Reachable nodes after candidate isolation Remaining reachable Tier-1 paths Enter fullscreen mode Exit fullscreen mode This turns a vague recommendation into a measurable trade-off.

The system can explain not only what it wants to isolate, but also what the graph predicts will remain available.

KIMO is the tool-calling AI incident commander inside BlastShield.

The model does not independently calculate the topology. It calls application tools that read FalkorDB and return structured results.

inspect_topology analyze_blast_radius recall_memory propose_remediation apply_remediation reset_topology Enter fullscreen mode Exit fullscreen mode KIMO is instructed to use tools before making claims about nodes, counts, paths, or safety.

The language model writes the explanation after the graph analysis has already produced the evidence.

The current demo uses a deterministic synthetic infrastructure graph. It is designed to be reproducible and safe for a hackathon demonstration.

After seeding the graph, the baseline topology contains:

For the demonstration incident, pod-auth-x92 was treated as the compromised source.

These are results from the deterministic demo topology, not a production benchmark. The purpose of the scenario is to show that the graph is performing the analysis and that the remediation decision is based on the current topology.

The important result is not a universal number.

The important result is that the system can show the path, calculate the candidate cut, compare the graph before and after isolation, and preserve the decision as an audit record.

An incident assistant should not turn a conversational sentence into an uncontrolled mutation.

BlastShield separates planning from execution.

When the operator asks for an analysis, KIMO can inspect the graph and propose a remediation.

The operator must explicitly approve it before apply_remediation is allowed to run.

sequenceDiagram participant Operator participant KIMO participant FalkorDB participant Audit Operator->>KIMO: Analyze compromised node KIMO->>FalkorDB: Inspect topology FalkorDB-->>KIMO: Nodes and relationships KIMO->>FalkorDB: Traverse blast radius FalkorDB-->>KIMO: Impact paths KIMO->>KIMO: Run articulation analysis KIMO-->>Operator: Explain and propose Operator->>KIMO: Explicitly approve KIMO->>FalkorDB: Quarantine and mutate graph FalkorDB->>Audit: Persist action hash and memory Audit-->>Operator: Show result The remediation flow can:

AI proposes Human approves Graph mutates Enter fullscreen mode Exit fullscreen mode The current project simulates infrastructure changes inside the FalkorDB topology. It does not claim to directly modify a user's AWS account or Kubernetes cluster.

The first useful UI decision was to make the topology visible without making the operator understand the database internals first.

The command console brings the live graph, incident controls, and agent conversation into one view.

The graph is also useful because it gives the operator something to challenge.

If KIMO says a database is at risk, the operator can inspect the highlighted path and see which relationships connect the source node to that database.

The highlighted path shows why a downstream entity was included in the blast-radius report.

The proposed action is visible before approval, and the resulting mutation is recorded afterward.

Incident memory is more useful when it keeps its topology context.

BlastShield stores AgentMemory nodes in FalkorDB with information such as:

That gives KIMO a path from a previous incident to the action that was taken:

graph LR I[Incident] --> S[Source Pod] I --> M[Agent Memory] M --> A[Remediation Action] A --> H[Audit Hash] S --> T[Current Topology] The long-term question is not only:

What happened? Enter fullscreen mode Exit fullscreen mode It is also:

What did we do? Did it preserve the right paths? What should we consider next time? Enter fullscreen mode Exit fullscreen mode What we learned The graph was the product, not the decoration At first, it is tempting to build a graph because graphs look impressive in a demo.

The graph became valuable only when every important feature depended on it:

If the graph is removed, the main product behavior disappears.

We learned to keep the language model away from the parts that should be reproducible.

The graph traversal, articulation-point analysis, reachability calculation, and mutation rules are application logic.

KIMO's job is to choose the appropriate tool, summarize the result, explain the evidence, and ask for approval.

The obvious response to a compromised pod is often to disable the whole service.

The graph can reveal a smaller containment point that breaks the dangerous path while preserving more healthy connectivity.

That is the difference between reacting to a red node and reasoning about a connected system.

An autonomous agent can investigate independently and prepare a high-quality action plan without silently changing production state.

The approval gate made the system more trustworthy because the operator can inspect the evidence before the mutation occurs.

We used synthetic infrastructure data so the demo is public, reproducible, and safe.

That does not make the graph behavior fake. The topology, queries, traversal, analysis, mutation, audit, and memory flows are real application behavior.

It does mean we are careful not to claim that this version is already a production AWS or Kubernetes controller.

The current graph is seeded from a deterministic synthetic topology.

The next version should ingest authorized data from Kubernetes, AWS IAM, cloud databases, service meshes, and deployment systems.

The current remediation changes the FalkorDB representation and records the action. It does not execute kubectl, AWS SDK calls, or cloud-provider mutations.

That is appropriate for the hackathon demo, but a production version would need provider-specific connectors, permissions, rollback, and policy enforcement.

A real SaaS version would require tenant isolation, role-based access control, secret rotation, encrypted connections, per-project credentials, and a detailed authorization model.

The numbers in this post come from the deterministic demo scenario. We have not presented them as a general production accuracy benchmark.

That distinction matters because trustworthy incident tooling should report what it has measured, not what sounds impressive.

The safest incident response starts with a path, not a prompt.

The path tells you what the compromised component can reach.

The graph tells you where a cut may contain the incident.

The algorithm compares the consequences.

That is the design behind BlastShield AI.

AI coding assistants were used for implementation assistance, debugging, documentation, and testing support.

The project team reviewed, tested, and understands the submitted code, graph model, queries, architecture, security boundaries, and product decisions.