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

The safest cloud response starts with a path, not a prompt

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.

Live demo: blast-shield-ai.vercel.app

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

Contents

• The problem
• The idea: walk from the incident to the containment point
• How a containment candidate is selected
• What the demo measured
• Fixing it safely
• Seeing the graph
• What we learned
• What is not done yet
• If you keep one thing
• Sources

The problem

Most incident tools are very good at answering:

• Which service is returning errors?
• Which container is using too much CPU?
• Which deployment happened most recently?
• Which log line contains the exception?

They are less good at answering:

• What can this compromised component reach?
• Which relationship makes the incident dangerous?
• Which node can be isolated without taking down everything else?
• What remains reachable after containment?

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.

The idea: walk from the incident to the containment point

BlastShield models infrastructure as a typed property graph in FalkorDB.

The graph contains entities such as:

• APIGateway
• LoadBalancer
• K8sPod
• Service
• Database
• IAMRole
• Secret

The relationships are operationally meaningful:

• CALLS
• CONNECTS_TO
• ASSUMES
• PERMITS
• READS_SECRET
• HOSTS
• REPLICATES_TO

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

The incident pipeline is:

Incident source
    → FalkorDB multi-hop traversal
    → Candidate articulation points
    → Reachability comparison
    → Human-readable recommendation
    → Explicit approval
    → FalkorDB mutation
    → Audit record and agent memory

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

The returned paths become evidence for the incident report. They are not replaced by a generated explanation.

How a containment candidate is selected

BlastShield does not use a fixed rule such as:

If a pod is compromised, shut down the pod.

Instead, it combines several pieces of graph evidence.

1. Find downstream impact

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

For example:

pod-auth-x92
  └── HOSTS → auth-service
        └── ASSUMES → iam-auth-token
              └── READS_SECRET → sec-jwt-private
                    └── CONNECTS_TO → users-db

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.

3. Compare reachability before and after isolation

For each selected candidate, BlastShield measures:

Reachable nodes before containment
Reachable nodes after candidate isolation
Remaining reachable Tier-1 paths

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.

4. Let KIMO explain the evidence

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.

The main tools are:

inspect_topology
analyze_blast_radius
recall_memory
propose_remediation
apply_remediation
reset_topology

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.

What the demo measured

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:

• 21 infrastructure nodes
• 24 relationships
• Services, databases, pods, IAM roles, and secrets

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

The live analysis produced:

• 2 impacted downstream entities
• 2 hops of downstream impact
• 2 candidate articulation points in the current topology
• 19 ingress-reachable nodes before isolation
• 17 ingress-reachable nodes after the selected cut
• 13 reachable Tier-1 paths protected after the analysis

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.

Fixing it safely

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 proposal does not mutate FalkorDB.

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:

• Quarantine the selected node
• Sever dangerous permission relationships
• Select a healthy database candidate for failover
• Persist a SHA-256 audit hash
• Store an episodic memory for KIMO
• Return the new graph state to the console

The safety boundary is:

AI proposes
Human approves
Graph mutates

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.

Seeing the graph

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

The command console exposes:

• FalkorDB connection status
• Node and edge counts
• The visual topology
• Incident selection
• Blast-radius results
• KIMO's evidence summary
• Cypher query execution
• Approval-gated remediation
• Audit history
• Agent memory

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 audit view closes the loop.

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

Memory that stays connected

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

BlastShield stores AgentMemory nodes in FalkorDB with information such as:

• Incident category
• Source node
• Learned containment strategy
• Confidence
• Success rate
• Timestamp
• Related audit hash

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?

It is also:

What did we do?
Did it preserve the right paths?
What should we consider next time?

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.

That is not enough.

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

• Blast-radius analysis reads graph paths.
• Cut-vertex analysis reads graph structure.
• Remediation mutates graph state.
• Audit records are stored in the graph.
• Agent memory is stored in the graph.

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

Deterministic analysis should come before fluent explanation

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 safest action may be smaller than the obvious action

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.

Approval is not the opposite of autonomy

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.

Synthetic data can still demonstrate real architecture

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.

What is not done yet

There are important limitations.

No live cloud ingestion yet

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.

Remediation is graph-level simulation

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.

No production multi-tenancy yet

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 demo is not a benchmark

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.

If you keep one thing

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.

The agent explains the evidence.

The human approves the change.

That is the design behind BlastShield AI.

Technology

BlastShield AI uses:

• FalkorDB
• Next.js
• TypeScript
• React
• OpenCypher
• Redis wire protocol
• OpenRouter-compatible AI APIs
• Tarjan articulation-point analysis
• SHA-256 audit hashes
• Docker Compose
• Vercel

Sources

• BlastShield AI source repository
• BlastShield AI live demo
• FalkorDB

AI Assistance Disclosure

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.