Blog · Architecture

AI Inventory vs CMDB: Why Your Configuration Management Database Is Not Your AI Governance Answer

Eleye Abdi·4 July 2026·7 min read

When organisations first confront the AI agent inventory problem, one of the most common responses is: "We have a CMDB. Can't we just add AI agents to it?" It is a reasonable question. The CMDB is the canonical source of truth for IT assets in most enterprises. Adding AI agents to it feels like the natural extension of existing practice.

The answer is: a CMDB can record AI agents, but it cannot discover them, cannot detect cross-platform patterns, and cannot generate the signed governance evidence that regulatory obligations require. For IT asset management, the CMDB is the right tool. For AI governance evidence, it is the wrong tool for three structural reasons.

A CMDB records what IT knows about. AI governance requires discovering what IT does not know about. These are opposite starting points.

What a CMDB Is Designed to Do

A Configuration Management Database is a repository of information about IT configuration items: servers, applications, networks, software licences, and their relationships. It supports IT service management: incident management, change management, and problem management. The CMDB is populated through discovery tools, manual input, and system integrations. It is maintained by IT teams and reflects the IT-managed estate. Its scope is precisely the limitation for AI governance purposes.

The Three Structural Gaps

Gap 1: CMDBs record, they do not discover

A CMDB record is created when someone adds it: when IT provisions a system, when a discovery tool scans the network, when an integration imports data. It reflects what has been added. It does not automatically surface what has not been added, which, for AI agents, is the majority of the governance-relevant population.

AI agents are not typically added to CMDBs because they do not fit existing discovery and provisioning processes. An employee authorising a ChatGPT plugin to access their Google Drive does not create a change request. An Apps Script automation built by a product manager does not go through IT procurement. A Salesforce Agentforce configuration deployed by revenue operations does not appear in network scans. These agents are invisible to the CMDB because the mechanisms by which they were created bypassed the processes that feed it.

Gap 2: CMDBs capture configuration items, not OAuth grant populations

AI agents in enterprise environments operate primarily through OAuth grants: authorisations at workspace admin level allowing agents to access organisational data. OAuth grants are not IT configuration items in the CMDB sense. They are identity and access management artefacts distributed across multiple platform-specific admin surfaces.

The appropriate discovery mechanism for AI agents is querying the OAuth grant registries of each platform (Google Workspace Admin SDK, Microsoft Graph API, Salesforce connected apps, OpenAI workspace admin) to enumerate what grants exist. This is a fundamentally different discovery mechanism from CMDB discovery, which typically relies on network scanning, agent-based collection, or provisioning system integrations.

Gap 3: CMDBs do not detect cross-platform patterns or generate signed evidence

The governance outputs required for Article 26 compliance and FCA supervision (cross-platform toxic-combination findings, signed evidence packs, reproducible under examination) are not CMDB outputs. CMDBs generate asset records, dependency maps, and change histories. They do not detect that Agent X on Google Workspace and Agent Y on Microsoft 365 together create a cross-platform risk pattern. They do not generate cryptographically signed evidence packs with per-tenant signing keys.

These are not features that could be added to a CMDB with configuration changes. They require fundamentally different architecture: platform API integration for OAuth grant discovery, cross-platform correlation logic, and a signing infrastructure that does not exist within IT service management tooling.

What CMDBs and AI Inventories Can Do Together

The answer is not to choose between CMDB and AI inventory. It is to understand what each does and use them for the right purposes.

  • CMDB: manages IT configuration items, supports incident/change/problem management, records the IT-managed AI estate as configuration items where useful
  • AI inventory: discovers the full AI agent population through OAuth grant enumeration, classifies agents by risk, detects cross-platform patterns, generates signed governance evidence

The two are complementary. AI inventory outputs can feed CMDB records, providing IT with a current, complete view of AI agents as configuration items. But the discovery and evidence generation that regulatory compliance requires must come from AI-native tooling, not the CMDB.

The Right Tool for AI Governance Discovery

  1. Queries workspace admin APIs directly: OAuth grant registry queries across Google, Microsoft, Salesforce, OpenAI, and other platforms
  2. Enumerates both delegated grants (agents acting as users) and application grants (service identities)
  3. Detects cross-platform patterns: related agents operating across multiple platforms simultaneously
  4. Generates signed evidence: cryptographically signed governance artefacts verifiable under regulatory examination

AETHER Pulse implements all four requirements. It does not replace the CMDB. It provides the AI governance discovery and evidence layer the CMDB was not designed to provide. For organisations that want AI agents in their CMDB as well as governed through AETHER Pulse, the outputs are complementary.

Frequently Asked Questions

Can we use ServiceNow's AI governance features instead of a dedicated AI inventory tool?

ServiceNow and similar ITSM platforms are adding AI governance modules addressing policy management, risk register, and workflow components well. They do not, in most implementations, address programmatic OAuth grant discovery across external platforms or generate cryptographically signed evidence packs. Evaluate specific vendor capabilities against the three gap criteria above.

How does an AI inventory differ from a software asset register?

A software asset register records software licences and applications: IT-managed assets procured through formal channels. An AI inventory discovers AI agents operating through OAuth grants, including those not procured formally. The discovery mechanism, scope, and governance outputs are all different.

See How AI Governance Discovery Works →

Working on Article 26 readiness, deployer-side governance evidence, or AI agent risk at a regulated firm? We'd value 15 minutes of your perspective.

Start a conversation