Registry specification
AI agent inventory
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. The hard part is not the storage — it is deciding what counts as an agent and keeping the record true a month later. Both are addressed below, with a full field specification.
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.
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.