What Is an Agent Inventory?

TL;DR

An agent inventory is the record of every agent that exists, not just the ones somebody approved, and the hard part is not the schema. It is keeping the fields filled after launch.

There is a public inventory you can audit yourself. OMB publishes the US federal AI use case inventory as CSV: the 2025 file holds 3,611 individually reported use cases from 41 agencies across 36 columns, with 445 flagged high-impact. The schema is good. Among those 445 high-impact entries, 318 leave the ongoing-monitoring column blank and 40 record monitoring as established.

The common reading is that inventory is a spreadsheet problem, solved once someone owns the spreadsheet. It is a freshness problem. A complete record on launch day decays into a plausible-looking guess within two quarters, and nothing in the tooling announces that it happened.

We are not saying inventory is the control. It isn't. An inventory decides nothing and blocks nothing. It is the substrate every later control reads from, which is why a stale one is worse than an obviously empty one.

What to do today: pick the three fields you would need during an incident, owner, reachable systems, and last review date, and make those three mandatory and machine-populated. Leave the other thirty optional.

Overview

Agents accumulate in places nobody was assigned to watch. A notebook a data-science team wired to a scheduler. An OAuth grant a sales rep clicked through in April. A service account a departed engineer left with standing access to the warehouse. None of those appear on an org chart and none of them wait for permission to exist.

Discovery is what finds them. The inventory is what happens next: one record per agent, stating what it is, who is accountable, what it can reach, and whether anyone has checked on it recently. Skip that second step and discovery just produces a longer list nobody reads.

Two adjacent posts here cover building an inventory and how an inventory differs from a registry. This one is about the definition and the failure mode: what belongs in a record, where the fields come from, and why the field that decays first is the one an incident responder needs.

What the Standards Already Say

The instinct that inventory is a new problem is worth resisting, because three established frameworks already specify one and their wording transfers almost unchanged.

NIST's AI Risk Management Framework puts it in the GOVERN function. GOVERN 1.6 reads: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." The second clause is the interesting one. Resourcing by risk priority is an argument against uniform depth, which is exactly what most inventory projects get wrong by demanding forty fields for every entry.

NIST SP 800-53 Rev 5 control CM-8 has been the system component inventory control for years. It requires an inventory that "Accurately reflects the system", "Includes all components within the system", "Does not include duplicate accounting of components or components assigned to any other system", and "Is at the level of granularity deemed necessary for tracking and reporting". Read those four as acceptance criteria for an agent inventory and they hold without amendment. The duplicate-accounting clause bites hardest, because the same agent routinely appears once as an OAuth client and once as a container.

CIS Critical Security Controls put asset inventory at Control 1, first of eighteen, defined as the duty to "Actively manage (inventory, track, and correct) all enterprise assets ... to accurately know the totality of assets that need to be monitored and protected within the enterprise". Agents are not in its list of asset types. The verb is what transfers: actively manage, not initially record.

Regulators are converging on registration as a formal act. Under Article 49 of the EU AI Act, providers of high-risk systems register before placing them on the market, and public authorities deploying such systems register themselves and the use, in the EU database referred to in Article 71. For high-risk systems there will eventually be an external inventory yours has to agree with.

Why Informal Tracking Breaks Down

Before anyone builds an inventory, tracking is informal, and for a reasonable cause: nobody was assigned to own agent visibility as a job. The information exists. It never exists in one place.

• A platform team keeps a spreadsheet of the agents it deployed itself.
• Individual teams document agents, sporadically, in tickets and READMEs.
• SaaS-embedded agents live only inside a vendor's own admin console.
• OAuth-connected agents surface as app grants in identity logs, if anyone looks.
• Coding agents exist as tokens in a developer's shell history.

Each source captures a slice and treats it as the picture. Take a legal team that authorizes a contract-review agent through a vendor marketplace listing. Legal knows it exists, because they requested it. IT can see the OAuth grant behind it, since the agent now holds a standing read scope into the document management system. Neither team holds both facts, and nothing forces them to compare notes.

Scale is what makes this stop being survivable. Palo Alto Networks' 2026 Identity Security Landscape, a survey of more than 2,900 security decision-makers, reports 109 machine identities per human in the enterprise, up from 82:1 a year earlier, with "40% of those agents already have access to organizational data". At that ratio, "we know our agents" is a claim about arithmetic, and the arithmetic does not support it.

one inventory record per agent --> owner, access, risk, review date OAuth grant -----/ code repo -------/ Five partial views, reconciled into one record. -->

Figure 1 — Five sources that each see a slice of an agent's existence, reconciled into a single record.

What an Inventory Records

A useful inventory captures more than a name. It holds the operational context that ownership, security and governance decisions depend on, and the honest way to design it is to sort fields by whether they can be populated by a machine.

Table 1 — Twelve fields, sorted by whether a machine can fill them. The four that cannot are the four that go stale.

Granted scopes against observed scopes is the most useful pair in the table, and almost nobody records both. Granted is the ceiling. Observed is what the agent has ever actually needed. The delta is permission you carry with no evidence it is used, and it is computable from data you already have whenever the audit trail records the tool name on every call.

A Real Inventory, Field by Field

Most writing about inventories is hypothetical. This one does not have to be, because there is a large public inventory with a documented schema.

OMB Memorandum M-25-21, dated 3 April 2025, requires every covered agency to "Publicly release an AI use case inventory consistent with OMB instructions", annually, under section 3(b)(v). The Department of Defense is exempt from inventorying individual use cases and Intelligence Community elements are excluded. The consolidated result ships as CSV in a public repository.

We pulled the 2025 file and counted. Its 36 columns include agency, use_case_name, contact_email, development_stage, is_high_impact, topic_area, problem_solved, system_outputs, has_pii, has_custom_code, and a block of high-impact safeguard fields: hi_testing_conducted, hi_assessment_completed, hi_independent_review, hi_ongoing_monitoring, hi_failsafe_presence, hi_appeal_process.

That is a good schema. Owner field, lifecycle field, risk flag, and explicit columns for the controls that are supposed to exist. Then the counts:

Table 2 — Counted directly from the 2025 consolidated CSV. High-impact means AI "with an output that serves as a principal basis for decisions or actions with legal, material, binding, or significant effect" under M-25-21.

Two of those rows point in opposite directions.

The 314 retired entries are the inventory working correctly. A record that survives decommissioning with its state changed is what you want, because "this agent was retired in March" is an answer and a missing row is not.

The 1,115 rows without a contact email are the freshness problem in its purest form. A row with an empty owner field cannot be reviewed, escalated or retired by anyone except the person who wrote it. A blank does not mean nobody owns it. It means finding out costs a week.

None of this is federal incompetence. The fields are new, reporting lags reality, and blank means unreported rather than absent. The lesson is structural and it applies to every private inventory too: the schema is the easy part, and the columns requiring a human to type something are the columns that end up empty in the rows that matter most.

Classifying Agents

Type shapes how an agent should be reviewed, so an inventory has to distinguish between them rather than treating every entry as an interchangeable line item.

• Internal assistants that answer questions or draft content for employees.
• Workflow automations that move data and trigger actions across systems.
• Coding and engineering agents operating inside development environments.
• Third-party agents brought in by vendors or partners.
• SaaS-embedded agents shipped inside tools the business already licenses.

How an agent gets triggered matters as much as what it is. Some act only when a person prompts them. Others run on a schedule or fire on events with nobody watching in the moment. An HR onboarding agent that provisions accounts the instant a new-hire record appears behaves very differently, from a risk standpoint, than a legal assistant that drafts a clause when an attorney asks.

OWASP's Top 10 for Agentic Applications, published 9 December 2025, gives the classification a security reason to exist. Two of its ten categories are ASI03 Identity and Privilege Abuse and ASI10 Rogue Agents. A rogue agent is definitionally one your inventory does not contain, which makes coverage a control objective rather than a hygiene metric.

Filling It Without Asking Nicely

The inventories that stay current are the ones fed by protocols rather than by people remembering. Three sources are worth wiring up, and all three are machine-readable today.

MCP servers answer tools/list, and the 2026-07-28 revision makes that answer stable enough to trust: the advertised tool set "MUST NOT vary per-connection or as a side effect of other requests on the connection", though it "MAY vary by the authorization presented on the request". So a periodic tools/list as a given agent's identity returns that agent's real capability surface, not a documented one. That is the tools and integrations row of Table 1, populated without a ticket.

A2A publishes an Agent Card, "a JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements", carrying name, description, url, version, capabilities, skills, securitySchemes and provider, discoverable at a well-known URI. Version 1.0.0 is current. An inventory that ingests Agent Cards gets its identity and capability fields free from any agent that publishes one.

SPIFFE covers the identifier. A SPIFFE ID "is a string that uniquely and specifically identifies a workload", in the form spiffe://trust domain/workload identifier, carried by credentials that are "short lived, rotated frequently and automatically". Use one as the primary key and the join between inventory, audit log and authorization decision is a single string rather than a fuzzy match on names.

inventory record Audit log (observed tool calls) --------/ Human input (owner, purpose, review date) -- dashed, the only path that decays -->

Figure 2 — Four machine-fed paths and one human one. The dashed edge is where inventories go stale.

What Breaks Without One

Skip the inventory and none of this goes away. Agents still get provisioned, still accumulate access, still outlive the person who built them. What disappears is the ability to answer questions about them on demand.

At small scale that is survivable. A team running three agents holds the whole picture in someone's head, and usually does. That stops working somewhere between a dozen agents and a hundred, and it stops quietly. Nobody announces the moment tribal memory fails. It gets discovered during an incident, when the question is "what can this thing reach" and the honest answer is a guess.

The real cost sits in the response, not the incident. A security team investigating a compromised credential needs to know, in minutes, everything that credential touches. Without an inventory that is a scramble across five admin consoles plus whoever still remembers building the thing. Palo Alto's survey prices the neighbouring version of this problem: disconnected identity silos add "an average of 12 hours per identity-related incident".

Regulation attaches clocks to the same gap. Article 73 of the EU AI Act requires a serious incident reported "not later than 15 days" after awareness, 10 days where a person has died, two for widespread infringement. Article 26(6) requires deployers of high-risk systems to retain logs "at least six months". Neither is satisfiable if you cannot determine which system was involved.

Where Fabriq Fits

Agentic Fabriq holds the machine-fed half of Table 1 as a side effect of how it works rather than as a reporting feature. Credentials live per user in a vault and get attached server-side at the moment of the call, so the credential-owner and reachable-systems fields are facts about 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. Token refresh runs automatically with last-used tracking, which is the closest thing to a real staleness signal on a connection.

It is not the inventory of everything. Agents nobody connected through it are invisible to it, exactly as an identity provider is blind to a credential nobody minted there. And clearing a vault copy of a credential is not the same act as invalidating a grant upstream, so retiring an inventory row does not by itself end the agent's access at the provider.

Frequently Asked Questions

What is an agent inventory? A system of record with one entry per agent, sanctioned or not, holding at minimum its identifier, owner, purpose, reachable systems, granted permissions, lifecycle state and last review date. It describes. It does not decide.

What is the difference between an agent inventory and an agent registry? The inventory aims at coverage and includes agents nobody approved. The registry records trust decisions: which agents are sanctioned, on what terms. Conflating them corrupts both, because you end up excluding the unapproved agent from the inventory in order to keep the registry clean, and the unapproved agent is the one you were looking for.

Is an agent inventory required by law? Not by that name. NIST's AI RMF asks for mechanisms to inventory AI systems at GOVERN 1.6, NIST SP 800-53 CM-8 requires a component inventory that accurately reflects the system, and EU AI Act Article 49 requires registration of high-risk systems in the EU database. US federal agencies must publish an AI use case inventory annually under OMB M-25-21 section 3(b)(v).

What fields should an agent inventory have? Start with the four you would need at 2am: identifier, owner, reachable systems, and where its actions are logged. Add model and version, granted and observed scopes, trigger type, sanction state and last review date. Resist the forty-field version, and note that NIST AI RMF GOVERN 1.6 explicitly scales the mechanism "according to organizational risk priorities".

How do you find agents nobody registered? Reconcile sources that were never meant to be an inventory: OAuth grants in the identity provider, vendor admin consoles, service accounts with no human owner, outbound traffic to model providers, CI tokens. Then wire the machine-readable paths so new agents register themselves: tools/list for capability, Agent Cards for identity, a SPIFFE ID as the key.

How often should an agent inventory be reviewed? Often enough that the last review date is never the oldest field in the row. The failure mode is not an unreviewed inventory, it is a reviewed one whose reviews all happened in one quarter eighteen months ago. CIS Control 1's framing is the useful one: actively manage, not initially record.

Does a CMDB work as an agent inventory? Not on its own. A CMDB models assets by where they sit and has no column for permission scope or delegation model. Covered separately here, but the short version is to link the two rather than extend one into the other.

Conclusion

An agent inventory will not tell you whether an agent should exist. That is not its job. Its job is making sure that once an agent does exist, somebody can find it, name its owner, and see what it touches, and that this stays true long after the person who built it has moved on.

The lesson from the one large inventory we can all read is about maintenance, not modelling. The federal schema is sound and the controls columns exist. Most high-impact rows do not fill them in, because filling them in needs a person to type something and nothing blocks when they don't. Design against that. Machine-populate every field you can, keep the human fields to a handful, and put the last review date somewhere it embarrasses someone.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — stable term ids for two of the columns above, the delegation model an agent runs under and the resource surfaces it can reach, so inventory rows from different teams compare.
• NIST AI Risk Management Framework 1.0 — GOVERN 1.6, "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities", and MANAGE 4.1 on post-deployment monitoring.
• NIST SP 800-53 Rev 5, CM-8 System Component Inventory — the four accuracy criteria, the no-duplicate-accounting rule, 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", the first of the eighteen controls.
• OMB Memorandum M-25-21 — dated 3 April 2025; the definition of high-impact AI, the annual public inventory duty at 3(b)(v), and the DoD and Intelligence Community carve-outs.
• 2025 Federal Agency AI Use Case Inventory, OMB — the consolidated CSV behind Table 2: 3,611 use cases, 41 agencies, 36 columns, 445 high-impact, and the hi_* safeguard columns counted directly from the file.
• EU AI Act Article 49: Registration — provider and public-authority registration in the EU database referred to in Article 71, and the non-public section for law-enforcement uses.
• EU AI Act Article 26: Obligations of deployers — paragraph 6, 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.
• Model Context Protocol specification, 2026-07-28, Tools — tools/list, the rule that the tool set must not vary per connection but may vary by the authorization presented, and the tool definition fields.
• A2A Protocol specification — the Agent Card definition and its name, description, url, version, capabilities, skills, securitySchemes and provider fields; current release 1.0.0.
• SPIFFE concepts — the SPIFFE ID format, the definition of a workload, and SVIDs with short-lived automatically rotated keys.
• OpenTelemetry semantic conventions, GenAI attribute registry — gen_ai.agent.id, gen_ai.agent.name, gen_ai.agent.version, gen_ai.tool.name and the operation names, all at Development stability.
• OWASP Top 10 for Agentic Applications 2026 — published 9 December 2025 by the OWASP GenAI Security Project, with more than 100 contributors.
• OWASP Top 10 for Agentic Applications, category list — the ASI01 to ASI10 names used here, including ASI03 Identity and Privilege Abuse and ASI10 Rogue Agents.
• 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 and the 12 hours added per identity-related incident. </content>