AI Agent Inventory Template

An AI agent inventory template gives a company one working list of the agents and agent workflows it knows about, who owns them, what they may do, where they run, and which controls and evidence apply.

The useful unit is usually an agent-workflow-environment combination. One agent may draft support replies, update account records, and run a nightly reconciliation under different owners, tools, data, and approval rules. Putting all three uses in one broad row hides the differences that reviewers need to see.

Download the AI agent inventory template (CSV)

The CSV contains 70 fields for identity, ownership, purpose, lifecycle, authority, reconciliation, control verification, systems, data, context, risk, review, monitoring, shutdown, and retirement. It starts with a header only so your team can define approved values before adding real records. The field dictionary defines each field, required status, value type, and multi-value format.

Download the AI agent inventory data dictionary (Markdown)

Treat imported and self-reported CSV values as untrusted text. Spreadsheet software may interpret cells that begin with =, +, -, @, a tab, or a carriage return as formulas. Import fields as text or neutralize formula-leading values according to your approved spreadsheet procedure before anyone opens the file. Preserve the original value in a protected evidence system when an investigation requires it.

TL;DR

Use the template to:

1. Give every agent workflow a stable inventory ID and named owners.
2. Record purpose, users, environment, lifecycle state, and operating trigger.
3. Map allowed and prohibited actions, approvals, systems, tools, data, and context.
4. Connect risk, impact decisions, policy reviews, tests, monitoring, incidents, and evidence.
5. Reconcile declared rows against systems that reveal what actually exists.
6. Review material changes and retire access, routes, schedules, and state when work ends.

The inventory records declared and approved state. It does not prove that an agent was deployed, that a control operated, that context entered a model session, or that a run produced the claimed outcome.

Use an AI agent charter template when an inventory row needs a detailed, approved operating contract for purpose, authority, controls, evidence, and stop conditions.

What Is an AI Agent Inventory Template?

An AI agent inventory is a maintained list of agent identities and the governed workflows they perform.

NIST’s AI RMF Core includes an outcome for mechanisms that inventory AI systems according to organizational risk priorities. The accompanying Govern Playbook describes an AI system inventory as an organized database of artifacts that may include system documents, incident plans, data dictionaries, implementation references, and contact information for relevant people.

Agents need fields beyond a basic model or application catalog because they can receive delegated work, call tools, keep state, act on schedules, hand work to other agents, and change external systems. The inventory should make those operating boundaries visible.

An inventory is still a record, not an enforcement system. A row that says an agent cannot send payments does not block a payment API. A row that names a stop method does not prove the stop path works. Connect the inventory to access, deployment, monitoring, and audit systems, then test the controls it references.

1. Define the Inventory Scope and Row Unit

Start by writing the inclusion rule. Include a system when it can perform or materially influence company work through one or more of these capabilities:

• It pursues a goal or completes a multi-step task.
• It calls tools, APIs, browsers, code runners, or other agents.
• It reads or writes company, customer, workforce, or production data.
• It runs on a schedule or event without a person starting each step.
• It creates external output or changes a system of record.
• It keeps working state or receives maintained context across sessions.

Do not limit discovery to centrally built production services. Include pilots, scheduled jobs, agents embedded in purchased software, coding agents, browser agents, team automations, and local workflows when their access or output creates company responsibility.

Use one row per agent-workflow-environment combination when purpose, authority, data, tools, owners, or controls differ. A single agent can therefore have several rows. Keep agent_id and workflow_id stable across related rows so discovery and reconciliation can group them before you move the data into a registry.

Record excluded classes and the reason for exclusion. A scope rule that changes informally will create false coverage metrics.

2. Discover Agents From More Than One Source

Owner surveys are useful, but they find only what people remember and choose to report. Reconcile them with technical and commercial sources such as:

• Identity providers, service accounts, OAuth grants, and credential brokers
• Cloud projects, deployment platforms, containers, functions, and job runners
• Tool gateways, API logs, browser automation, MCP configuration, and integrations
• Source repositories, package manifests, CI workflows, and infrastructure code
• Schedules, queues, event rules, callbacks, and webhook registrations
• Procurement, expense, contract, and approved-software records
• Monitoring, audit, incident, help desk, and data-access records

Discovery output is a candidate list. Add every found agent to the inventory so it remains inside the coverage and reconciliation denominator, but set approved_lifecycle_state to an explicit unreviewed or not-approved value until an authorized decision occurs. Record the observed state, assign an investigation owner, and narrow or stop access when policy requires it. Inventory entry does not grant approval.

Record the discovery sources in each row so another reviewer can repeat the search and assess coverage.

The inventory should also accept reports from employees and agents, but a self-report is a lead until another source confirms the identity and scope.

3. Assign Stable Identity and Human Ownership

Every row needs a stable inventory_id. It also needs a stable agent_id and workflow_id, which let several rows refer to one agent or workflow across environments without relying on names. Do not reuse any of these IDs after retirement because old logs, reviews, incidents, and evidence may still refer to them.

Name at least three responsibilities where the workflow warrants them:

Owner	Accountable for
Business owner	Purpose, outcome, users, operating decision, and continued need
Technical owner	Build or configuration, integrations, deployment, reliability, and technical change
Risk owner	Risk decision, required controls, exceptions, review, and escalation

Use roles or groups for continuity, but retain the named person who approved a decision at the time. An inbox or team name alone does not establish individual accountability.

The agent’s technical identity is separate from the human owner and the person, service, or schedule that starts a run. Preserve those distinctions because they answer different questions during authorization and audit.

4. Record Purpose, Status, and Operating Context

The purpose field should describe one bounded business workflow and outcome. “Help the finance team” is too broad. “Draft invoice-exception summaries for an accounts-payable reviewer” states the work, user, and decision boundary.

Record:

• Business unit and workflow name
• Approved lifecycle state, observed lifecycle state, and environment
• Agent type and user population
• People affected by the output or action
• Invocation sources, schedules, and event triggers
• Model, runtime, configuration version, and deployment location
• Parent agents and downstream agents

Define allowed lifecycle values before teams fill the file. A practical set may include proposed, discovery, testing, approved for limited use, active, restricted, suspended, deprecated, and retired. Each state should have an owner, entry criteria, exit criteria, and an effect on access or operation.

Keep approved and observed lifecycle state in separate fields. If those differ, set the reconciliation status, record the mismatch, and open corrective work instead of silently choosing one.

5. Map Authority, Approval, and Stop Paths

An agent inventory should show what the workflow may do, not only what software it uses.

For each row, record:

• Autonomy level
• Allowed actions and prohibited actions
• Human approval rules and thresholds
• Control IDs, enforcement points, and control owner
• Evidence source, trust level, verification result, and verification date
• Systems the workflow may read and write
• Tools and APIs it may call
• The tested method to pause or stop it, with test evidence and date
• Credential-management approach, without credential values

Use action verbs and object scope. “CRM access” does not say whether an agent can search contacts, export a segment, change an account owner, or delete records. Record the action, object, environment, limit, and approval condition.

Treat the inventory as a map to enforcement. The actual control may live in identity policy, an API gateway, application permissions, a queue, a deployment platform, or a human approval service. Link to that control and retain representative test evidence.

When one row references several controls, keep enforcement points, owners, evidence sources, trust levels, verification results, and verification dates in the same order as control_ids. Use a protected structured control-evidence record keyed by inventory_id and control_id instead when parallel CSV values would be hard to maintain.

Never store passwords, tokens, private keys, recovery codes, or secret values in the inventory. Record the approved credential mechanism or a protected management reference. Keep access to the inventory itself narrow because its metadata can expose system relationships, authority, and control locations.

6. Map Data, Context, Tools, and Dependencies

List the highest data classes the workflow may receive, create, infer, or send. Link to the governing data record instead of copying personal data, customer records, confidential prompts, unrestricted traces, or sensitive evidence into the CSV.

Context deserves separate fields because an agent’s behavior depends on more than the model. Record the approved Knowledge, Skill, and Memory routes or stable references that apply to the workflow. Keep runtime inputs and tool results separate from maintained context records.

For Alignbase, permissions govern who may discover, read, or change each Resource, while independent Always routes govern which published Knowledge, published Skills, and current Memory enter an agent’s current-context bundle. Compilation or response issuance records do not prove that content entered a model session or was consumed.

The inventory should point to exact context and configuration versions in release evidence when those versions matter. The live row can show current desired state, while immutable delivery and run records preserve point-in-time state.

List tool and system dependencies separately from context. A tool descriptor says a capability exists. Authorization at the execution boundary decides whether a particular call may proceed. Inventory documentation cannot grant authority to itself.

7. Connect Risk, Reviews, Tests, and Evidence

The inventory is an index into other governance records, not a place to duplicate all of them.

Connect each row to:

• A risk tier and its method
• An impact determination, accountable approver, decision date, and evidence reference
• Applicable policy, legal, privacy, security, workforce, and accessibility reviews
• Test, evaluation, release, rollback, and recovery evidence
• Monitoring and incident owners
• Last and next review dates
• Change, exception, and approval references
• An evidence package or protected evidence index

NIST’s inventory outcome is risk-prioritized, which means every row does not need the same review depth. Higher authority, sensitive data, external effects, scale, affected people, weak reversibility, or high-impact decisions should drive stronger controls and more frequent review.

The U.S. federal requirements in OMB Memorandum M-25-21 apply to federal agencies, not every company. They still offer a useful example of connecting an AI use case inventory to high-impact determinations, central tracking, ongoing performance review, independent review, and risk acceptance.

Inventory presence is not evidence that those activities happened. Link to signed decisions, immutable test results, deployed configuration, monitoring records, or other evidence appropriate to the claim.

8. Reconcile Declared State With Observed State

Set a reconciliation cadence and define the systems used for comparison. The process should detect:

• Deployed agents with no inventory row
• Inventory rows with no owner or inactive owners
• Active credentials, schedules, routes, or integrations for suspended or retired rows
• Tools, systems, data, users, or downstream agents missing from the approved scope
• Configuration or model versions that differ from the reviewed release
• Review dates that passed without a decision
• Duplicate records and reused IDs
• Records that claim a control but have no current evidence

Describe each mismatch, link its supporting evidence, and assign it an owner, severity, due date, and interim action. A reconciliation dashboard that only counts stale rows does not reduce the exposure.

Record the discovery sources, last reconciliation date, and reconciliation status even when the states match. When the status is mismatch, unknown, or investigating, complete the mismatch description, evidence reference, owner, severity, due date, and interim action fields. Use those fields to resolve controlled UNKNOWN, UNASSIGNED, or UNCONFIRMED values as well as confirmed differences.

The official 2025 Federal Agency AI Use Case Inventory repository provides a current public example of machine-readable inventories, a data dictionary, validation work, stable identifiers, lifecycle reporting, and explicit handling for details that cannot be publicly released. Your internal inventory will need different fields and tighter access, but the format discipline is useful.

9. Review Changes and Retire Completely

Review every row on its scheduled date and after a material change, including:

• New purpose, users, affected people, or business owner
• New tools, systems, data classes, context, or downstream agents
• Expanded write, send, execute, approve, delegate, or spending authority
• New model, runtime, integration, deployment location, or configuration
• Incident, control failure, unexpected outcome, or material evaluation change
• Changed law, contract, policy, risk tier, or impact determination

A change to one field may require changes elsewhere. A new write tool can change risk, approvals, tests, monitoring, rollback, and incident response.

Retirement requires more than setting approved_lifecycle_state to retired. Revoke or rotate credentials, stop schedules and queues, remove routes and integrations, close delegated grants and pending approvals, handle Memory and records under policy, preserve required evidence, reconcile downstream work, and verify that no active path can restart the workflow. Record completion status, the verifier, and revocation evidence separately from the retirement plan.

Keep the retired record and stable ID for the required retention period. Record the replacement or exit plan so reviewers can trace where the work, data, context, and responsibility moved.

10. Move From an Inventory Template to a Governed Registry

A CSV is useful for discovery because nearly every team can open it, filter it, and fill missing fields. It becomes fragile when several teams edit it, fields drive access decisions, agents change often, or reviewers need exact history.

Move to an AI agent registry when you need:

• Controlled creation and changes
• Required fields and approved values
• Direct human ownership checks
• Version history and point-in-time state
• Links to identity, access, context, deployment, monitoring, and incidents
• Automated discovery and reconciliation
• Lifecycle transitions that affect operation
• Access controls for sensitive inventory details
• APIs, exports, and audit records

An AI agent management platform goes further by connecting the registry to governance, monitoring, change, suspension, retirement, and evidence workflows. The inventory remains the starting question: which agents and agent workflows exist, who owns them, and what is each one allowed to do?

Use the AI agent governance checklist to test each governed workflow, the AI agent risk register template to track risks and controls, and the AI agent lifecycle management guide to carry the record through operation and retirement. The Alignbase blog covers each control area in more detail.

The inventory is useful when it changes decisions. Unknown agents should enter review. Missing owners should block approval. Expired evidence should trigger reassessment. Retired workflows should lose every operating path. That is how a list becomes an operational control rather than a quarterly reporting exercise.