The Agent Inventory: The First Control Every Board Will Ask For

Every serious conversation about AI governance I have had this year has ended at the same question, usually asked by the most senior person in the room: can we produce, today, a list of every AI system acting on our behalf — and the authority each one runs on? The honest answer, almost everywhere, is no. Not because the systems are hidden, but because nobody owns the list, the list has no standard shape, and the things on it change faster than any quarterly review.

The six essays in this series argued the why: authority is the constraint, outcomes need proof, verification is the bottleneck, debt compounds under automation, money moves at machine speed, and trust is becoming infrastructure. This is the first of the operator pieces — the how. And the how starts here, because every other control depends on it.

What counts as an agent

Cast the net wider than “the chatbot.” An inventory that only lists the AI products you bought misses most of the exposure. Four classes belong on it: models your teams call directly, including the ones inside other vendors’ products; agents that take actions across systems — sending, filing, approving, paying, provisioning; applications with AI features enabled, especially the ones switched on by default; and integrations, the connectors, plug-ins, and automations that give any of the above reach into your data and your systems of record. The last class is where shadow authority lives. A harmless assistant with a connector into the ERP is a different object than the assistant alone.

The eleven fields

Resist the urge to build a platform before you have a spreadsheet. The inventory is a table, and it earns its keep with eleven fields per row:

1. 01IdentityWhat it is, which vendor or team built it, and which credential it runs under — a named service identity, never a shared human login.
2. 02OwnerThe named human accountable for its continued use. Not a team, not a vendor — a person, because accountability that cannot be assigned to a person cannot be reviewed.
3. 03Purpose and outcomeWhat it is for and how you would know it worked, in the terms the business uses, so the inventory ties to the value conversation rather than floating beside it.
4. 04AuthorityWhat it may do, on whose behalf, on which data, within which limits — the four questions from the first essay, written down. Where the answer is “whatever the account it runs under can do,” write that down too; it is the finding.
5. 05Data reachWhich systems and which classes of data it can read and change. Reach is where a modest assistant becomes a material risk.
6. 06Autonomy levelSuggests, drafts, acts with approval, acts alone. One word that determines how much verification the row needs.
7. 07SpendHow it is metered and what it cost last month. Token invoices are the fastest discovery tool you own; anything with a bill has a row.
8. 08Approval and expiryWho approved it, on what date, against what system state — and when that approval lapses. Approval attaches to a defined, time-bound state, not to the idea in general.
9. 09Reassessment triggersThe material changes that force a review before expiry: a model change, a new data source, wider scope, more autonomy, a vendor incident.
10. 10EvidenceWhere the record of what it actually did lives — the logs, the decision records, the verification results — and how long they are kept. A row with no evidence location is a row you cannot defend.
11. 11StatusProposed, approved, active, restricted, suspended, retired. The lifecycle is the point; an inventory that only knows “active” is a list of things you have stopped looking at.

Thirty days to a first complete list

Keeping it alive

Inventories die of two causes: nobody owns the list itself, and nothing feeds it. Give the list an owner with a service level, and wire three feeds into it so it updates without heroics — procurement, so no AI contract closes without a row; identity, so no service credential is issued without a row; and finance, so any new AI line item without a row is a question by the end of the month. Then review by trigger, not by calendar: the quarterly attestation catches what the triggers missed, but the triggers do the work.

Treat the evidence field as the seed of everything downstream. When each row points at a real record — what was authorized, what was done, what was checked — the inventory becomes the index to your audit trail rather than a separate artifact. That is the half of this I’ve been working on in the open, in a proposed OCSF extension for recording authorization decisions at the data element, so the record is in a standard any counterparty can read.

What to do now

Name the list’s owner this week. Everything else follows from one person being accountable for the inventory itself.

Start from invoices and credentials, not surveys. Surveys find what people remember; bills and keys find what is running.

Write authority per row, however ugly. “Inherits the admin account” is a finding worth more than a blank cell.

Put an expiry on every approval. Standing authority with no end date is the default condition of every unmanaged estate.

Wire the three feeds. Procurement, identity, and finance keep the list true after the thirty days are over.

Why the board asks for this first

The inventory is the one document from which every other control can be derived and toward which every failure can be traced. Boards ask for it first because it is the only honest answer to “how exposed are we?” — and because a company that can produce it on demand is, almost by definition, a company that can be trusted to delegate more. That is the whole argument of this series in a single table.

This is the first piece in the Operator Edition of Field Notes on the Agentic Enterprise, the practical layer under the six essays. It builds directly on The Agentic Economy Runs on Authority. Next in the Operator Edition: “Write the Mandate: A One-Page Template for Delegating Authority to an Agent.”