Agent Inventory vs. CMDB

Overview

Take an infrastructure-automation agent that began provisioning resources outside its intended environment. Someone notices, and a security review opens. The reviewer pulls the configuration-management record for the agent's container and finds a hostname, an owner, an environment tag. Nothing wrong with any of it, and none of it answers the question the review needs answered: was this agent permitted to provision there, and if not, what else has it touched that nobody has checked?

The stall is a category mismatch, not a tooling bug. A configuration management database was built to describe infrastructure, meaning things that sit somewhere and depend on other things. An agent decides things, and a record built for static infrastructure has nowhere to write down a decision boundary.

Most enterprises already run a CMDB, and the instinct when agents arrive is to reuse it rather than stand up something new. That instinct is half right and it is not foolish. The CMDB stays valuable. It simply does not hold the layer that governs an agent, and this post is about where exactly the seam falls, which fields land on which side, and why the CMDB's own quality metrics will tell you everything is fine.

What a CMDB Tracks

Under ITIL 4, a configuration item is "a component of the IT infrastructure that needs to be managed and controlled", and the CMDB is "a database that stores configuration information, including CIs, their attributes, and relationships". The purpose of the service configuration management practice is to "ensure that accurate and reliable information about the configuration of services, systems, and infrastructure components is available to support effective service management". Note what is being promised: accurate information about configuration.

The dominant implementation makes the model concrete. ServiceNow's documentation describes configuration items as entities that are part of your environment, and is explicit that they can be "a physical entity, such as a computer or router", "a logical entity, such as an instance of a database", or "Conceptual, such as a Requisition Service". Everything descends from the cmdb_ci table, and classes "inherit attributes and relationships, forming a CMDB hierarchy managed through the CI Class Manager". A laptop class extends the computer class, which extends the base class.

That structure earns its keep. It underpins incident management, change management, and the blast-radius question every change board asks before approving anything. When a database tier degrades, the CMDB says which services depend on it and who to page.

We would go further and say the fit is genuinely good for what it was built for. A configuration item does not choose to call a new tool at runtime, does not decide to read a table nobody pointed it at, and does not behave differently on a Tuesday than it did on a Monday. Static assets get a static schema, and inheritance is the right way to model them.

A Different Kind of Asset

An agent is not a server sitting in an environment. It is an actor. A single agent may act on behalf of a user, call several tools, hold delegated permissions, and touch sensitive data across multiple systems in one run. Its risk is not set by where it runs. It is set by what it can do.

In CMDB terms, the infrastructure-automation agent from the opening scene is a small containerized service with a couple of API dependencies, unremarkable next to a thousand other rows. Operationally, the same agent can spin up compute, open network paths, and provision storage in whichever environment its credentials reach. The container is low risk. The behaviour is not.

There is a scale problem behind the modelling problem. Palo Alto Networks' 2026 Identity Security Landscape, surveying more than 2,900 security decision-makers, reports 109 machine identities per human identity in the enterprise, up from 82:1 a year earlier, with 40% of agents already holding access to organizational data. A CMDB sized for servers and applications is not sized for a population that grows at that rate and whose entries each carry a credential.

Fields a CMDB Never Had

The reason you cannot simply extend the configuration-item schema is that the important agent fields are not attributes. Some are, and those extend fine. Others are relationships, functions evaluated at request time, or pointers into a different system.

Table 1 — Nine things a review asks about. Four of them are not attribute-shaped, which is the whole argument.

The fifth and sixth rows are where the modelling breaks, and MCP makes the reason explicit rather than philosophical. The 2026-07-28 specification says a server's advertised tool set "MUST NOT vary per-connection or as a side effect of other requests on the connection" but "MAY vary by the authorization presented on the request", because "credentials are per-request input, not connection state". An agent's real capability surface is therefore something you compute, per caller, per call. You can snapshot it into a CMDB field. What you have then is a cached value with no invalidation rule, which is a worse artifact than no value at all.

Here is the record we would actually keep, with the CMDB link as a first-class field rather than an afterthought:

agent_id:            spiffe://corp.example/ns/itops/sa/access-review-agent
display_name:        IT Access Review Agent 02
model_provider:      vendor-x / v4.2
delegation_model:    aact:delegation-model/autonomous   # no user impersonation
tool_source:         mcp://idp-tools.corp.example   # resolved per call
granted_scopes:      [idp.groups.read, ticketing.write, chat.notify]
observed_scopes:     [idp.groups.read, ticketing.write]
credential_owner:    iam-platform-team
credential_ref:      vault://agents/access-review-02
audit_log:           siem://agents/access-review-02
trigger:             scheduled (weekly)
sanction_state:      approved
risk_class:          medium                 # touches identity data
last_reviewed:       2026-05-04
cmdb_links:          [ci:idp-prod, ci:ticketing-app, ci:chat-int]

Two lines in there do work a CMDB row cannot. granted_scopes against observed_scopes is the delta between the ceiling and the floor, which is unexercised blast radius and is computable from the audit log. And cmdb_links is the field that stops this record from becoming a second, competing source of truth about infrastructure.

Why CMDB Health Misses Agents

This is the part that convinces operations people, because it is an argument from their own instrumentation rather than from first principles.

ServiceNow measures CMDB health on three KPIs. Completeness checks whether required and recommended attributes are populated, per class. Correctness tests records against data-integrity rules covering duplicates, orphaned records lacking required relationships, and staleness, where the default rule flags records unchanged for 60 days. Compliance audits records against predefined templates and scripted audits, the sort used for SOX or HIPAA expectations.

Those three are a good design for assets. Now apply them to an agent.

Table 2 — The CMDB's own quality metrics, and the agent failure each one cannot see.

The staleness row is the one worth sitting with. A rule keyed on the record's last-updated timestamp measures record churn. For a server, record churn is a decent proxy for whether anyone is maintaining the entry. For an agent, the two things that matter most, its scopes and its behaviour, change in other systems entirely. An agent CI can be green on all three KPIs while the agent has quietly acquired write access to a system nobody associated with it.

The Duplicate-Accounting Trap

NIST SP 800-53 Rev 5 control CM-8 has required a system component inventory for years, and its wording is a useful checklist here. The inventory must "Accurately reflect the system", "Include all components within the system", "Not include duplicate accounting of components or components assigned to any other system", and be "at the level of granularity deemed necessary for tracking and reporting".

The duplicate-accounting clause is where agent records go wrong fastest. One logical agent typically shows up as a container or serverless function, an OAuth client registration in the identity provider, one or more service accounts, and a row in a vendor's admin console. Model each of those as its own configuration item and you have four rows, all correct, none of which is the agent. Model only the container and the agent's access is invisible. Model only the OAuth client and its runtime is invisible.

Figure 1 — One agent, four legitimate configuration items. Without an agent-owned key, none of the four is the agent.

The resolution is a primary key that belongs to the agent rather than to any of its hosts, which is the taxonomy's aact:identity-model/per-agent-identity. A SPIFFE ID is a reasonable choice: it "uniquely and specifically identifies a workload" in the form spiffe://trust domain/workload identifier, and the credentials carrying it are "short lived, rotated frequently and automatically". Telemetry then joins on the same identity, since OpenTelemetry's generative-AI conventions carry gen_ai.agent.id, gen_ai.agent.name and gen_ai.agent.version alongside gen_ai.tool.name and gen_ai.tool.call.id. Those attributes are still at Development stability, so treat the names as a moving target, but the join key idea is sound today.

Connect, Don't Replace

None of this makes the CMDB irrelevant, and we would push back hard on any pitch that says otherwise. Agents depend on applications, APIs, data stores and service accounts, most of which are already configuration items, and the agent inventory should reference those records rather than re-describe them. Two parallel sources of truth drifting apart helps nobody, and rebuilding dependency relationships the CMDB already models correctly is waste with a new name on it.

The practical move is to treat the agent as a first-class entity in its own inventory and link each agent to the configuration items it relies on. From the CMDB side, a database scheduled for migration now shows which agents act against it and might need pausing. From the inventory side, an agent under review shows exactly which downstream systems it can reach.

There is also a records-retention reason to keep the audit pointer in the agent record rather than the CI. Under the EU AI Act, providers of high-risk systems keep automatically generated logs under Article 19 "for a period appropriate to the intended purpose", and Article 26(6) requires deployers to keep logs under their control for "at least six months" unless other Union or national law provides otherwise. A review that has to guess which log store holds an agent's calls is already over budget on a 15-day incident clock.

dead end |-- linked inventory: effective permission scope + audit log pointer + credential owner --> trail to a finding The inventory's cmdb_links field is what connects the two paths instead of leaving them separate. -->

Figure 2 — The same review taken two ways. A CMDB alone stalls at "what is it". A linked inventory continues to "what could it do, and who is accountable".

Back to the Review

Go back to the infrastructure-automation agent. With a linked inventory in place, the review stops stalling at the container record. It reads granted_scopes, confirms the target environment sits outside them, and reads observed_scopes to see when the agent first exercised the permission it should not have had. The audit_log pointer resolves to a store rather than to a question. Ten minutes later the credential owner is in a conversation they did not expect to have that day.

The CMDB still tells the reviewer which systems are involved and who owns the surrounding infrastructure, and it does that better than anything else in the building. It was never going to say what the agent was allowed to do. Until a record exists that does, every review like this ends at the same wall, and the CMDB's health dashboard will be green the whole time.

Where Fabriq Fits

Agentic Fabriq holds the rows of Table 1 that a configuration item cannot. It keeps credentials per user in a vault and attaches them server-side at the moment of the call, so the agent never handles the secret and the credential-owner relationship is configuration rather than recollection. Every request carries two identities, the agent and the acting user, and an agent's effective tool list is the intersection of the user's scopes and the agent's own, computed per call rather than stored. Action-level permissions are enforced in the backend, and each call lands in an audit record that carries both identities.

What it is not is a replacement for the CMDB, and it does not pretend to model your infrastructure. It also does not reach into a provider for you: clearing a vault copy of a credential is not the same act as invalidating a grant upstream, so retiring an agent in one place does not end its access at the SaaS provider.

Frequently Asked Questions

Can I just extend my CMDB to cover AI agents? Partly. Attribute-shaped facts extend fine: identity, model, version, delegation model, owner. What does not extend is effective permission scope and capability surface, because under MCP those are resolved per request against the caller's authorization rather than stored. A snapshot in a CI field is a cache with no invalidation rule.

What is the difference between an agent inventory and a CMDB? A CMDB models assets by where they sit and what they depend on, in service of incident and change management. An agent inventory models actors by what they are authorized and able to do, in service of review and authorization. Different question, different primary key, different freshness requirement.

Should the agent inventory live inside the CMDB platform? It can, and for many organizations that is the pragmatic answer, because the platform already has ownership data, workflow and an audit trail. Just make it a distinct class or table with its own quality rules rather than a set of custom attributes on an existing CI class, and keep a link field in both directions.

Why does CMDB health not catch agent drift? Because all three KPIs inspect stored values. Completeness checks whether attributes are populated, compliance checks them against a template, and the correctness staleness rule flags records unchanged for a default 60 days. An agent whose scopes changed in the identity provider has an untouched CMDB record, so nothing fires.

How do I avoid counting the same agent several times? Give the agent an identity that does not belong to any of its hosts and use it as the primary key, then treat the container, the OAuth client and the service accounts as linked items rather than as separate agents. This is CM-8's duplicate-accounting rule applied to a new asset class.

Does ITIL cover AI agents? Not as a distinct entity. ITIL 4's configuration item is "a component of the IT infrastructure that needs to be managed and controlled", and an agent is genuinely that, so nothing in the framework excludes it. What is missing is any notion of a configuration item that holds delegated authority, which is why the extension has to be a new record rather than a new class.

What single field matters most? The audit log pointer, if you are optimizing for incident response. Everything else in a review can be reconstructed slowly. Where the calls were recorded cannot, and the EU AI Act's Article 73 gives you 15 days to report a serious incident, 10 where a person died, two for widespread infringement.

Do we need both records from day one? No. Start with the CMDB you have and add one table with six columns: agent identity, owner, granted scopes, credential reference, audit log pointer, and links to configuration items. Six columns that are true beat thirty that are aspirational.

Conclusion

A CMDB and an agent inventory describe different layers of the same enterprise, and neither substitutes for the other. One maps what you operate. The other maps who is operating on your behalf and what they are authorized to do while they are at it.

The strongest reason to keep them separate is not taxonomy, it is measurement. A CMDB grades its own health on attribute completeness, duplicates, orphans and a 60-day staleness rule, and an agent can pass all four while its permissions change underneath. A record whose quality metrics cannot see the thing that makes it dangerous is not a record of that thing.

So build the inventory as its own record, key it on an identity that belongs to the agent, and link it back to the configuration items rather than letting the two drift apart. That combination is what turns a stalled review into a short one.

Sources

All URLs read 2026-09-29.

• Configuration management and the CMDB, ServiceNow product documentation — configuration items as physical, logical or conceptual entities, the cmdb_ci base table, and class inheritance through the CI Class Manager.
• Understanding CMDB Health, ServiceNow — the completeness, correctness and compliance KPIs, their sub-metrics, and the 60-day default staleness rule.
• ITIL Service Configuration Management — the ITIL 4 definitions of a configuration item and a CMDB, and the stated purpose of the service configuration management practice.
• NIST SP 800-53 Rev 5, CM-8 System Component Inventory — the accuracy and completeness criteria, the prohibition on duplicate accounting, and granularity left to the organization.
• CIS Critical Security Controls, Control 1: Inventory and Control of Enterprise Assets — "Actively manage (inventory, track, and correct) all enterprise assets", and the asset types it does and does not name.
• Model Context Protocol specification, 2026-07-28, Tools — the tool set must not vary per connection but may vary by the authorization presented, "credentials are per-request input, not connection state", and the tool definition fields.
• SPIFFE concepts — the SPIFFE ID format and definition, what counts as a workload, and short-lived automatically rotated credentials.
• OpenTelemetry semantic conventions, GenAI attribute registry — gen_ai.agent.id, gen_ai.agent.name, gen_ai.agent.version, gen_ai.tool.name and gen_ai.tool.call.id, all at Development stability.
• A2A Protocol specification — the Agent Card as "a JSON metadata document ... describing its identity, capabilities, skills, service endpoint, and authentication requirements"; current release 1.0.0.
• EU AI Act Article 19: Automatically generated logs — provider log retention "for a period appropriate to the intended purpose".
• EU AI Act Article 26: Obligations of deployers — paragraph 6, deployer logs kept "at least six months" unless other Union or national law provides otherwise.
• EU AI Act Article 73: Reporting of serious incidents — the 15-day, 10-day and two-day reporting clocks.
• 2026 Identity Security Landscape, Palo Alto Networks — 109 machine identities per human, up from 82:1, and 40% of agents already holding access to organizational data.
• 2026 Identity Security Landscape overview, Palo Alto Networks — the survey base of more than 2,900 cybersecurity decision-makers.
• Agent Access Control Taxonomy — the delegation model and identity model dimensions; the delegation enum in Table 1 and the delegation_model line in the record above, and per-agent-identity for the host-independent primary key.
• NIST AI Risk Management Framework 1.0 — GOVERN 1.6, mechanisms to inventory AI systems resourced according to organizational risk priorities. </content>