Agent inventory
How to Build an Agent Inventory
Create an inventory that separates logical agents, deployments and runtime identities, with discovery, reconciliation and retirement evidence.
An agent inventory should let an organisation answer a practical question: which agent can affect this process, under whose authority, through which deployed system and with what evidence of its current state? A spreadsheet containing names and model providers cannot reliably answer that question.
This guide is for platform owners, risk teams and operations managers who need a maintained register of deployed AI agents. It distinguishes the logical agent from its deployments, identities and individual runs, then provides a reconciliation method. The inventory becomes a reference point for AgentOps, rather than another catalogue that ages independently of production.
Decide what one inventory record means
A logical agent is the operationally meaningful capability with a purpose, owner and permitted scope. A deployment is a running or deployable instance in a defined environment. A runtime identity is the technical principal through which the system obtains access. A run is one execution of a task. These objects are related, but they are not interchangeable.
If every run becomes an inventory record, the register becomes telemetry. If several distinct agents share one generic “AI platform” record, ownership and authority disappear. Create stable identifiers for logical agents and deployments, then link identities, tools and traces without treating them as the same object.
The NIST AI RMF Playbook's GOVERN guidance includes maintaining an AI-system inventory as part of organisational governance. The implementation below is a proposed operational design; it does not turn a completed register into a compliance certificate or establish that every listed system is safe.
Worked portfolio: three agents, seven deployments, four identities
Consider an illustrative organisation with a training-course catalogue assistant, a purchasing-enquiry router and a travel-request drafting assistant. The catalogue assistant has production, test and preview deployments. The other two have production and test deployments. That produces three logical agents and seven deployments.
Each production deployment uses its own runtime identity. The four non-production deployments currently share one test identity, giving four identities in total. This is a discovered arrangement, not a recommendation. The inventory should expose whether that shared identity creates excessive access or makes activity difficult to attribute.
Counting seven agents would overstate the number of logical capabilities. Counting four agents from the identity list would miss the actual deployment structure. Counting only three names without the relationships would hide the shared non-production access. The useful inventory preserves all three views and lets the owner investigate their consequences.
| Logical agent | Deployments | Runtime identities | Question exposed |
|---|---|---|---|
| Course catalogue assistant | Production, test, preview. | Dedicated production identity; shared test identity for the other two. | Can preview activity be distinguished from test activity? |
| Purchasing-enquiry router | Production, test. | Dedicated production identity; shared test identity. | Does test access include anything outside its intended scope? |
| Travel-request drafting assistant | Production, test. | Dedicated production identity; shared test identity. | Does the record clearly state that drafting does not authorise booking? |
A minimum record that supports real decisions
Record purpose and prohibited scope in ordinary language. “Travel agent” is ambiguous; “prepares a travel request for employee review and cannot book or pay” establishes a meaningful boundary. Include the business owner, operational owner and the role authorised to approve changes to that boundary.
- Identity and lifecycle: stable agent identifier, current state, creation record and retirement reference where applicable.
- Deployment relationships: environment, deployment identifier, active version, runtime identities and hosting references.
- Action scope: permitted tools, read and write boundaries, approval requirements and prohibited actions.
- Data relationships: source categories, destination categories, sensitive-data handling and accountable data owners.
- Operating evidence: outcome definition, monitoring location, runbook, response coverage and recent readiness decision.
- Change and review: last verified date, verifier, evidence inspected, open exceptions and next review trigger.
Store references to secrets and access policies, never the secrets themselves. An identity identifier and a link to an approved access-management record are usually more useful than a copied token. Restrict the inventory according to the information it exposes; architecture, privileged paths and data locations can themselves be sensitive.
Discover from more than one source
Start with declared projects and service owners, but reconcile them with deployed workloads, identity records, approved tool integrations, model-provider accounts and operational telemetry. Finance records can reveal an active service that has no corresponding owner record, while deployment records can reveal a dormant system that still holds credentials.
Use the least intrusive evidence needed to establish existence and relationships. Discovery does not require collecting every prompt or customer payload. A deployment reference, service identity, approved integration and trace metadata may be sufficient to identify the service for owner review.
Record provenance for each observation. A billing line suggests spending, not necessarily an autonomous agent. A workflow name suggests intended purpose, not proof of current authority. Ask the responsible team to validate the interpretation before adding unsupported detail to the register.
Reconcile disagreements as work items
Compare the declared inventory with the discovered evidence. Classify differences as an unregistered deployment, an unknown owner, an outdated version, an unexpected identity, a missing dependency or a retired service that still appears active. Assign a resolution owner and due date based on consequence.
For the example, the shared test identity may appear in four deployment records but only one identity-management record. That is not automatically a duplicate. It is a relationship that needs review: what can the identity access, can deployments be distinguished and should the arrangement change?
Do not make reconciliation disappear by deleting inconvenient records. If an owner cannot be found, mark the ownership gap and apply the organisation's approved containment or review process. A register that labels uncertainty honestly is more useful than one with every cell filled by assumption.
Represent tools, sub-agents and shared services carefully
A tool connection is not necessarily a separate agent. A bounded helper that performs a delegated task may share a logical agent's ownership, or it may deserve its own record if it has an independent lifecycle, decision scope or operating team. Write the inclusion rule and apply it consistently.
Link shared retrieval services, model endpoints and orchestration platforms as dependencies. This allows an owner to identify which agents are affected by a change or outage without duplicating the platform record in every row. The AgentOps tooling-stack guide addresses how these operating components fit together.
Maintain both technical and business relationships. A change to the purchasing-enquiry source may affect one agent's evidence, while a change to the shared test identity affects several deployments. The inventory should support those different impact questions, rather than forcing every relationship into a single “vendor” field.
Make inventory updates part of controlled change
Use deployment and approval workflows to propose updates when an agent, tool, identity or permission changes. Automation can populate technical observations, but a responsible person still needs to confirm the meaning of the business purpose and permitted scope. An automatically discovered write permission should not become an approved business authority.
Link the register to agent change control and action authorisation. A release request should identify the agent record it changes, while the inventory should show the currently approved boundary and any temporary exception. Preserve enough history to explain which version and authority applied during an incident.
Set review triggers that match change frequency and consequence. A periodic attestation can catch missed changes, but it should ask the owner to verify specific evidence. “Still owned by this team” is weaker than confirming the active deployments, tool permissions and current operating support.
Retire the service without erasing its history
Retirement should establish that intake has stopped, scheduled jobs are disabled, active tasks have a disposition and runtime access has been removed where no longer needed. Check shared identities carefully so that removing one deployment does not disrupt another without an agreed change.
Keep the retired record and required evidence according to the applicable retention decisions. Mark what was disabled, when, by whom and how it was verified. A retired agent may still be relevant to an unresolved incident, an audit question or a retained record; deletion from the live catalogue does not answer those needs.
Distinguish verification status from lifecycle status. A deployment can be active while its owner attestation is overdue, or retired while evidence of credential revocation is still missing. Use separate fields for these facts rather than forcing them into one green or red label. This lets operations prioritise the actual gap without falsely implying that an unverified record is either safe or already shut down. When evidence is refreshed, retain the reference and reviewer so the next verification can inspect a change rather than repeat discovery from the beginning.
Use the register to ask better operational questions
Useful inventory checks include agents with no operational owner, write-capable deployments without a current approval record, expired exceptions and services whose runbooks no longer match their tools. Report these as specific gaps, not as a single misleading “inventory complete” percentage.
The AgentOps readiness checklist uses these records as evidence, and the assessment guide explains how to test them against observed operation. Discuss an agent inventory and reconciliation review with a masked deployment list, identity relationships and a sample ownership record. The priority is a register that supports decisions when something changes.
FAQ
Your questions, answered.
What counts as one AI agent in an inventory?
Define a logical agent by its operational purpose, owner and permitted scope. Record its deployments, runtime identities and executions as related objects rather than interchangeable counts. A separate helper may deserve its own record if it has an independent lifecycle or authority. Write the inclusion rule so different teams classify the same arrangement consistently.
How do you discover agents that are missing from the official register?
Reconcile declared projects with deployments, identity records, approved integrations, provider accounts and suitable operational metadata. Record the source of each observation and ask owners to validate the interpretation. A charge or workflow name alone does not prove an autonomous agent exists. Discovery should use the minimum information needed, without collecting unnecessary prompts or sensitive payloads.
Should agent inventories contain API keys and secrets?
No. Store identity identifiers and references to approved access-management records rather than the secrets themselves. Restrict access to the inventory because architecture and permission relationships may also be sensitive. The register should explain which principal can do what and where the controlling policy lives, without becoming a repository of credentials.
How often should an agent inventory be reviewed?
Update it through relevant deployment, permission, tool and ownership changes, then use periodic verification to detect omissions. Choose the review cadence from change frequency and consequence. Ask owners to inspect concrete evidence such as active deployments and permissions. A date stamp or ownership acknowledgement alone cannot establish that the technical record remains accurate.
Should retired agents be deleted from the inventory?
Keep a retired record and the evidence required by applicable retention decisions. Establish that intake, scheduled work and unnecessary access have been disabled, and record unresolved tasks or incidents. Retired systems may remain relevant to audit or recovery questions. Removing a name from the live catalogue does not establish that the service has stopped.
Can inventory discovery automatically approve an agent?
Discovery can establish observed components and relationships, but it does not confer business authority or readiness approval. A detected write permission may be an error that needs investigation. Keep observed state, approved scope and unresolved exceptions distinct, with accountable people validating purpose, risk decisions and the operating arrangements before the service is accepted.