Agent Registry vs. Agent Inventory

Overview

Say the two words out loud and most of the disagreement dissolves. An inventory records what exists. A registry records what was reviewed. Nobody would confuse those two jobs, and yet the terms get swapped constantly, including by the vendors shipping both.

That is partly vocabulary drift, and there is no standards body handing down correct definitions here the way there is for, say, a token format. What is not drift is the operational difference underneath. One record has to be comprehensive, including the things nobody wants found. The other has to be selective, including only what someone has vouched for. Build one system to do both and it does both badly: either everything discovered is treated as sanctioned, or everything unreviewed drops out of view.

Definitions on their own are covered in what is an agent inventory and what is an agent registry. The comparison with a CMDB has its own post. What follows is the seam between the two records: how each is populated in 2026, what the available tools collect, and the reconciliation that makes the pair worth more than either half.

Two Different Questions

The inventory asks what agents we have. Comprehensive by design: if an agent exists and touches enterprise systems, it belongs there, sanctioned or not.

The registry asks which agents may operate. Selective by design: an entry requires an owner, a stated purpose, scoped permissions and a lifecycle state.

Table 1 — The same seven questions answered two different ways. The rows that matter most are the fourth and the last.

The fourth row is where collapsing the two records does real damage. In an inventory, a missing entry is a visibility gap. In a registry, a missing entry is supposed to be a denial. One system cannot hold both meanings for the same absent row.

NIST's AI RMF is a useful tiebreaker on the first row, because it defines the broad record without smuggling approval into it. GOVERN 1.6 describes an inventory as "an organized database of artifacts relating to an AI system or model", and the attributes it suggests recording are documentation, links to source code, incident response plans, data dictionaries and "AI actor contact information". Nothing in that list is a decision. Its coverage guidance is similarly blunt: inventory all systems, or at minimum the high-risk ones. Coverage is the inventory's whole job, and judgment is somebody else's.

The Inventory: Everything That Exists

The inventory is populated by discovery, not by request, and in 2026 the discovery surfaces are specific enough to name.

Consent logs are the highest-yield source, because most shadow agents arrive as an OAuth grant rather than a deployment. Microsoft Defender for Cloud Apps exposes an OAuth apps view built for exactly this sweep: filter by permission level and by how common an app is, use the saved query for "Apps authorized by external users", and sort on the Last authorized date, which the documentation suggests using to find apps that "may no longer be required". You can set a rule to notify you when an app "requires high permissions and was authorized by more than 50 users", and remediation is a ban or a revoke, per app or per user.

Platform registries are the second source. The Microsoft 365 admin center's agent list groups agents as Microsoft, external partner-built, published by your org, or shared by creator, and it exports over 30 attributes per agent including status, channel, date created, last modified, publisher, version, owner and the agent's instructions. There is a preview Graph endpoint for it, which the documentation labels, revealingly, "Get all agents in your inventory":

Connect-MgGraph -Scopes 'CopilotPackages.Read.All'
$uri = "https://graph.microsoft.com/v1.0/copilot/admin/catalog/packages"
do {
    $response = Invoke-MgGraphRequest -Method GET -Uri $uri
    $response.value | ForEach-Object { Write-Host $_.displayName }
    $uri = $response.'@odata.nextLink'
} while ($uri)

Two counters on that page are pure inventory logic. One reports agents without owners, which happens when the user who created a shared agent is deleted from the organization. The other reports unmanaged agents, defined as agents "created or managed outside of Agent 365, without its risk protection and observability". A registry has no way to express either number, because both describe things that were never registered.

What discovery does not reach is worth stating plainly. The public MCP Registry is a catalog of publicly reachable servers and "does not support private servers", so it will never enumerate the internal server on mcp.acme-corp.internal. A2A agents publish their own capability documents at /.well-known/agent-card.json, which only helps if you already know the host. Anything behind a personal API key, in a notebook, or on an unmanaged laptop shows up in your egress logs or nowhere.

A healthy inventory entry records where the agent runs and how it was found, which credentials it appears to hold, what it can reach, who seems to own it, and whether it looks active, idle or abandoned. Plenty of entries stay partial. An unverified owner is still a useful fact, because it names a gap.

The Registry: Everything That's Trusted

The registry is populated by a process, not a scanner. An entry exists because someone proposed it, someone reviewed it and someone authorized it. Where the inventory tolerates ambiguity, the registry refuses it.

An entry is a commitment: a named accountable owner, a documented purpose and intended scope, explicit permission boundaries, managed credentials, an audit binding, and a lifecycle state with a date the approval expires.

Registration also has a legal form in some jurisdictions now, and the legal form is narrow in exactly the way the internal one should be. Article 49 of the EU AI Act requires providers of Annex III high-risk systems to "register themselves and their system in the EU database" before the system is placed on the market. Article 49(2) extends that to providers who concluded their system is not high-risk under Article 6(3), so even the exemption gets recorded, and Article 71 makes that database public for Article 49 entries. Nothing there resembles a scan. Somebody asserts something and signs their name to it.

The registry is also turning into something machines read, not only auditors. The Cloud Security Alliance's agentic identity paper, published 18 August 2025, sketches a registry whose entries hold naming-service names, decentralized identifiers and PKI certificates, resolvable by capability so that one agent can look another up before talking to it. Whether that particular design wins is open. The direction is not: an entry that only a human can interpret cannot participate in a call.

Take a finance reconciliation agent that posts adjusting entries to the general ledger. An entry means a finance owner, a written list of which accounts it may touch, a cap on transaction size, its own service identity rather than a borrowed login, and a log record for every entry it posts. That identity is the taxonomy's aact:identity-model/per-agent-identity: registered, carrying its own policy, revocable without touching anyone else. That is what turns "an agent that can write to the ledger" into "an agent we decided to trust with the ledger, within these limits".

Two Hundred Agents

Suppose discovery across an enterprise turns up two hundred agents. They are not the same kind of thing. Some are authorized production systems doing real work: a procurement agent triaging requests, an operations agent restarting failed jobs. Some are experiments a data team spun up last quarter and never cleaned up. Some are abandoned, the owner gone and the credentials still live. Some are third-party agents individual users connected to their own accounts. Some are simply unsanctioned, running with real access nobody approved.

All two hundred belong in the inventory. A much smaller number belong in the registry. If you want a sense of what "much smaller" looks like in a program that publishes its numbers, the 2025 federal consolidation reported 3,611 AI use cases across 56 agencies with 445 marked high-impact, which is roughly one in eight getting the heavier treatment.

We would resist treating the gap as a scoreboard to zero out by next quarter. Some of those two hundred should never be registered, the abandoned ones especially, and the right outcome there is decommissioning. A shrinking inventory and a growing registry are not the same kind of progress, and conflating them is a smaller version of the mistake this whole comparison is about. The federal inventory handles that case with a rule worth copying: a retired use case is reported as retired immediately after its final operational year, and only then drops out of the record.

How They Connect

In a working setup the two are stages in one flow rather than separate silos.

Figure 1 — Discovery feeds the inventory, review promotes entries into the registry, and the enforcement point feeds observed behavior back. The return arrow is the part most programs leave out.

The connection runs in both directions, and the reconciliation is a three-way diff rather than a single list.

Figure 2 — Three buckets from three sets. Each one has a different owner and a different remedy.

Bucket two is the one people forget. A registry entry that discovery can no longer find is drift in the other direction: an authorized agent quietly decommissioned or moved without anyone updating the record. Bucket three needs the audit log rather than either record, because the only place scope drift is visible is in what the agent actually called.

What to Measure

Four numbers are worth putting on a dashboard, and none of them is the total agent count.

Table 2 — Four numbers, three sources. The first is the honest shape of an agent estate mid-adoption.

The fourth one has survey context. The Cloud Security Alliance and Oasis Security surveyed 383 practitioners in August and September 2025 and found 24% taking more than a day to rotate or revoke an exposed credential, and 30% needing over a day just to triage a high-severity credential leak. The same survey found 16% not tracking when new AI-related identities are created at all, and only 14% describing creation and removal of AI identities as fully automated, against 27% doing it entirely by hand.

Those numbers are self-reported and sponsored by a vendor in the space, so treat them as a shape rather than a benchmark. The shape is consistent with the failure modes below.

What Goes Wrong

Two failures come from collapsing the records into one system, and two come from running both badly.

Everything discovered is treated as authorized. Governance disappears. The unsanctioned analytics agent and the abandoned experiment are legitimate now because a scanner found them. Discovery becomes a way of laundering shadow agents into trusted status.

Only registered agents are tracked. The organization goes blind to everything else: unsanctioned activity, third-party connections, forgotten experiments, all of it operating outside the field of view. A clean list of trusted agents tells you nothing about what else holds a live token.

The inventory goes stale between scans. The symptom is an agent that appears in an incident and not in the record, and the cause is usually a discovery source nobody owns. Consent events are continuous; a quarterly export is not.

The registry becomes documentation. The symptom is that deleting an entry changes nothing. If no enforcement point is aact:failure-behavior/fail-closed on a missing entry, the registry is a wiki page with better formatting, and the diff in Table 2 is the only thing keeping it honest.

OWASP's Top 10 for Agentic Applications, published 9 December 2025, ends its list at ASI10 Rogue Agents. That category only means anything against a record of what was sanctioned. Without the pair of records, a rogue agent and a normal one look the same from the inside.

Where Fabriq Fits

Agentic Fabriq sits at the enforcement end of that flow. Credentials live per user in a vault and get attached server-side at the moment of the call, so the agent never handles the secret, and an agent's effective tool list is the intersection of the user's scopes and the agent's own. Every call carries two identities, the agent and the acting user, into the audit record, which is what makes bucket three of Figure 2 answerable rather than theoretical.

It is not a discovery scanner, and it does not reach into providers for you. Clearing a vault copy is not the same act as invalidating a grant upstream, so that call stays yours to make.

Frequently Asked Questions

What is the difference between an agent registry and an agent inventory? An inventory is the record of every agent that exists, populated by discovery, and it is supposed to include the ones nobody approved. A registry is the record of agents that passed review, populated by people. Different population methods, different definitions of complete, different meaning for a missing row.

Do I need both? Yes, and in that order. A registry without an inventory cannot tell you what it is missing. An inventory without a registry cannot tell you what is allowed.

Can one tool do both? Tools can hold both records, and several do. What cannot be shared is the admission rule. The moment a scanner can create a registry entry, the registry means "found" instead of "approved", and you are back to one record.

Which comes first? The inventory. You cannot review what you have not seen, and the first pass at discovery usually reorders the review queue anyway.

Is the MCP Registry an agent inventory? No. It is a public metadata catalog of MCP servers, and it "does not support private servers", so it can neither enumerate your internal servers nor say anything about your agents.

How do I find agents nobody told me about? Start with OAuth consent logs, which is where most of them arrive, filtered by permission level and last-authorized date. Add your platform's agent list, then egress logs for calls to model and agent APIs from services that have no business making them. Shadow agents in depth are their own subject.

What should the gap between the two counts be? Not zero. Some discovered agents should be decommissioned rather than registered, so the number to watch is not the gap itself but how long an entry sits in it unresolved.

Is an Agent Card a registry entry? No. A card is self-published by the agent at its own well-known URL. It is a discovery input, and the party asserting the capabilities is the party you are trying to verify.

Conclusion

The argument over which term is more correct is a distraction from the relationship. The inventory answers what agents you have. The registry answers which of them are authorized. You need both, in that order, and the value is in the join rather than either table.

Discover broadly, on a schedule, from sources that generate events rather than reports. Authorize deliberately, with an owner and an expiry. Then run the three-way diff in Figure 2 and treat its three buckets as work items with different owners. That gap is data, not embarrassment, and it is the clearest single number an agent operations program can report.

Sources

All URLs read 2026-09-29.

• Investigate and remediate risky OAuth apps, Microsoft Defender for Cloud Apps — the permission-level and community-use filters, the external-user saved query, the Last authorized signal, the 50-user policy example, and ban or revoke as remediation.
• Agent Registry in the Microsoft 365 admin center — the four agent types, the ownerless and unmanaged counters, the 30-plus export attributes, and the preview Graph endpoint labelled "Get all agents in your inventory".
• What's new in Microsoft Entra Agent ID — registry convergence under Agent 365 and the sponsor workflows aimed at orphaned agents.
• The MCP Registry — a metadata catalog of publicly reachable servers that "does not support private servers", with security scanning delegated downstream.
• A2A: Agent Discovery — the /.well-known/agent-card.json path and the three discovery mechanisms.
• NIST AI RMF Playbook, GOVERN — GOVERN 1.6 defining an inventory as "an organized database of artifacts", and its coverage guidance.
• 2025 Federal Agency AI Use Case Inventory — 56 agencies, 3,611 use cases, 445 high-impact, and the reporting rule for retired use cases.
• EU AI Act Article 49: Registration — registration in the EU database, including for systems judged not high-risk under Article 6(3).
• EU AI Act Article 71: EU database for high-risk AI systems — public availability of Article 49 entries and the Commission as controller.
• The State of Non-Human Identity and AI Security, CSA and Oasis Security — 383 responses fielded August and September 2025: tracking, ownership, automation and time-to-revoke figures.
• Agentic AI Identity and Access Management: A New Approach, CSA — the agent registry, decentralized identifiers and naming-service model, published 18 August 2025.
• Agent Access Control Taxonomy — the identity model and failure behavior dimensions; per-agent-identity for what a registry entry commits to, and fail-closed for the posture that keeps a registry from becoming documentation.
• OWASP Top 10 for Agentic Applications — ASI01 to ASI10, including ASI10 Rogue Agents, published 9 December 2025.