Agent Inventory and the Agent Register: The Control You Need Before Agent Sprawl Becomes Identity Debt

Most teams do not have an agent governance problem first. They have an agent visibility problem first.

The failure mode is not exotic. A team stands up an agent to move work faster. It inherits more access than intended, gets wired into real systems, and quietly becomes one more identity with unclear ownership, fuzzy scope, and no clean answer when someone asks what it can actually touch.

That is not an AI story first. It is an identity story. It is effective access, delegated scope, and ownership debt showing up in a newer wrapper.

Three takeaways up front

Inventory tells you what exists. The Agent Register tells you what matters.
Discovery metadata is not governance, and it is definitely not authorization.
If an agent has identity, access, and runtime impact, it needs an owner, lifecycle, and evidence trail.

Picture a very ordinary failure mode. A new-hire onboarding agent gets stood up quickly, inherits broader directory and ticketing access than intended, gets promoted to production because it “works,” and six months later, nobody can explain why it can still read more than onboarding data. That is not model risk. That is identity debt with a task loop.

This is not me inventing a new category because agent hype needed fresh stationery. The NIST AI RMF Playbook already treats AI system inventories as a governance baseline. Microsoft is building agent identity and lifecycle controls into Entra Agent ID and the Agent Registry. Google’s A2A specification treats discovery and interoperability as day-two operational concerns. The market is no longer arguing about whether agents need governance. It is arguing about the minimum control surface required to prove ownership, scope, and effective access before something breaks.

This is a pressure test, not a new idea

The disciplines are familiar: inventory, ownership, scope, review, logging, and retirement. None of that is new. What agents do is turn familiar governance gaps into faster, quieter failures.

Speed is the first pressure point. Agents can be provisioned in minutes by developers, low-code builders, SaaS admins, or automated pipelines that never pass through the review path your identity program expects. Microsoft’s agent identity documentation is direct about this: the identity models built for humans and applications are not sufficient for enterprise-scale AI agents because agents can be created and destroyed faster than most review cycles are designed to catch.

Autonomy is the second. A traditional app waits to be called. An agent can initiate, decide, and act. That changes the risk profile of ungoverned access in ways a static CMDB record does not capture, and a quarterly access review will not catch in time.

Delegated scope is the third. Agents often inherit permissions from whoever provisioned them. That creates a gap between intended use and effective access, and that gap usually stays invisible until something breaks.

Cross-system reach is the fourth. Agents do not just sit behind one endpoint. They call tools, touch data, chain actions, and sometimes trigger downstream changes across systems that were never part of the original request.

If you have ever had to explain orphaned access, stale app registrations, or privileges that drifted beyond the original ask, you already know the pattern. Agents just compress the timeline and widen the blast radius.

That is why this is a pressure test, not a brand-new idea. The core disciplines still hold. The operating model just got faster, messier, and less forgiving.

Why the old mental model breaks

Traditional app inventory assumes a slower, cleaner world: a request exists, ownership is clear, scopes drift slowly, and boundaries are visible. Agents break those assumptions fast.

An agent can be live before the review starts. It can inherit more access than intended, add tools over time, and reach systems that were never part of the original ask. As Microsoft’s agent identity guidance makes clear, classic service-principal thinking is a poor fit here.

By the time someone asks what it can actually touch, you are already in effective-access territory, not intended-scope territory. That is why the Register matters. It gives you the burden-of-proof fields the old model often hand-waved: named ownership, approved use, actual reach, review cadence, and evidence when incident response or audit comes calling..

What a real Agent Register needs to capture

A register with just a name and an owner is a spreadsheet with a header row. It will not help you during an incident, it will not shrink blast radius, and it will not give you the receipts an auditor or responder needs when the burden of proof lands on your team.

A register earns its place when a tired human can open it during an incident and figure out ownership, approved scope, effective access, and likely blast radius in under five minutes. That bar lines up with the NIST AI RMF Playbook and the metadata model in Microsoft’s Entra Agent ID overview.

Here is what that looks like in practice:

Identity fields. Agent name or ID, environment, model or provider stack, version or build reference. Basic but non-negotiable.
Ownership fields. Business owner, technical owner, executive sponsor, incident contact. Not “the team.” Named individuals.
Purpose and scope fields. Stated purpose, allowed use cases, prohibited use cases, and data classification of data touched. The prohibited use cases column gets skipped constantly, and it is one of the most useful fields when something unexpected happens.
Access fields. Authentication method, scopes or entitlements granted, tools and APIs the agent can call, and downstream systems it can reach or modify.
Lifecycle fields. Provisioning date, last reviewed date, next review date, expiration or retirement date, and the criteria that trigger retirement. Agents should not be indefinite by default. If the use case is genuinely ongoing, that decision should be made explicitly and documented.
Evidence fields. Logging location, log retention period, last audit date, and known exceptions with approval references. Evidence fields are what separate a governance record from a governance decoration.

NIST recommends inventorying all AI systems, not just a subset, and naming a responsible individual or team for maintaining the inventory. That second point is the one that fails most often in practice. A register with no named maintainer is a register that will be six months stale when you actually need it.

Inventory vs. Register vs. Registry: the short version

This distinction is worth a minute because this is where teams start collapsing control boundaries that should stay separate.

If you already run a CMDB, service catalog, or app inventory, here is the clean way to think about it.

The Inventory is the scope. What do we have across the environment?
The Register is the governance. Who owns this agent, what can it touch, what is it approved to do, when was it last reviewed, and when should it stop existing?
The Registry is the plumbing. Where is this agent, how do you call it, what does it expose, and what authentication does it expect?

Google’s A2A specification makes the discovery layer concrete. Agent Cards describe server identity, capabilities, endpoint URL, and authentication expectations. Microsoft’s Agent Registry does the same kind of work for platform and runtime visibility.

Do not collapse those layers because it feels cleaner on a diagram. Your registry will not answer the 2 a.m. incident questions or carry the burden of proof when audit or incident response comes calling. It will not tell you who owns the agent, whether the scope is still justified, or whether anyone has reviewed it in the last 90 days. That is what the Register is for.

The operational use cases

Different teams ask different questions. A register only gets adopted if it answers the questions each team is actually asking.

Security wants to know which agents can reach regulated data, which have broad API access that was never scoped down, and which have not been reviewed in the last 90 days.

IAM wants to know who owns the identity, when access was last certified, and whether the agent is operating within its originally approved scope or whether scope has crept through tool additions or permission inheritance.

Platform and engineering want to know which agents are still active in production versus sitting in a dev environment nobody cleaned up, and which agents are sharing credentials with something else.

Audit wants evidence. Approval documentation. Review history. Log retention confirmation. The register needs to answer those questions without a forensic exercise.

Incident response is where it all comes together. When something goes wrong, the questions come fast: what could this agent reach, what did it actually do, where are the logs, who do I call right now? A register with incomplete evidence fields will slow every one of those answers down at exactly the moment you cannot afford it.

The NIST AI RMF Playbook frames inventories as tools that need to support both system-specific and organization-wide questions. That dual function is the whole point.

Best practices that hold up under pressure

The NIST AI RMF Playbook recommends maintaining a policy for inventories, naming a responsible individual or team, and inventorying all systems rather than a subset. Microsoft’s Agent ID page emphasizes observability, sponsorship, lifecycle controls, and secure defaults as the enterprise baseline.

Here is what that looks like when it is working:

Inventory all agents, not just the ones your team built. Low-code platforms, third-party integrations, and user-provisioned automations create agents outside your normal pipeline. If it has an identity and acts on behalf of a user or system, it belongs in the register.

Assign ownership before deployment. Not a team name. A person. Someone who can be reached when something goes wrong and who understands what they are accountable for.

Separate discovery from authorization. Knowing where an agent is and what it exposes is not the same as deciding what it is allowed to do. Keep those layers distinct.

Require a review date and an expiration date at provisioning. If the use case is genuinely ongoing, that is a decision, not a default.

Capture evidence-grade logs before go-live. Where do they go, how long are they retained, and how are they accessed? Define that before the agent is live, not after an incident.

Define retirement criteria before rollout. What signals that this agent is no longer needed? What happens to its credentials and permissions when it is decommissioned?

What to do on Monday morning

If you need a practical starting point instead of another framework diagram, start here.

Pull a list of every agent identity you can find, including low-code, SaaS-embedded, and user-provisioned automations.
Force named ownership onto every production agent. Not a mailbox. Not a team alias. A person who will answer the phone when something goes sideways.
Record what the agent can actually touch now, not what the original request said it would touch. Intended scope is not the same thing as effective access.
Add a last review date, next review date, and expiration date to every production agent record.
Make sure the logs exist somewhere that incident response can actually reach without a scavenger hunt. If you cannot pull receipts fast, you do not have control.

Discovery is not authorization

This one comes up more than it should.

Google’s A2A specification is explicit: the Agent Card describes server identity, capabilities, endpoint, and authentication expectations. Authorization is still enforced by the server’s own access policies and should follow least privilege. Being discoverable does not mean being trusted. Being callable does not mean being broadly authorized.

The governance failure this creates: teams treat discoverability as a proxy for approval. If the agent is in the registry, it must have been vetted. That logic breaks when the registry is a technical mechanism with no governance gate, which is the default for most current implementations.

Clean separation: the registry tells you what exists and how to reach it. The Register tells you whether it should be reached, by whom, under what conditions, and with what review history behind it. Those are different documents serving different purposes. Do not collapse them.

Anti-patterns from the field

These are not framework gaps. These are things that actually happen.

“The app registration is enough.” It captures the credential. It does not capture purpose, ownership, review cadence, data classification, or what happens when the agent is decommissioned. An app registration is the floor, not the register.

“The builder probably owns it.” Probably is not an incident contact. Ownership needs to be named, documented, and kept current as people move teams.

“We’ll document it after the pilot.” Pilots that go to production without documentation are how most ungoverned agent debt starts. An incomplete register at deployment is recoverable. No register at all is not, especially not under incident timeline pressure.

“It only reads data.” Read access to sensitive data is still sensitive access. Data classification belongs in the register regardless of whether the agent writes anything.

“We can reconstruct the access history later.” You cannot. Not reliably, not at 2am during an incident, and not in a way that satisfies an auditor. Evidence-grade logs need to be captured and retained from the start, not reconstructed after the fact.

“Temporary agents don’t need lifecycle controls.” Temporary agents that outlive their intended lifespan without controls become permanent agents with orphaned access. Temporary is a deployment decision. It is not a governance exemption.

Why this matters right now

NIST already treats AI inventories as a governance baseline in the AI RMF Playbook. Microsoft is productizing agent identity, lifecycle, and registry controls in Entra Agent ID. Google’s A2A work shows discovery and interoperability are moving from architecture talk to day-two operational reality.

Meanwhile, agents are already arriving through low-code platforms, embedded SaaS features, and developer workflows that move faster than most identity review paths were built to handle. Useful automation can show up before ownership, review, logging, and evidence trails.

So the question is not whether agents need governance. It is what a minimum control surface lets you prove ownership, scope, effective access, and blast radius before something breaks. The answer is not a brand-new doctrine. It is applying governance discipline that already works to a runtime that accumulates quiet access faster than most teams expect.

Agent Register template

Lightweight starting point. Spreadsheet, wiki, CMDB-adjacent table, internal governance system, whatever you actually use. Grounded in the NIST AI RMF Playbook and the metadata concepts in Microsoft’s Agent Registry and Google’s Agent Card spec.

Field	Description	Example
Agent Name / ID	Unique identifier	hr-onboarding-agent-v2
Environment	Deployment environment	Production
Model / Provider	LLM or framework	GPT-4o via Azure OpenAI
Version / Build	Current version or build ref	v2.1.3
Business Owner	Named individual, business accountability	Jane Smith, HR Ops
Technical Owner	Named individual, technical accountability	Dev lead, Platform Eng
Executive Sponsor	Named sponsor for risk acceptance	CISO or VP Engineering
Incident Contact	Who to call when something goes wrong	ops-agents@company.com
Stated Purpose	What this agent does	Automate new hire provisioning
Allowed Use Cases	Approved scope	HR onboarding, domestic employees only
Prohibited Use Cases	Explicitly out of scope	No payroll access, no external data sharing
Data Classification	The highest classification of data touched	Confidential / PII
Auth Method	How the agent authenticates	Managed identity, Entra ID
Scopes / Entitlements	Permissions granted	Read HR system, write to ITSM queue
Tools / APIs	What the agent can call	Workday API, ServiceNow API
Downstream Systems	Systems the agent can reach or modify	ITSM, Active Directory, email
Provisioning Date	When first deployed	2025-01-15
Last Reviewed	Most recent access review	2025-09-30
Next Review	Scheduled next review	2026-03-31
Expiration Date	Scheduled decommission date	2026-12-31 or on project close
Retirement Criteria	What triggers decommission	Project ends, owner leaves, 90 days inactive
Log Location	Where logs are stored	Azure Monitor / Log Analytics
Log Retention	How long logs are kept	365 days
Last Audit Date	Most recent formal audit	2025-10-01
Known Exceptions	Policy deviations with approval reference	Exception #2025-047, approved by CISO

Visibility before control

Before you can talk about least privilege, runtime guardrails, or meaningful access reviews with a straight face, you need the boring but critical truths in one place: what exists, who owns it, what it can touch, how it authenticates, where it logs, and when it should stop existing.

That is what the Agent Register gives you. Not the whole program. The control surface that keeps the rest of the program honest.

Without it, you do not have agent governance. You have good intentions, a few diagrams, and an identity problem that will only become visible when something breaks.

Bureaucracy is not the point. Receipts are.