AI Agent Registry vs CMDB vs IGA: Where to Inventory

When an organisation starts counting its AI agents, three teams each claim the record: the AI governance team wants an agent registry, IT service management says agents are configuration items in the CMDB, and the identity team says agents are identities that belong in identity governance and administration (IGA). All three are partly right, and the failure is not choosing one but letting all three hold conflicting copies of the same fields. This guide is a system-of-record decision guide: which attributes each system should be authoritative for, how records synchronise, how discovery fits in, and how to choose the authoritative source when the systems disagree. It is for identity architects, CMDB and ITSM owners, AI platform leads and GRC teams. The registry data model itself is covered in the AI agent registry guide and agent access governance in the Identity Governance for AI Agents Guide; this page covers the boundary between the three systems.

Key takeaways

Short answer: authority is per attribute, not per agent. The registry owns what the agent is and is allowed to be, IGA owns who and what it can access, and the CMDB owns where it runs and what depends on it.
One immutable agent ID is the join key. Issue it in the registry at approval and carry it into the identity object and the configuration item, or reconciliation becomes guesswork on display names.
Discovery is evidence, not a record. Cloud AI platforms, identity providers, OAuth consent logs and gateways tell you what exists; they never become authoritative, they feed reconciliation.
Gate credentials on the record. If IGA or the identity provider can issue credentials to an agent with no approved registry entry, the registry is a history book, not a control.
Measure disagreement. The useful metrics are agents present in one system and missing in another, owner mismatches and credentials with no record, not raw counts.

What each system is for

Agent registry: the authoritative record of each approved agent as an AI actor: its purpose, autonomy level, model, tools and endpoints, risk tier, accountable owner, approval status and link to the AI register entry. NIST AI RMF GOVERN 1.6 asks that "mechanisms are in place to inventory AI systems", and NIST AI 600-1 GV-1.6-003 adds generative AI fields such as underlying foundation models and their versions, human oversight roles and data provenance. That is registry content.
CMDB: the operational record of configuration items and their relationships, used for change, incident, problem and service management. NIST SP 800-53 CM-8 asks for a component inventory that "accurately reflects the system", has no duplicate accounting and carries accountability information; CM-8(4) adds the individuals responsible for administering components.
IGA: the authoritative record of identities, their entitlements, ownership for access and certification history. NIST SP 800-53 AC-2 asks organisations to define permitted account types, assign account managers, require approvals for account creation and monitor use; IA-4 requires authorisation before assigning an identifier to a "service" or "device". For agents, this is where access decisions and their evidence live.
Discovery sources: cloud AI platform APIs, identity provider application and workload identity listings, OAuth consent grants, MCP and AI gateways, endpoint and code scanning. See the Shadow AI Discovery Guide and NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.

Side-by-side comparison

Attribute	Agent registry	CMDB	IGA
Unit of record	Agent definition and deployed instance	Configuration item and relationship	Identity, account and entitlement
Question answered	Is this agent approved, for what, at what risk?	What runs where, what depends on it, what changed?	What can it access, who approved that, is it still needed?
Primary consumers	AI governance, risk, audit, gateways and policy engines at runtime	Service desk, change management, incident and problem teams	Identity team, access reviewers, auditors, SOC
Update trigger	Approval, change of purpose, model or tools, retirement	Deployment, change record, discovery reconciliation	Joiner, mover, leaver events, access requests, certification
Threat it addresses	Unapproved or misdescribed agents, unknown model and tool changes	Unknown dependencies, untracked changes, slow incident scoping	Excess privilege, orphaned access, long-lived credentials
Typical failure	Spreadsheet nobody updates; not consulted before credential issue	Stale CIs, no owner, agents modelled as generic software	Agents treated as service accounts with no purpose or sponsor
Framework anchor	NIST AI RMF GOVERN 1.6; ISO/IEC 42001 B.4.2 to B.4.6	SP 800-53 CM-8; CSF 2.0 ID.AM-02, ID.AM-08	SP 800-53 AC-2, IA-4; CSF 2.0 PR.AA-01, PR.AA-05

Threat model for each record

Registry: the misrepresented agent

The registry protects against agents that are unapproved, or approved for one purpose and quietly extended. Threats include a builder adding a new tool or MCP server, a provider swapping the underlying model, or an agent being connected to a higher data class than its risk tier allows. If the registry is wrong, governance decisions and runtime policy that read from it are wrong.

CMDB: the invisible dependency

The CMDB protects against blind spots during change and incidents. An agent that calls a payment API, reads a customer database and runs on a shared container platform has dependencies that incident responders need within minutes. If the agent is not a CI with relationships, a change to the database or platform cannot be risk-assessed against it, and an incident cannot be scoped. See the Asset Inventory and CMDB Security Guide.

IGA: the orphaned credential

IGA protects against access that outlives its purpose. Agents accumulate OAuth grants, API keys and role assignments; when the owner leaves or the project ends, those credentials remain valid. The Vercel Context.ai OAuth breach shows the pattern: a consumer AI app was granted broad access through a corporate Google account, nobody reviewed or owned the grant, and after the vendor was breached the stolen token gave the attacker that account. A grant with no owner in any record is a grant no review will ever reach.

Attribute allocation: the system of record for each field

Each attribute has one authoritative system. Others may hold a read-only copy for their own purposes, but they never edit it.

Attribute	Authoritative system	Copied to	Why there
Agent ID (immutable, never reused)	Registry	IGA, CMDB, identity provider, gateways	Issued at approval; the join key for everything else (IA-4 prevents reuse of identifiers)
Purpose, intended use, autonomy level	Registry	CMDB (summary)	Governance attribute, approved by the AI governance process
Risk tier	Registry	IGA, CMDB	Drives review frequency in IGA and change risk in the CMDB
Accountable business owner	Registry	IGA, CMDB	One owner answerable for the agent existing at all
Model, model version, provider	Registry	CMDB (as a dependency)	Model change is a governance event; NIST AI 600-1 GV-1.6-003 lists foundation models and versions
Tools, MCP servers and APIs it may call	Registry (approved set)	Gateways, policy engine	Approved capability; actual grants are checked against it
Agent Card or endpoint metadata	Registry	Discovery service	Self-description must be verified against the approved record
Identity objects (workload identity, app registration, service principal)	IGA (with identity provider)	Registry (reference)	Identity lifecycle is an IGA process
Delegator (person on whose behalf it acts)	IGA	Registry	A delegated access relationship that must be reviewed and revoked with the person's lifecycle
Entitlements, scopes, roles	IGA	Registry (summary for drift checks)	Access is requested, approved and certified in IGA
Credential type, issue date, expiry (not the secret)	IGA or secrets manager	Registry	Rotation and expiry are access lifecycle controls
Access sponsor and certification status	IGA	Registry	Evidence of review belongs with the review system
Hosting runtime, environment, region	CMDB	Registry	Operational fact maintained by deployment and discovery
Upstream and downstream dependencies	CMDB	Registry (reference)	Relationship mapping is the CMDB's purpose
Support group, change records, incidents	CMDB and ITSM	None	Service management processes
Lifecycle status	Registry (approval state); IGA (identity state); CMDB (operational state)	Each reads the others	Three states, reconciled: a retired agent must have disabled identities and a retired CI

Two rules keep this workable. First, never store secrets in any of the three: store the credential identifier and expiry, not the value. Second, keep the owner single-sourced. The registry owner is accountable for the agent existing; the IGA sponsor is accountable for its access and is usually, but not always, the same person. When they differ, record both and the reason. The NHI Ownership Guide covers the ownership model.

Sync patterns

Described in words, the reference architecture has the registry as the hub for agent existence, IGA as the hub for access, the CMDB as the hub for operations, and a reconciliation job comparing all three with discovery.

Registry first, gated provisioning: a new agent is requested and approved in the registry, which issues the agent ID. An event (webhook or queue message) triggers IGA to create the identity object with the agent ID as a correlation attribute, owner and risk tier. IGA refuses identity creation for agent types without a registry ID. This is the pattern that makes the registry a control.
Registry to CMDB as a CI class: on approval or deployment, the registry creates or updates an agent CI with the agent ID as a reconciliation key; the deployment pipeline then adds runtime and dependency relationships. The CMDB never creates agent CIs from scratch except as discovered, unconfirmed items.
IGA to registry, access summary: IGA publishes entitlements, credential expiry and certification outcome back to the registry on change, so the registry can compare actual access with the approved tool set and flag drift.
Discovery into reconciliation: scheduled or event-driven discovery from cloud AI platforms, identity providers, OAuth consent logs and gateways produces observed agents. Each observation is matched on agent ID, then on identity identifiers (client ID, workload identity), then flagged for triage. Matches update "last seen"; non-matches open a shadow agent case.
Retirement cascade: setting an agent to retired in the registry triggers IGA to disable identities and revoke credentials, and the CMDB to retire the CI. NIST AI RMF GOVERN 1.7 asks for processes to decommission AI systems safely; this cascade is the evidence.

Event-driven sync is preferable for creation and retirement, where delay is risk. Nightly batch reconciliation is acceptable for descriptive attributes. NIST SP 800-53 CM-8(2) asks that inventory currency, completeness and accuracy be maintained with automated mechanisms, which in practice means reconciliation runs without a person starting it. See the NHI Inventory Reconciliation guide for matching logic.

Choosing the authoritative source when systems disagree

Disagreement	Which system wins	Action
Identity exists in identity provider, no registry entry	Neither: treat as shadow agent	Assign provisional owner from the creator, restrict or suspend per policy, require registration within a set period
Registry says retired, identity still enabled	Registry	Disable identity and revoke credentials immediately; investigate why the cascade failed
Owner differs between registry and IGA	Registry for accountability, IGA for access sponsor	Confirm with both people; record the split or correct one
Entitlements exceed approved tool set	Registry (approved set)	Remove excess access in IGA or raise a registry change for approval
CMDB shows a model version the registry does not	CMDB for the observed fact	Registry raises a change review: a silent model change is a governance event
Agent CI exists, no deployments or sign-ins for 90 days	Discovery evidence	Owner confirms or retires; cascade retirement

Decision guidance

Where should agents be inventoried first? In the registry, if you can gate credentials on it. If you cannot yet, start with IGA, because access is where agents cause harm, and add the registry as the approval front end.
Can the CMDB be the registry? It can host the registry if it supports a dedicated agent class with governance fields, approval workflow and an API that IGA and gateways can query at runtime. If the CMDB is already stale for ordinary servers, adding agents to it will not fix that; build the registry separately and sync.
Can IGA be the registry? IGA can hold identity-centric fields well, but it is not usually the right home for model version, tools, autonomy level or AI register links. Extending IGA schemas to carry them works for small estates; at scale a separate registry keeps IGA focused on access.
Small organisation (tens of agents, one platform): one register in the platform or a controlled table, synchronised to IGA, with agents represented in the CMDB only if the CMDB is already used for incident management.
Large organisation (hundreds of agents across low-code, cloud AI platforms and SaaS): dedicated registry with an API, event-driven sync to IGA and CMDB, discovery from every platform and a weekly reconciliation report. The AI Agent Lifecycle Management Guide covers the lifecycle states.
Regulated environments: keep the AI register (system level, for regulators and auditors) separate from the agent registry (instance level), linked both ways; see the AI Register and AI Inventory Template.

Worked scenario: a customer service agent

A support team builds an agent that reads tickets, queries the order system and issues refunds up to a limit.

Registry: the request records purpose, autonomy (refunds within limit without approval, above it with human approval), model and version, tools (ticketing API, order lookup, refund API), risk tier high, business owner the head of support. Approval issues agent ID AGT-0142.
IGA: the registry event creates a workload identity tagged AGT-0142 with the head of support as sponsor. Access requests for the three APIs are approved against the registry's tool list; refund scope is limited by amount. Certification is quarterly because the tier is high.
CMDB: the pipeline creates CI AGT-0142 on the container platform with relationships to the ticketing service, order database and payment service, and a support group.
Drift: three months later a developer adds an email-sending tool. Gateway discovery observes calls to the mail API from AGT-0142; reconciliation compares them with the registry's approved tool set and opens a change review. IGA shows a new scope granted outside the request process, which the review removes until the registry change is approved.
Retirement: when the agent is replaced, setting AGT-0142 to retired disables the identity, revokes the credentials and retires the CI in one cascade, and the reconciliation report confirms all three agree.

Implementation

Agree the attribute allocation in a short standard signed by the AI governance, identity and ITSM owners, using the allocation table above.
Define the agent ID format and add it as a correlation attribute in IGA, the identity provider and the CMDB agent class.
Run discovery once across all platforms before building sync, so you know the size of the estate and the reconciliation load.
Back-fill: register discovered agents with provisional owners and tiers; mark unregistered ones for triage rather than deleting them.
Build sync in audit mode: run reconciliation and report mismatches without blocking for two to four weeks; fix the data and the matching rules.
Turn on gating for one platform first: IGA refuses agent identities without a registry ID. Expand platform by platform.
Turn on the retirement cascade and test it on a non-production agent end to end.
Rollback: keep gating behind a configuration switch per platform so it can be relaxed to report-only if it blocks urgent work, with each bypass logged as an exception.

Detection and measurement

Registry coverage: share of agent identities in the identity provider with a matching registry ID (target 100% after gating).
Shadow agent rate: new unmatched observations per week from discovery, and median days to triage.
Owner agreement: share of agents where registry owner and IGA sponsor are the same, or the split is recorded.
Access drift: agents whose IGA entitlements exceed the registry's approved tool set.
Retirement completeness: retired agents with any enabled identity or active CI (target zero).
Staleness: agents with no sign-in or deployment for 90 days still marked active.

Alert on identity creation for agent-type objects without a registry ID, on new OAuth consents to AI applications, and on calls through AI or MCP gateways from identities with no registry match.

Common failure patterns

Stale CMDB as the source of truth. Agents loaded once into the CMDB by a project, never reconciled, then used for incident scoping. Responders trust a record that is months old.
Shadow agents with live credentials. Agents created in builder tools or connected through user OAuth consent never enter any record. The Vercel Context.ai case is the delegated-grant version of this.
Three owners, no accountability. The registry, IGA and CMDB each hold a different owner name, so reviews go to the wrong person and nobody retires the agent.
Agents as generic service accounts. IGA holds the identity but not purpose, delegator or tier, so certification reviewers approve access they cannot judge. See Agent Identity Recertification.
Display names as join keys. Reconciliation matches on names that builders change freely, producing duplicates and false shadow agents.
Retirement in one system only. The registry entry is closed but the identity stays enabled because no cascade exists.

Framework mapping

Framework	Reference	Primary system
NIST AI RMF	GOVERN 1.6 inventory of AI systems; GOVERN 1.7 decommissioning	Registry, with retirement cascade
NIST AI 600-1	GV-1.6-001 enumerate GAI systems; GV-1.6-002 inventory exemptions; GV-1.6-003 inventory entry fields	Registry
ISO/IEC 42001	B.4.2 to B.4.6 resource documentation (data, tooling, system and computing, human resources)	Registry, linked to CMDB
NIST CSF 2.0	ID.AM-02 inventories of software, services and systems; ID.AM-08 life cycle management	CMDB and registry
NIST CSF 2.0	PR.AA-01 identities and credentials managed; PR.AA-05 access permissions defined and reviewed	IGA
NIST CSF 2.0	GV.RR-02 roles and responsibilities; DE.CM-03 technology usage monitored	Registry owner fields; discovery
NIST SP 800-53 Rev. 5	CM-8, CM-8(2), CM-8(4), PM-5	CMDB and registry
NIST SP 800-53 Rev. 5	AC-2, AC-2(3), IA-4	IGA

NIST's NCCoE is running a project on software and AI agent identity and authorisation, which has published a concept paper and a summary of comments and is releasing resources on a rolling basis; expect guidance on agent identification and authorisation to develop from it.

Practitioner checklist

Publish an attribute allocation standard naming one authoritative system per agent attribute.
Issue an immutable, never-reused agent ID in the registry and carry it into IGA, the identity provider and the CMDB.
Make IGA refuse to create agent identities without an approved registry ID.
Store credential identifiers and expiry in IGA or the secrets manager, never secrets in the registry or CMDB.
Record the delegator for any agent acting on a person's behalf, and tie it to that person's leaver process.
Feed every discovery source into one reconciliation job and open a case for each unmatched agent.
Build a retirement cascade from the registry to IGA and the CMDB and test it end to end.
Report registry coverage, shadow agent rate, access drift and retirement completeness monthly.

AI Agent Registry vs CMDB vs IGA: Which System Owns Each Agent Attribute