Your new workforce won't be all human. Join the
conference to learn the new workforce OS.
request invite
TL;DR: A read-only AI Coworker audited a full CMDB of 890 configuration items against AWS and Microsoft Entra. It surfaced ghost servers the CMDB still called live, owned by people who had already left, and flagged the two sources it could not verify instead of faking coverage. A wrong-but-trusted CMDB is more dangerous than none, because change impact analysis silently rides on the drift.
Related reading: Why approved changes still cause outages, Start where you are.
Ask an IT team if they trust their CMDB and watch the body language. The configuration management database is supposed to be the single source of truth for what you run and how it connects, the thing change impact analysis, incident routing, and outage blast-radius all stand on. In practice it is the system everyone routes around. "The CMDB is wrong, so we do not use it" is one of the most common sentences in IT operations, and practitioners say it out loud: real ServiceNow community threads carry titles like "Is your CMDB lying to you?" and "Why does our CMDB look complete but still fail during incidents?"
The reason it goes wrong is structural. A CMDB does not keep itself accurate. It stores what you feed it and keeps the record even after reality moves on. Configuration item states usually do not change just because a change, asset, or request workflow ran, so the record and the real world drift apart quietly. A server gets decommissioned; the CI still says operational. A cloud instance is deleted; the CMDB never hears. An owner leaves the company; the CI still lists them. Commonly cited industry figures put average CMDB accuracy around 60 percent, though treat that as directional and verify before quoting. Rather than argue the number, we ran the audit.
We raised one request: enumerate every CI in the CMDB and verify each against its real-world source of truth, then report the mismatches. The CMDB Integrity Coworker read the whole database, all 890 configuration items with no sampling, reconciled each class against the right authority, and attached an audit-ready HTML report to the ticket.
It verified what it could reach: AWS for the cloud infrastructure CIs, and Microsoft Entra for identities, applications, and every CI owner, 675 service principals checked, plus owner existence and enabled status for each flagged CI. Then it came back with a named list, not a maturity score.
The confirmed drift clustered in one dangerous place. About seven ghost CIs: AWS-typed configuration items the CMDB still carried as live, that no longer exist in AWS at all. Nine departed-owner CIs: records whose listed owner is gone or disabled in Entra, so nobody is accountable for them. Seven shadow resources: things actually running in AWS with no CI in the CMDB, the estate the CMDB never knew about.
The detail that matters is how they line up. The ghost CIs were owned by identities that had left, and none of them carried a business-service relationship. So a change touching any of them would currently be scored as low impact, because the CMDB shows nothing downstream, when in reality the record is a fiction. That is the exact mechanism by which a trusted CMDB approves the change that breaks something nobody expected.
The best part of the run was what the Coworker refused to do. Two whole classes of CI could not be verified, and instead of quietly passing them, it reported them as UNVERIFIED and said why. The CMDB's cloud CIs come from two clouds; AWS was reachable, but the Azure resources needed an Azure Resource Manager read scope it did not have. The device CIs needed Microsoft Intune, which returned a 403 on the available permissions. It named both gaps in the report, rather than let a green result imply coverage it did not have.
That is the difference between an audit you can act on and a dashboard you have to second-guess. It told us exactly how far its assurance went.
A blank CMDB makes you cautious. A confident, wrong CMDB makes you reckless. When the data is trusted but stale, the damage is downstream and invisible: change impact analysis reads the relationships, sees nothing, and approves a change that takes down a service nobody flagged. Incident routing points at a CI that is a ghost. Audits inherit the errors. The CMDB does not fail loudly; it fails the moment you rely on it.
The Coworker reads, reconciles, and reports. It did not edit a CI, change a state, delete a record, rewrite a relationship, or touch a single cloud resource. It handed over a ranked list of what is wrong, the source it checked each against, and a recommended correction, then routed the ownerless records to be reassigned. Fixing the CMDB stays with the people who own it. That read-only boundary is what makes it safe to run across the whole database, on demand, as often as you like.
The CMDB becomes trustworthy again, because the errors are named and fixed instead of suspected and avoided. Change impact analysis stops running on fiction, because ghost CIs and missing relationships surface before a change rides on them. The shadow estate appears, the AWS resources that were never in the CMDB at all. Accountability returns, because departed-owner CIs get reassigned. Coverage is honest, because the sources it could not reach are labelled unverified, not counted as clean.
Why do CMDBs become inaccurate? Because they do not self-correct. The CMDB stores what it is given and keeps records even after reality changes, and CI states usually do not update just because a change, asset, or request workflow ran.
How does the AI Coworker check accuracy? Read-only. It enumerates every CI, then cross-checks each against the authoritative source for its type: the cloud provider for infrastructure, Microsoft Entra for identities, applications, and owners, and Microsoft Intune for devices where the scope allows.
What did it actually find in this run? Across 890 CIs it found about seven ghost AWS CIs the CMDB still called live, nine CIs whose owner had left, and seven shadow AWS resources missing from the CMDB.
What does "unverified" mean in the report? It means the Coworker could not reach that source of truth, so it did not judge those CIs. In this run, Azure infrastructure and Intune devices were both reported as unverified rather than assumed accurate.
Does it edit or clean the CMDB itself? No. It reviews, reconciles, and recommends, and routes ownerless records to be reassigned. It never edits a CI, changes a state, deletes a record, or rewrites a relationship.
The CMDB is the most quietly distrusted system in IT, and that distrust is rational, because nothing keeps it honest. A read-only AI Coworker can be the thing that keeps it honest: it checked all 890 CIs in the CMDB against reality, found the ghosts a change would have tripped over, and was candid about the two sources it could not see. The Coworker finds the lies and marks the blind spots; your team corrects the record.
See how the AI Workforce audits your CMDB against reality at atomicwork.com.
