An agent inventory should track authority, not just existence

The next enterprise AI artifact is probably going to look boring.

It will not be a new prompt pattern.

It will not be a cinematic demo.

It will be an inventory.

That sounds administrative, but it is a real signal. As agents move from experiments into production workflows, companies need to know where the agents are, what systems they touch, what data they can see, what actions they can take, and who is responsible when those actions create consequences.

This morning’s scan had a few live candidates pointing in the same direction. Databricks’ State of AI Agents material argues that organizations using governance tools get far more AI projects into production, while OneTrust’s Spring 2026 release messaging includes AI agent inventory, policy management, and guardrail enforcement. Boomi’s recent enterprise platform positioning also leans into persistent context, trusted data access, and governance as agents move from pilots into production.

None of that is surprising by itself.

The useful point is narrower:

An agent inventory is only useful if it becomes an authority inventory.

A list of agents tells you what exists.

An authority inventory tells you what each agent is allowed to do.

That difference matters.

What changed

The old shadow-IT problem was mostly about tools.

Which apps are people using?

Where is company data going?

Who approved this integration?

Agents turn that into a deeper problem because they are not just places where work happens. They can become participants in the work.

A chatbot that answers policy questions is one thing.

An agent that reads tickets, updates CRM records, drafts customer replies, recommends refunds, opens pull requests, buys services, changes schedules, or triggers downstream workflows is different.

The first problem is visibility.

The second problem is authority.

This is why the inventory layer is becoming more important. Companies cannot govern agents they cannot see. But seeing them is only the first step. The more important question is what kind of operating authority each agent has been given.

Can it observe?

Can it prepare?

Can it recommend?

Can it execute?

Can it commit the organization externally?

Can it spend, send, delete, approve, publish, deploy, or change records without a human?

Those questions are not metadata. They are the management system.

What people are overreacting to

People may overreact to agent inventory as a compliance checkbox.

That is understandable. Inventories sound like the kind of thing risk teams ask for after the interesting work has already happened. They can easily become spreadsheet theatre: name, owner, system, vendor, purpose, risk rating, review date.

That is better than nothing.

But it is not enough.

A company can have a beautiful list of agents and still not know whether one of them can make a bad commitment on behalf of the business.

It can know that a sales-support agent exists without knowing whether it can email customers directly.

It can know that a finance agent exists without knowing whether it can approve invoice exceptions.

It can know that a coding agent exists without knowing whether it can open pull requests, merge, deploy, or run networked commands.

It can know that a procurement agent exists without knowing whether it can switch vendors, split orders, or renew a subscription.

The inventory exists, but the operating risk is still hidden.

The mistake is treating inventory as a map of tools.

It needs to become a map of delegated authority.

What people are underreacting to

People are underreacting to how quickly agent governance becomes organization design.

Once an agent can act across systems, the question is no longer only technical. It becomes a question of role design.

What role is this agent playing?

What work has been delegated to it?

What decisions remain human?

What evidence is required before it crosses a boundary?

Who reviews exceptions?

What happens after repeated failures?

What authority can be expanded after repeated success?

This is where many teams will get stuck. They will buy or build agent platforms, add logging, create a governance register, and still struggle because they have not described the agent’s authority in operational language.

A risk rating is not the same as an authority boundary.

A system owner is not the same as an accountable workflow owner.

A policy link is not the same as a stop-line.

A dashboard is not the same as a decision about what the agent may do next.

The inventory should not only help the company answer, “Do we have this agent?”

It should help the company answer, “What has this agent earned the right to do?”

The authority-inventory fields

A practical agent inventory should include normal IT and risk metadata, but the operating layer needs sharper fields.

At minimum, I would want these:

1. Workflow location
   Where in the work loop does the agent operate? Intake, triage, drafting, analysis, recommendation, execution, review, exception handling, reporting, follow-up?

2. Authority level
   Is it observe-only, prepare-only, recommendation-only, human-approved execution, bounded autonomous execution, or external commitment authority?

3. Allowed commitments
   What can it actually change? Records, messages, tickets, schedules, purchases, permissions, code, files, customer promises, approvals, deployments?

4. Forbidden actions
   What must it never do, even if it appears confident? Delete, send externally, spend above a cap, approve exceptions, bypass review, merge to production, contact customers, use certain data?

5. Escalation triggers
   When must it stop and ask? Low confidence, missing data, policy conflict, novel request, high-value transaction, unhappy customer, legal/regulatory language, irreversible action?

6. Evidence required to keep authority
   What proof shows the current authority level is still deserved? Accuracy, exception rate, human correction rate, complaint rate, rework rate, audit findings, financial impact, review quality?

7. Evidence required to expand authority
   What would justify giving the agent more scope? Stable performance over enough cases, low-severity exceptions, good recovery, clear human-review agreement, predictable edge cases?

8. Rollback or demotion path
   What happens when the agent fails? Narrow scope, return to human approval, disable a tool, reduce limits, require retraining, redesign the workflow, retire the agent?

9. Accountable human owner
   Who owns the workflow decision, not just the vendor relationship or system configuration?

10. Next authority review date
    When will the organization explicitly decide whether the agent should continue, expand, narrow, pause, or be retired?

These fields change the conversation.

Instead of asking, “Do we have governance?” the team asks, “Can we explain why this agent has this authority today?”

That is a much better test.

A simple example

Imagine a customer-support agent.

A weak inventory entry says:

• Name: Support Agent
• Purpose: Helps answer customer tickets
• Owner: Customer Operations
• Risk: Medium
• Status: Active

That is visibility, but not control.

An authority inventory says:

• Workflow location: ticket triage and draft response
• Authority level: prepare-only for refunds; human-approved execution for plan changes below a defined threshold
• Allowed commitments: classify tickets, retrieve customer history, draft replies, recommend refunds, update internal notes
• Forbidden actions: send customer-facing messages, issue refunds, promise exceptions, close escalated tickets
• Escalation triggers: angry customer, legal threat, refund above threshold, missing order data, policy mismatch
• Evidence to keep authority: human reviewers accept at least 90% of classifications and drafts with minor edits
• Evidence to expand authority: three months of low correction rates on low-value plan-change cases
• Rollback path: return plan-change updates to human-only execution if correction rate rises or complaints increase
• Accountable owner: head of customer operations
• Next review: monthly operating review

Now the inventory is useful.

It tells managers what the agent does, what it may not do, what evidence matters, and what decision must be made next.

The manager takeaway

The agent inventory should not be treated as clerical hygiene.

It should be treated as the front door to agent management.

If you are a manager, do not only ask your team for a list of deployed agents. Ask for the authority inventory.

For every agent, ask:

• What workflow step does it occupy?
• What can it observe, prepare, recommend, execute, and commit?
• What is explicitly outside its authority?
• What evidence would make us expand or reduce that authority?
• Who owns the authority decision?

If those questions are hard to answer, the problem is not the inventory template.

The problem is that the organization has delegated work without clearly describing the delegation.

That is exactly where agent risk lives.

The next phase of enterprise AI will have more dashboards, more governance tools, more inventories, more policy managers, and more runtime controls. Good. Those are needed.

But the practical edge will go to teams that use those tools to answer the management question underneath all of them:

What has this agent been allowed to do, and why?

That is the difference between tracking AI and managing AI.