Change Guardian: Using AI Graphs to Find Hidden Risks Missing from IT Dependency Maps

Title

Change Guardian: Using AI Graphs to Find Hidden Risks Missing from IT Dependency Maps

Meta Description

Change Guardian is an AI agent built on the FalkorDB graph database that cross-validates to uncover hidden dependencies missing from the CMDB, calculates the true blast radius, and prevents business disruptions caused by IT changes.

Article Content

An outdated IT dependency map can cause the emergency departments of 51 hospitals to simultaneously lose critical lab results at 2 a.m. Change Guardian uses an AI agent and a graph database to find the 51 hidden connections that nobody wrote down on that map.

The Question Every IT Team Asks

Suppose you're responsible for a hospital's core IT systems. Tonight, you need to install a security patch on a server and reboot it. Before you act, you open the CMDB (Configuration Management Database) to check "which systems depend on this server"—the so-called blast radius.

The map shows: only the lab reporting system is affected, low risk. You approve the change.

At 2 a.m., emergency departments across the region stop receiving critical lab results.

What went wrong? The map wasn't drawn wrong—it was out of date. New connections are added every week: temporary project integrations, quick fixes, new campus rollouts. Someone meant to update the CMDB but didn't. This slowly widening gap between what the map records and what the system actually does is called CMDB drift.

Gartner has warned that organizations that don't address CMDB data quality issues will eventually suffer visible business disruptions. And the person approving the change has no way to know which line is missing—because a missing line looks exactly the same as a line that never existed.

CMDB (Configuration Management Database) is a core practice in the ITIL framework for recording configuration items (servers, applications, databases, network devices, etc.) and their relationships in the IT environment. It is supposed to be the authoritative basis for change impact analysis, but in reality CMDB maintenance often lags behind actual changes—temporary integrations, emergency fixes, and project launches are rarely synchronized. This deviation between data and actual state is CMDB drift. The danger of drift is that it is silent: a missing dependency link looks exactly the same as a dependency that never existed, and any CMDB-based impact analysis will systematically underestimate the blast radius. Gartner research points out that CMDB data quality issues have become one of the main causes of change management failures, and the key to fixing drift is introducing evidence sources independent of manual maintenance for cross-validation.

What Change Guardian Solves

Change Guardian is an AI agent whose core idea is: don't just look at what the map says, look at what the system actually does. It cross-validates data from multiple real tools to find dependency relationships nobody recorded, shows the true blast radius, explains the reason with exact graph paths, and then takes action—notifying the right people and proposing fixes to the map, waiting for human approval.

To make the system verifiable, the author built a fictional Northwind Health healthcare system: 51 hospitals, about 1,000 clinics, two data centers, and two cloud regions, covering every layer from patient-facing services down to servers, storage, network devices, and medical devices. The reason for choosing a healthcare scenario is straightforward: the question of "what really depends on what" matters most where mistakes hurt people.

According to the project description published by the author on Dev.to, the tool was completed in the Graph Hacks 2026 hackathon with support from WeMakeDevs and FalkorDB.

Truth Comes from Evidence, Not a Single Tool

Change Guardian's "what actually happens" view comes from evidence—records produced by the tools real hospitals already run. The author simulated data sources from ten tools, each generating data in its real format:

• Discovery scans list every device on the network
• Application monitoring shows which applications call which databases
• Network traffic records show who is communicating with whom, even if no software is installed on the device
• Interface engines (the hub routing medical messages) show where messages actually flow
• Backup and storage reports show whether data really has a safe copy
• Login and database audit logs, HR data sources, IT service desk history show who uses what, and which team actually fixes each system

No single tool can see everything. The network can see traffic but not intent; the interface engine can see message routing but not servers; the service desk knows who fixes problems, which often doesn't match the owner listed on the map. The truth lies in the combination.

Core Case: One Patch, 51 Hospitals

A change request reads: Apply an ESXi security patch to dc1-host-07 and reboot. The dependency chain from bottom to top is: physical server → virtual machine → database lrc-db-01.

The CMDB says this patch affects 4 components, 0 hospitals.

The evidence says: 107 components, 51 hospitals.

Where does the discrepancy come from? The CMDB records the hospitals' critical lab result interfaces (the feeds that deliver urgent results to emergency departments) and also records the database. What it's missing is the 51 links between them. The interface engine's configuration shows that all 51 feeds write to lrc-db-01 every day, for 14 days straight. But nobody added those links to the map.

So the patch that seemed to affect only lab reporting would actually cut off critical lab results for all 51 hospitals' emergency departments.

Why a Graph Database

Dependency maps are naturally graphs: servers, databases, and services are nodes, and "depends on" is the edge between nodes. "What happens if this goes down" means walking along edges—from the server to everything on it, then to everything above that, sometimes many steps deep.

Change Guardian stores two versions of the truth in the same FalkorDB graph, using the same nodes and two kinds of edges: edges declared by the CMDB, and edges observed by evidence. The question then becomes two traversals from the same starting point: follow only declared edges → what the CMDB thinks will break; follow declared plus observed edges → what will actually break.

The difference between the two traversals is the finding itself, and the path between them automatically becomes the explanation.

The author also honestly tested the alternative of an ordinary relational database, with mixed results: on large-scale dependency traversal, the graph database is clearly faster (on 3.47 million nodes, tracing 105,713 dependent components, FalkorDB took 38 ms versus 357 ms for PostgreSQL, about a 9x gap); with 100 concurrent users, FalkorDB's slowest response was 1.7 seconds versus 4.4 seconds for PostgreSQL; but when building a complete report including owner, department, and hospital information, PostgreSQL was actually faster (908 ms vs. 1,324 ms), because that is essentially a table join strength. The author also notes that for the largest changes, a hybrid approach where FalkorDB handles traversal and SQL fills in details is fastest.

Graph databases use nodes and edges as their native storage model, making them particularly suited for multi-hop dependency traversal. Unlike relational databases that simulate graph structures through JOINs, graph databases use index-free adjacency during traversal, meaning each node directly holds pointers to its neighbors, so traversal cost is proportional to path depth rather than total table size. In blast radius analysis—queries that need to go deep from a single starting point—this characteristic delivers order-of-magnitude performance advantages. FalkorDB is a graph database built on Redis that supports the Cypher query language and vector indexing, and its memory-first architecture makes it stand out in low-latency traversal scenarios. The benchmark in the article (3.47 million nodes, 105,713 dependent components, 38 ms vs. 357 ms) is a direct reflection of this characteristic—but note that graph database advantages are concentrated in traversal workloads; aggregate reporting queries may still be a relational database strength.

Why an AI Agent, Not Just Code

Drift detection itself is done by precise graph checks, which is a deliberate design choice: detection must be precise and testable. According to the benchmark answer comparison published by the author, these checks found all 109 planted problems with no false positives, including correctly not flagging four backup links that looked broken but were actually fine.

But reviewing a change is not a fixed procedure. The next question depends on the previous answer: is the actual impact different from the declared impact? If so, which links are hidden, and what evidence can show them? Who really owns the newly affected systems (often not what the map says)? Are there other recent changes nearby? How high is the risk, who should be warned, and what should be done next?

This is where an AI agent comes in: an AI model that can autonomously decide the next step, call tools to query, and keep reasoning until it can answer. Change Guardian's agent selects steps from 18 graph tools and explains why, providing tool calls through MCP (Model Context Protocol), meaning any MCP-compatible AI application can use the same set of graph tools. It also writes change notes and requests change advisory board review; modifications to the CMDB itself always wait for human approval.

Every number and system name is validated against the graph. If they don't match, its answer is held back and a rule-based review result is shown instead. Each investigation costs less than half a cent.

MCP (Model Context Protocol) is a standardized protocol proposed and open-sourced by Anthropic for letting AI models call external tools and data sources in a unified way. Before MCP, each AI application needed to write custom integration for each tool, creating an N×M adaptation matrix between tools and models. MCP reduces this matrix to N+M: a tool only needs to implement an MCP server once, and any MCP-compatible AI client can use it directly. In Change Guardian's case, 18 graph query tools are wrapped as MCP tools, and the agent discovers and calls them through the protocol, meaning the same set of graph tools can be reused by Claude Desktop, IDE plugins, or other MCP clients without modifying the agent logic. The core value of MCP is decoupling tool capabilities from agent implementation, making graph database query capabilities portable infrastructure.

Memory Lets Judgment Accumulate Rather Than Evaporate

When a person approves a suggestion, the 51 missing links are added to the CMDB. That approval is also stored in the agent's own memory graph (a separate graph in FalkorDB). The next time anyone reviews a change to this server, the agent already knows: someone confirmed those 51 links. If someone rejects a finding as a false positive, the agent won't raise it again.

Without memory, every review starts from zero, and people keep answering the same questions. With memory, human judgment accumulates rather than being discarded.

Honest Test Results

The author wrote nine test scenarios with known answers. The first five scenarios shaped the agent: the first run solved only 2 of 5 because two tools were missing; after adding them, it solved 4 of 5. The author admits: "Scores you've tuned prove nothing."

So four never-before-seen scenarios were written, with expected answers saved before running, run only once, and nothing modified afterward. On the final data, the agent answered 7 out of 9 correctly.

The two failures are the most instructive: both involved warning the wrong team (one also named the wrong cause). Ownership is the hardest thing for the agent to get right—which makes sense, because ownership is precisely the fastest-aging information in real CMDBs.

Unexpected Lessons

The author shared several engineering lessons:

Check your tools before blaming the database. The first benchmark was unfair to FalkorDB: a missing library caused the Python client to read results slowly. After installation, decoding speed improved about threefold. The author corrected and published the revision.

Measure under exactly the same conditions. One rerun looked 2.7x slower, not because of the database but because the laptop was busy doing something else. After that, only back-to-back, same-condition measurements were published.

Graph algorithms can audit your own model. The author ran a connected-components check (finding groups of nodes not connected to any other node) to find isolated systems; no orphan nodes were found, but it revealed a whole family of services that nobody connected to anything—making some dangerous changes look harmless. The model was fixed as a result.

Reserve a test set for the agent. A score promised in advance is far more valuable than a tuned score.

Next Steps

Change Guardian currently runs on fictional data. The next step is to connect to a real CMDB read-only, letting it review every change request the moment it's submitted, so warnings arrive before anyone approves the change—not after the outage.

Because the most dangerous dependency is the one nobody wrote down.

Demo video: https://youtu.be/FjRZv8ZxBCE · Live demo: https://change-guardian.vercel.app · Code: https://github.com/sudarshan032/northwind-drift-agent

One-line Summary

Change Guardian uses a graph database and an AI agent to compare CMDB declarations against real evidence, finding hidden dependencies and explaining the blast radius.

Paragraph Summary

The article introduces an AI agent project called Change Guardian, aimed at solving the distortion of IT dependency maps caused by CMDB drift. The project built a fictional Northwind Health healthcare system as a test environment, simulating data sources from ten real tools to generate evidence, and storing CMDB-declared edges and evidence-observed edges in the same FalkorDB graph. By comparing the difference between two traversals—one following only declared edges and one following declared plus observed edges—the system precisely discovers hidden dependencies and generates explanation paths. In the core case, an ESXi patch that appeared to affect only 4 components would actually cut off critical lab results for 51 hospitals' emergency departments. The agent autonomously reasons by calling 18 graph tools via the MCP protocol, answering 7 of 9 test scenarios correctly, with ownership identification being the weakest link. Human approval results are stored in a memory graph, allowing judgment to accumulate.