Free template and practical guide
AI agent inventory: guide, template and worked example
An AI agent inventory is the record of every autonomous or semi-autonomous AI system operating in your organisation, what each one is permitted to do, and who is accountable for it. Download the free Excel template, then follow the guide to decide what counts as an agent, choose the right fields and keep the inventory accurate.
The scoping problem: what counts as an agent
Every agent inventory project stalls in the same place. Someone asks whether a scheduled script that calls a model API counts, and the conversation consumes a fortnight. The definition that survives contact with a real estate is not about autonomy or architecture:
If it can take an action with a consequence outside its own process, and a model output influences whether or how it takes that action, it is an agent.
That is deliberately broad, and broad is correct at the inventory stage. The inventory's job is to be complete; the risk register's job is to be selective. Applying the test:
| System | In scope? | Why |
|---|---|---|
| Chat assistant that drafts text for a human to send | Yes, low autonomy | Consequence outside the process, mediated by a human. Record it; score it low |
| Nightly script that classifies tickets and sets priority | Yes | Writes to a system of record with no human in the loop |
| Model call that returns a sentiment score to a dashboard | No | No action; it produces a reading |
| Coding assistant that opens pull requests | Yes | Creates artefacts in a system others act on |
| Vendor product with an embedded AI feature | Yes | You are the deployer. The obligations attach to you |
| Recommendation ranking inside a product you own | Yes, if it changes what a user is offered | Consequence outside the process, at scale |
The vendor row is the one most inventories get wrong. Teams inventory what they built and omit what they bought, which is usually the larger population. Under EU AI Act Article 26, deployer obligations for high-risk systems — human oversight, use in line with instructions, log retention — land on the organisation using the system, not only on the provider who built it.
The field specification
Twenty-one fields in five groups. The first group alone is a usable inventory; add the rest in order as the population grows past what a person can hold in their head, which is about fifteen agents.
Identity (5) — the minimum viable inventory
| Field | Notes |
|---|---|
agent_id | Stable, never reused. Referenced by logs, incidents and the risk register |
name | What people actually call it, not the repository name |
purpose | One sentence, business-readable. If it takes a paragraph, it is probably several agents |
owner | A named person accountable for its behaviour. Not a team |
status | Proposed / in development / monitored / live / retired. Drives which review applies |
Technical (5)
| Field | Notes |
|---|---|
model | Provider and model identifier, with version where pinned. Unpinned is itself a finding |
hosting | Provider API, self-hosted, or embedded in a vendor product |
framework | Agent framework or SDK, or none. Determines what telemetry is available to you |
tools | Every tool, function or MCP server it can invoke. The most operationally important field on this list |
triggers | What starts it: user request, schedule, webhook, another agent |
Access and data (5)
| Field | Notes |
|---|---|
identity_used | Service account, delegated user identity, or shared credential. A shared credential is a finding on its own |
systems_accessed | Systems it can reach, each marked read or write |
data_classes | Classifications it can encounter: public, internal, confidential, personal, special-category |
egress | Where data goes — which provider, which region, and whether the provider's terms permit training on it |
human_in_loop | None / approval before action / review after action. The single strongest control on this list |
Risk posture (3)
| Field | Notes |
|---|---|
autonomy_level | 1–4: suggests, proposes for approval, acts within bounds, acts unbounded |
blast_radius | Worst credible consequence of it acting wrongly at full rate until noticed |
reversibility | Can its actions be undone, and by whom, and how quickly |
Governance (3)
| Field | Notes |
|---|---|
approved_by / approved_on | Who let it go live. The agent equivalent of a decision log entry |
last_reviewed | Drives the staleness report |
evidence_location | Where the logs are and how long they are kept. Asked for during every incident, and by Article 26 |
tools is the field that pays for the whole exercise.
During an incident, the question is never "which model was it" — it is
"what could this thing reach". An inventory that records the model but not the
tool surface answers the wrong question at the worst moment.
What the template records, and a worked example
Twenty-one fields is the full specification. The free template is a short form of it, a spreadsheet one person can fill in for a first pass. Each column below is tied to the specification fields it summarises, so a row in the spreadsheet can grow into the full record later without being rewritten.
| Column | What to record | 21-field specification |
|---|---|---|
| Agent name | What people actually call it, not the repository name. | name |
| Purpose | One business-readable sentence. If it takes a paragraph it is probably several agents. | purpose |
| Owner | A named person accountable for its behaviour, not a team. | owner |
| Model and provider | Provider and model identifier, with the version where it is pinned. A vendor product with an AI feature goes here too. | model, hosting |
| Tools and permissions | Every tool, function or MCP server it can invoke, and each system it can reach marked read or write. | tools, systems_accessed |
| Data accessed | The classes of data it can encounter: public, internal, confidential, personal, special-category. | data_classes |
| Environment | Where it runs. Pick from the list. | Not in the 21 fields; added for this template |
| Risk tier | One tier, chosen from the list. The tiers are the ones in the free AI governance framework template. | autonomy_level, blast_radius |
| Review date | The date a person last checked that this row is still true. Enter a date. | last_reviewed |
The worked example shows the level of detail to aim for. The three agents are fictional. Notice what the tier follows: what the agent can reach and what it touches, not how clever the model is. The invoice matcher is High because it can write to a payment queue and holds supplier bank details; the pull request reviewer is Low because it can only comment on internal code.
| Agent name | Purpose | Owner | Model and provider | Tools and permissions | Data accessed | Environment | Risk tier | Review date |
|---|---|---|---|---|---|---|---|---|
| Support reply drafter | Drafts replies to customer tickets for a support agent to review and send. | Priya Nair, Support | Hosted model API, version pinned | Reads tickets (read). Writes draft replies (write). Cannot send. | Customer names and ticket text (personal data) | Production | Medium | 2026-09-15 |
| Invoice matcher | Matches supplier invoices to purchase orders and flags mismatches. | Tomas Weber, Finance | Hosted model API, version not pinned | Reads purchase orders and invoices (read). Writes to the payment approval queue (write). Cannot release payments. | Supplier bank details (confidential) | Production | High | 2026-09-22 |
| Pull request reviewer | Comments on pull requests in two internal repositories. | Dana Okafor, Engineering | Self-hosted open-weights model | Reads repositories (read). Writes pull request comments (write). | Source code (internal) | Development | Low | 2026-08-30 |
Our opinion, not a standard. A one-sentence purpose, a named person as owner, and the tools and permissions marked read or write are the three columns we would not let a row go without. They are the answers an incident, an access review or an auditor asks for first. The tiers are the same four as the free AI governance framework template, so the two documents use one vocabulary.
Where the data comes from
An inventory maintained by asking people is stale on arrival. Each field has a source that can be automated to some degree, and the ones that cannot be should be few enough to keep current by hand.
| Source | Populates | Automatable |
|---|---|---|
| Repository and config scanning | model, framework, tools, triggers | Fully — MCP configs and SDK imports are machine-readable |
| Identity provider | identity_used, systems_accessed | Fully, via service principals and OAuth grants |
| API gateway / egress logs | egress, actual tool usage vs declared | Fully, and it is the only check on drift |
| Procurement and vendor records | Vendor-embedded agents | Partly — needs an AI question in the questionnaire |
| The owner | purpose, blast_radius, reversibility, human_in_loop | No. These are judgements |
The pattern that works: discover technically, attribute manually, verify continuously. Machines find the agents and record what they can reach; humans supply purpose and consequence; egress telemetry checks whether the declared tool surface matches the observed one. That third step is what distinguishes an inventory from a spreadsheet of good intentions.
Why inventories drift, and the two fields that catch it
An agent inventory decays faster than a software asset inventory, because an agent can change materially without any code changing. Four mechanisms:
- Tool surface expands. Someone adds an MCP server to a configuration. The agent's name, owner and purpose are unchanged; what it can reach has doubled.
- The model moves under it. An unpinned model identifier gets a new version with different behaviour, and no change was made on your side.
- Prompt and instruction changes. Frequently held outside version control, frequently edited by people who do not consider it a code change.
- The vendor ships a feature. An approved product becomes an AI deployment on a release note you did not read.
Mechanisms 1 and 2 are detectable and should be alarmed rather than reviewed.
A declared-versus-observed comparison on tools, and a version check
on model, catch the majority of real drift — and both are
cheap if you have the egress logs already.
The staleness metric worth reporting: proportion of live
agents whose last_reviewed predates their most recent configuration
change. Not "how many have we reviewed this quarter", which measures activity,
but "how many are described by a record that was true before the thing
changed", which measures whether the inventory is load-bearing.
Inventory, registry, catalogue
Three words used interchangeably for three different artefacts, which causes real confusion when a vendor sells you one and you needed another.
| Answers | Audience | Completeness bar | |
|---|---|---|---|
| Inventory | What exists, including what we wish did not | Risk, security, audit | Must include unapproved and vendor-embedded agents, or it is not one |
| Registry | What is approved and how to invoke it | Engineering | Only approved agents, by definition |
| Catalogue | What is available to use | The business | A curated subset, presented for discovery |
The failure is using a registry as an inventory. A registry contains what teams chose to register — which by construction excludes everything the governance exercise exists to find. If a record is populated by voluntary submission, it is a registry, whatever it is called, and it cannot answer a risk question.
Which fields a tool can keep true, and which stay yours
The specification above is twenty-one fields. Roughly two thirds can be populated and kept current automatically; the rest are judgements and no product supplies them. Being clear about the split is the difference between an inventory that stays true and one that is accurate on the day it is compiled.
| Fields | Kept true by |
|---|---|
model, framework, tools, triggers, hosting |
Discover reads them from configuration, so they update when the configuration does — this is what catches silent scope expansion |
identity_used, systems_accessed |
Agent identity and non-human identity management, from service principals and grants rather than from declarations |
egress, observed vs declared tool use |
Runtime gateway — the only source that can contradict the record, which is the point |
evidence_location |
Audit ledger, with retention set once rather than per agent |
agent_id, name, status, approved_by, last_reviewed |
The registry holds them; you supply the approval |
purpose, owner, blast_radius, reversibility, human_in_loop, data_classes |
You. These are judgements about consequence and accountability, and anything that claims to infer them is guessing |
For reference, the fields Agent Trust Cloud states it holds per
agent are owner, purpose, model, framework, tools, MCP servers, data
sources, permissions and secrets, plus ten lifecycle statuses from Discovered
through Quarantined to Retired. Against the twenty-one above, that leaves
blast_radius, reversibility, human_in_loop
and autonomy_level for you to add — which is the right
division, because all four are judgements about consequence rather than facts
about configuration.
One row does the work that justifies tooling at all: observed versus declared. Every other field can be maintained by a diligent person with a spreadsheet. Only runtime telemetry can tell you that an agent's real tool surface stopped matching its record three weeks ago, and that is the failure mode this artefact exists to catch.
The one field this page has called the most operationally important —
tools — is also the one that drifts fastest. The
free Discover plan is enough to populate it from configuration and see
whether your existing record survives contact with the estate.
What the inventory is evidence for
Three separate demands land on this artefact, and knowing which one you are serving decides which fields you cannot skip.
Incident response
At 02:00, the question is which agents could reach the compromised system and
what they were permitted to do with it. That is systems_accessed,
tools, identity_used and
evidence_location. This is the use that justifies the inventory on
its own, regardless of regulation.
EU AI Act deployer obligations
Article 26 requires deployers of high-risk AI systems to use them in
accordance with instructions, assign human oversight to competent persons, and
keep logs under their control for a defined period. You cannot demonstrate any
of that for a system you have not recorded — and human_in_loop,
owner and evidence_location are the fields that speak
to it directly.
Access review
Agents hold credentials and are systematically missed by joiner-mover-leaver
processes, because they never leave. identity_used and
owner are what lets an access review include them — and an
agent whose owner has left the organisation is one of the most common and least
detected findings in the whole category.
Common questions about AI agent inventory
What is an AI agent inventory?
An AI agent inventory is a record of every autonomous or semi-autonomous AI system operating in an organisation, capturing what each one does, which systems and tools it can reach, which identity it acts under, who is accountable for it and what evidence of its behaviour is retained.
What counts as an AI agent for inventory purposes?
A practical test: if it can take an action with a consequence outside its own process, and a model output influences whether or how it takes that action, it is in scope. That includes scheduled scripts calling model APIs and AI features embedded in vendor products; it excludes systems that only produce a reading with no action attached.
What fields should an AI agent inventory contain?
At minimum: identifier, name, purpose, named owner and status. A full specification adds model and version, hosting, framework, callable tools, triggers, identity used, systems accessed, data classes, egress destination, human-in-the-loop mode, autonomy level, blast radius, reversibility, approver and date, last reviewed, and evidence location.
What is the difference between an agent inventory and an agent registry?
An inventory records what exists, including unapproved and vendor-embedded agents, and serves risk and audit. A registry records what has been approved and how to invoke it, and serves engineering. A registry populated by voluntary submission cannot answer a risk question, because it excludes exactly what the exercise is looking for.
Why do AI agent inventories go out of date so quickly?
Because an agent can change materially with no code change: its tool surface expands when a configuration gains a new server, an unpinned model identifier moves to a new version, prompts are edited outside version control, and vendors ship AI features into approved products. Declared versus observed comparison on tools and models catches most of it.
Do we need an agent inventory for the EU AI Act?
Article 26 places obligations on deployers of high-risk AI systems — using them per instructions, assigning competent human oversight, and retaining logs. Those duties cannot be demonstrated for systems that have not been recorded, so an inventory is a practical prerequisite even though the Act does not name the artefact.
Is there a free AI agent inventory template?
Yes. Agent Trust Cloud publishes a free Excel template with an inventory sheet, drop-down lists for environment and risk tier, a date check on the review date, an instructions sheet and a fictional example. It downloads without an email address.
What columns should an AI agent inventory spreadsheet have?
The free template has 9: agent name, purpose, owner, model and provider, tools and permissions, data accessed, environment, risk tier, review date. They are a short form of the 21-field specification on this page, and the risk tier is a judgement a person makes.
Start your inventory
There are two free ways to start. Neither needs a card.
1. The spreadsheet
Download the free template (.xlsx). You fill it in by hand, so it is as accurate as the person filling it in and as current as the last review date in each row.
2. A free workspace
Build your inventory in a free workspace creates a Discover workspace. What it does today: you register an agent by hand (name, department, business owner and environment), and the setup wizard walks you through discovery. You can connect a Microsoft Entra ID directory so machine identities are read from it, once an administrator in your tenant grants read-only consent, and you can sync a Slack workspace or import an MCP configuration from Agent safety. What it does not do: there is no cloud-account connector yet, so a cloud account ID you enter is recorded and nothing is read from the account.