Agent Inventory & Registry

The self-declared inventory fails for three structural reasons, not one cultural one.

The usual diagnosis is that engineers do not fill in the form. That is true and it is the least interesting of the three failures, because the other two persist even with perfect compliance.

• Registration happens once and the system changes weekly. An agent registered in March with two tools and a retrieval index over the help centre is, by July, an agent with nine tools, a database write and a different model. The row in the spreadsheet is accurate about a system that no longer exists, and nothing in the process notices.
• The interesting agents were never projects. The ones that carry real risk are frequently the ones nobody scoped as an AI initiative: a script somebody wired to a provider API, an automation inside a SaaS tool that a business team enabled, an internal assistant that grew tools one pull request at a time. None of them ever crossed the desk that owns the register.
• "Agent" has no agreed boundary, so the count is a definition argument. Is a prompt template an agent? A workflow with one model call? A sub-agent spawned at runtime? Teams answer differently, and an inventory whose unit of record is contested cannot be reconciled against anything. Step 3 fixes this, and it is the fix that makes the rest work.

Derive it from the three things an agent cannot do without.

An agent that runs in production needs credentials, needs a network path to a model, and costs money. Each is a chokepoint you already operate, each produces a record without anyone volunteering it, and together they are far more complete than any survey.

• Credential issuance. Every agent holds a token for something — the model provider, a database, an internal API. If credentials are issued centrally and short-lived, the issuance log is the population, and the identity it issues to is the natural primary key. This is the governance payoff of scoped credentials and agent identity, and it is the reason those are worth building first.
• The gateway. If model calls route through a proxy, every caller appears in its logs with a model, a volume and a time range, whether or not anyone registered it. A gateway deployed for cost control turns out to be the highest-coverage discovery tool in the organisation.
• The bill. Provider invoices and cloud cost allocation surface workloads that dodged both other controls — a team with its own API key on a corporate card is invisible to your gateway and visible to finance. Unattributed spend is the discovery queue.
• Then reconcile, and treat every mismatch as a finding. An identity in the credential log with no registry entry is a shadow agent. A registry entry with no traffic for ninety days is either decommissioned-but-still-credentialed or, worse, a system nobody remembers that still holds a token. Both are more actionable than anything a survey returns.

The unit of record is not "an agent". It is the grant.

This is the step that decides whether the register is useful or ceremonial. "Customer support agent" is a product name; it is not a thing you can assess, because two deployments under that name may differ on everything a regulator or an incident responder would ask about.

• Record the tuple, not the name: the agent identity, the tool grants it holds, the data scopes those tools reach, the model and version serving it, the autonomy level (proposes, acts-with-approval, acts), and the deployment environment. Those six fields are what change, and they are what every downstream question is actually about.
• Version the tuple, and keep history. The question that arrives during an incident or an audit is never "what does it do?" — it is "what did it do on 14 May?". A register that only holds current state cannot answer it, and reconstructing the answer from deploy logs eight months later is the expensive failure documented in serious-incident reporting.
• Let sub-agents inherit rather than multiply. A supervisor that spawns workers at runtime does not create fifty registry entries; it creates one entry whose grant covers what the workers may hold. Record the topology, and record that the delegation cannot exceed the parent's grant — which is a design requirement as much as a bookkeeping one.
• Name an accountable owner, one human, on every entry. Not a team alias. The obligation to have a specific person answerable is the whole content of accountability and ownership, and an entry with no owner is the entry that will still be running credentials two years after its team reorganised.
• Classify at registration, and re-classify on change. Risk tier, whether personal data is in scope, whether the output reaches a person outside the company. Determined once at the start, these fields rot precisely when the agent gets interesting — so bind re-classification to a change in the tuple rather than to an annual review.

Make the registry load-bearing: no entry, no credential.

A register that only observes will drift, because nothing depends on it being right. A register that sits in the issuance path cannot drift, because an agent that is not in it does not run.

• Registration becomes a deploy-time gate. The credential broker refuses to mint a token for an identity with no registry entry, an unowned entry, or a tuple that does not match the grant being requested. This is one integration and it converts the whole exercise from documentation into a control.
• The registry ID travels in the trace. Every run carries it, so cost, evaluations, incidents and audit records all join on the same key. Without this the register is an island; with it, "show me every run this agent made in May, with outcomes" is a query rather than a project — which is what tracing and observability was building toward.
• Changing the tuple is a change request, not an edit. Adding a tool or widening a data scope goes through the same review as the code, on the machinery in rollout and versioning. The failure mode this prevents is the agent that acquired database write access in a Friday deploy and was assessed as read-only.
• Generate the compliance artifact from the register; do not maintain it separately. The evidence pack, the risk classification list, the record of processing — each should be a rendering of the same data. Two hand-maintained lists always disagree, and the one you show an auditor will be the stale one.
• Beware the registry becoming the bottleneck. If registering takes a week, teams route around it and you are back to shadow agents with extra process. Automatic registration on first credential request, with review afterwards for anything above the lowest risk tier, keeps the friction where the risk is — the balance argued in governance without gridlock.

Third-party agents are in scope, and they are the hard half.

The agents most likely to be missing from your register are the ones you did not build. They arrive through procurement, through a feature toggle in software you already own, and increasingly through a plugin an engineer installed.

• Vendor features become agents without a purchase decision. A SaaS product ships an assistant that reads your data and takes actions in it; nobody bought an AI system, so nobody registered one. Sweep your vendor list for capabilities that were enabled rather than acquired — that sweep reliably finds more agents than the internal survey.
• An installed plugin is a grant. A bundle that carries both instructions and a configured tool server extends what an agent can read and reach, on the credentials of whoever installed it. Register the installation as a change to the tuple, and read agent supply-chain security for what to check before it lands.
• Record what you cannot inspect, and mark it as such. For a third-party agent you will not have the model version or the tool list. Register what you do control — the data it reaches, the actions it can take, the contract and the owner — and flag the unknowns explicitly. An honest gap is governable; a blank row is not. The diligence questions are in third-party model and vendor risk.
• Downstream deployers need the same facts from you. If you ship an agent that others operate, the register is where the disclosure obligations and the instructions-for-use are sourced from, and it is the reason those fields must be structured rather than prose.

Operate it: reconcile on a schedule, and make decommissioning someone's job.

Inventories decay in a specific direction — they grow. Entries are added at launch and almost never removed, so within two years the register describes a fleet substantially larger than the one running, and its credibility goes with it.

• Reconcile weekly, automatically, and report the diff. Credential identities minus registry entries, registry entries minus observed traffic, spend minus attributed agents. Three numbers, trending. A rising first number is shadow deployment; a rising second is dead entries holding live credentials.
• Decommissioning is the step everyone skips. Retiring an agent means revoking its credentials, closing its egress allowances, resolving the retention obligation on its traces per retention and legal hold, and marking the entry closed with a date. An agent that was "turned off" by removing a UI entry point and still holds a valid token is not decommissioned.
• Alert on grant expansion, not on registration. New agents get attention naturally. The dangerous event is an existing, already-approved agent acquiring a new tool or a wider data scope — that is where risk classification silently becomes wrong, and it is a cheap alert once the tuple is the unit of record.
• Drill the lookup. Once a quarter, pick an agent and a date and time how long it takes to produce its exact configuration on that date, its owner, and its runs. The exercise is the same one an incident or a regulator will impose, and the first attempt is always slower than anyone expects.
• Publish the count. A number that leadership sees monthly — agents in production, by risk tier, with owners — does more for accuracy than any policy, because it makes the register something people are asked about rather than something they fill in.

Related: agent identity for the primary key this rests on, audit trails and provenance for what the registry ID joins to, the EU AI Act for agents and NIST AI RMF for agents for the obligations this feeds, and policy enforcement for turning register entries into runtime controls.