Agent Inventory
Which agents exist, and who owns them?
Reference notes by Min · Reviewed October 11, 2026
Definition
An agent inventory is a maintained record of deployed or proposed agents, their owners, purposes, dependencies, permissions and review status.
An inventory is useful when a reviewer can move from a named agent to its current owner, permitted work and supporting evidence. A spreadsheet can be sufficient for a small pilot. At larger scale, the same information may be distributed across deployment records, identity services and a review system, joined by a stable agent identifier.
Decide what one record represents. An agent definition describes a reusable configuration; a deployment describes its environment and enabled tools; a run describes one task. Keeping these levels distinct avoids creating thousands of duplicate inventory entries while retaining the detail needed to investigate a specific action.
What it covers
- Ownership
- Who is accountable for the use.
- Capabilities
- Models, tools, memory and access paths.
- Status
- Pilot, production, paused or retired, with review dates.
Record both the approved scope and the observed scope. A tool catalogue shows what could be exposed, while deployment configuration and runtime records show what was actually available. If those disagree, mark the difference as a review item with an owner and resolution date.
Use lifecycle states that correspond to decisions: proposed, piloting, approved, suspended and retired. A state should point to its rationale and effective date. Retirement should connect to credential removal, scheduled-job cancellation and data retention decisions; hiding a row does not complete that work.
In practice
Practical design patterns by Min.
- Link entries to actual deployments and grants.
- Update the record when tools or purposes change.
- Track review ownership rather than only counting agents.
Start discovery from several places: code repositories, registered workloads, purchasing records, integration configurations and tool-call telemetry. Reconcile them against the inventory. Record unmatched agents as unknown or pending review rather than silently counting them as approved.
Assign responsibility for each field. A platform team may maintain deployment and model versions, the business owner may maintain purpose and benefit, and security may maintain permitted access. Capture who last confirmed the data and which source supports it.
Make change triggers concrete. A new write-capable tool, customer population, model provider, data category or child-agent path may require reassessment. Small cosmetic changes need not receive the same review as an expansion of authority.
Suggested inventory fields
An illustrative schema to adapt to your workflow. These fields are Min’s operational design suggestions; they are not a mandatory NIST template.
| Field | What to capture |
|---|---|
| Agent and deployment IDs | Stable references that distinguish the reusable definition from its environment-specific deployment. |
| Purpose and prohibited uses | The business task, expected benefit and boundaries that reviewers agreed to. |
| Accountable owner and maintainer | A business decision owner and a technical contact, with confirmation dates. |
| Model and dependency versions | Provider, model configuration, retrieval sources and significant service dependencies. |
| Tools and side effects | Enabled operations, read/write/export capabilities and commitment boundaries. |
| Data and affected users | Data categories, audience, customer or tenant scope and relevant sensitivities. |
| Identity and delegated authority | Managed identity reference, grant scope, expiry and child-agent relationships; no secrets. |
| Review state and evidence | Current lifecycle state, rationale, approver, evaluation links and material limitations. |
| Operational record | Monitoring owner, incident route, cancellation mechanism and observed deployment activity. |
| Cost, benefit and next review | Budget owner, measured usefulness, operating cost and change or date-based review triggers. |
Working example
Reviewing a new integration
A team adds a write-capable tool.
- Update the agent’s capability record.
- Reassess permissions and oversight requirements.
- Record the decision and next review date.
Why the controls matter
For a support agent, maintain one deployment record linked to multiple case runs. A case run identifies the requesting employee, customer scope, tools used and any approved refund. The inventory links to those records without copying every conversation into its main table.
If a refund tool is enabled later, compare the new configuration with the approved read-and-draft scope. Mark the deployment pending review, assign the refund decision owner and record the updated limits before allowing the new action.
Common pitfalls
- A registry disconnected from live access.
- An entry with no accountable owner.
An impressive coverage percentage can hide stale records. Report completeness and freshness separately: an owner name is present, an owner has confirmed responsibility, and that owner is still reachable are different conditions.
Do not store access secrets in the registry. Reference a managed credential or identity record. Keep sensitive prompts, customer records and detailed traces in systems with appropriate access controls and retention rules.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Can an operator identify the owner of an unknown tool call?
- Does every active deployment have a current scope and review decision?
- Can suspension stop new work and invalidate its access?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- NIST AI RMF Core ↗Accessed October 11, 2026