AI Agent Inventory: The Fields to Record for Every Agent

An AI agent inventory for companies is one register that lists every agent in use, with a named owner, a stated purpose, the accounts and data it can reach, and a review date. Each agent gets a short record that a person keeps current. The test is simple: anyone responsible should be able to say who owns an agent, what it can touch and why it exists in under a minute.

Key takeaways

• Register every agent that reads company data or takes action, including those bought inside existing software and those employees set up themselves.
• Every record needs a named business owner, not only a team name or a vendor.
• Record access as carefully as purpose: accounts, tools, permission level, data sources, memory and the model provider account.
• Write down which actions need human approval and exactly how to switch the agent off.
• A register only works if it is reviewed on a schedule and updated whenever the agent changes.

What belongs in an AI agent inventory?

For inventory purposes, an agent is any AI system that uses company data or credentials and produces output or actions without a person performing each step. That is wider than the agents your IT team deployed on purpose. Most companies find that the list includes more than they expected.

Candidates to register:

• Agents built or configured for you by a partner or an internal team
• Assistants embedded in software you already pay for, once they can read shared data or take actions
• Workflow automations that call a model to decide, classify or draft
• Custom assistants or personal agents that employees created and connected to company data
• Pilots and experiments that were never formally closed

A single chat session where someone pastes a public paragraph into a tool is a policy question, not an inventory item. The moment that tool is connected to a mailbox, a shared drive or a customer system, it belongs in the register.

The hardest entries to find are the ones nobody announced. Ask each department head what has been connected, then check software admin consoles, identity provider app lists and the integrations that people have authorized. Frame it as a way to support the work, not as an audit of individuals. If people fear consequences, the unofficial agents stay hidden. A register is usually the first artifact of a lightweight governance approach, because every other control depends on knowing what exists.

Which fields establish ownership and purpose?

Ownership gaps cause most of the trouble. An agent keeps running after its sponsor changes teams, a vendor contact leaves, or the original pilot ends. Without a named person, nobody feels entitled to change it or switch it off.

Record these identity and purpose fields for each agent:

• Name and one-line description: a plain name people will recognize, such as the supplier query assistant
• Role statement: one or two sentences describing the job the agent does, written like a job scope
• Business owner: a named person who answers for whether the agent is useful and appropriate
• Technical owner: the person or provider who maintains it and can change its configuration
• Backup owner: a second named person, so the record survives holidays and departures
• Status: proposed, pilot, production, paused or retired
• Users and audience: who may instruct the agent, and who may receive its output
• Out of scope: what the agent must not do, even if it technically could

The out of scope field is often skipped and often the most useful. Agents tend to drift toward whatever people ask of them. A written boundary gives the owner something to point to when a request goes beyond the original role.

Ownership also has levels. One person is accountable, others are responsible for doing the work, and some only need to be consulted or informed. If those distinctions are blurry in your company, a RACI for AI agents is a good companion to the register, and the register can simply link to it.

Which fields record access, data and memory?

Purpose tells you what an agent is supposed to do. Access tells you what it is able to do. The gap between the two is where risk lives, so the register should record both with equal care.

The OWASP Authorization Cheat Sheet starts from least privilege: grant only what is required for the task. The OWASP Top 10 for LLM Applications names excessive agency as a risk category, meaning a system with more functions, permissions or autonomy than its job needs. You cannot apply either idea to agents you have not described. These fields make the review possible:

• Identity and accounts: the mailbox, user or service account the agent acts as, and who administers it
• Channels: where people reach it, such as email, chat or a web form, and where it can send messages
• Tools and integrations: each connected system, with the permission level written as read only, draft only, or write
• Data sources: which documents, databases or folders it can read, and how sensitive each one is
• Memory: what the agent stores between sessions, where that store lives, who can inspect it and how long it is kept
• Model provider and account holder: which model it uses and whose account, billing and keys sit behind it
• Hosting and data location: where processing and storage happen, which matters for contracts and privacy duties
• Approval boundaries: the actions that always require a human to approve before they take effect

Two of these deserve extra attention. First, identity: an agent that borrows a person's login makes every action look like that person's, and it vanishes from your records when that person leaves. The reasoning behind giving a company agent its own identity and accounts is worth reading before you fill this field. Second, the provider account: if the keys and billing sit in a vendor's or an individual's account, your company may not control its own agent. Our note on who owns AI API keys in a business explains what to check.

Permission level is the field to be strictest about. Write what the agent can do, not what it usually does. If it has write access to the customer system but only ever reads, the record should say write.

Which fields cover operations, review and exit?

A register that describes only the day an agent launched goes stale quickly. A third group of fields makes the record a working tool.

• Success measure: the observable result that tells you the agent is doing its job, agreed in advance
• Monitoring and logs: where activity is recorded, who reads it and how problems are reported
• Last review and next review: dates set by the owner, with the name of the reviewer
• Last change and approver: what was altered in prompts, tools, permissions or model, and who signed off
• Dependencies: the systems, vendors or models that, if they change, would affect the agent
• Incident contact: who is called first when the agent behaves unexpectedly
• Shutdown and revocation: the steps to pause it, revoke its access and confirm that it can no longer act
• Exit and export: what must be kept, exported or deleted if the agent is retired or the provider is replaced

The NIST AI Risk Management Framework organizes risk work around governing, mapping, measuring and managing AI systems. A register supports the mapping step by recording context, and the success measure and review fields support the measuring and managing steps. You do not need to adopt a framework formally to borrow the logic.

The shutdown field should be tested, not just written. If the instruction reads revoke access in the admin console, someone should have confirmed that the owner has the rights to do that.

How do you build the first register?

A spreadsheet or shared table is enough to start. The effort lies in the conversations, not the tool. A workable sequence:

• Step one: appoint one person to run the register, with permission to ask questions in every department.
• Step two: collect candidates from department heads, software admin consoles, the identity provider's list of connected apps, finance records for new subscriptions and any integrations employees have authorized.
• Step three: create one template containing the fields above, and keep it short enough that people will actually complete it.
• Step four: fill in each record in a short conversation with the owner, not by sending a form and waiting.
• Step five: allow the answer unknown, mark it clearly and assign someone to resolve it. An honest gap is more useful than a guess.
• Step six: sort the records by access. Agents with write permissions or sensitive data get reviewed first.
• Step seven: set a review date for each record and list the events that force an earlier update.

Those events are the part most registers miss. Update the record when a new tool or data source is connected, when the model or provider changes, when the owner leaves or moves, when an incident occurs, and when the agent is given a new task. If your company already has a process for changing a live agent safely, add a register update as a required step in it. Otherwise the record will drift away from reality within a few months.

Keep the register boring and visible. A short list that the owner reads every review is better than a thorough document that no one opens.

What does a register entry look like? An illustrative example

This is an illustrative scenario, not a real company. A distribution business runs an agent that drafts replies to supplier questions about delivery dates. Its record might read:

• Name: Supplier delivery assistant
• Role: drafts replies to supplier delivery questions using the order system, for a buyer to review and send
• Business owner: head of purchasing. Backup: purchasing coordinator
• Technical owner: external implementation partner, with an internal contact in IT
• Status: pilot
• Out of scope: changing orders, promising dates in writing, handling payment questions
• Identity: a dedicated agent mailbox, administered by IT
• Tools: order system with read only access, shared mailbox with draft only access
• Data sources: open purchase orders and supplier contact records
• Memory: summaries of past supplier threads, stored in the company's own environment, retention set by the owner
• Model provider: company-held account, billing owned by finance
• Approval boundary: every outgoing message is approved by a buyer
• Success measure: buyers accept most drafts with light edits, judged in a recurring sample review
• Next review: set by the owner, earlier if tools or data sources change
• Shutdown: IT disables the mailbox and revokes the order system grant

Completing this record usually surfaces questions. Perhaps nobody can say how long the memory is kept, or the model account turns out to belong to the partner. Each question is a decision someone should make deliberately, and the register is the place where those decisions become visible and can be checked later.

How does managed operation keep the register current?

The fields above mirror what a first engagement with Be Human defines: one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Those decisions are written down at the start, so the first version of a record exists before the agent goes live.

In managed operations, the recurring work touches the same fields. Monitoring and recurring evaluations feed the success measure, permission reviews check the access fields against what the agent actually holds, and integration maintenance and controlled improvements update the change history. Identity, memory, channels and tools stay under the company's control, and the company keeps the final say on approvals and ownership. The register remains the company's document, readable by its own people without a provider's help.

Frequently asked questions

Do we need an inventory if we only run one agent? Yes, and it is easier to start now. A single agent still has an owner, access rights, a model account and a way to shut it down, and writing those down takes a short time. The habit and template are then ready when the second and third agents arrive.

Where should the register live? Put it in a shared location the owners and the administrators can all reach, with edit rights limited to the register keeper and the named owners. Choose something your team already opens, such as a shared table, rather than a new system that adds friction. What matters is that it is findable and has a visible history of changes.

How often should records be reviewed? Match the rhythm to the access. An agent that can write to customer systems deserves a closer review cycle than one that only drafts internal summaries. Beyond the schedule, always update on trigger events such as a new integration, a model change, a new owner or an incident.

How is an inventory different from a RACI or a governance policy? The inventory lists what exists and how each agent is set up, while a RACI assigns roles and a policy sets rules. They work together: the policy says what is allowed, the RACI says who decides, and the register shows whether each agent actually matches. Without the register, the other two have nothing concrete to apply to.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.