Skip to content
Back to blog
February 19, 2026·Marc Edun, COO·2 min read

Before you write another AI policy, build an agent inventory

Agent Governanceinventoryshadow AIoperating model

Most organizations do not have one AI estate. They have several overlapping ones.

Engineering has agents in code repositories and cloud environments. Operations has automations in workflow platforms. Teams connect assistants to document stores. Individual employees create agents with SaaS tools. Procurement sees vendor contracts; security sees identities; finance sees invoices.

Each view is accurate and incomplete.

Before adding another policy, create a shared inventory of the agents that actually exist.

A model list is not an agent inventory

Listing approved model providers is useful, but it does not show what the systems built on those models can do.

The inventory should be organized around deployed agents and workflows. For each one, record:

  • business purpose and current status;
  • accountable business owner and technical owner;
  • users or systems that can invoke it;
  • model and provider dependencies;
  • data sources and classification;
  • tools, connectors, repositories, and cloud environments;
  • read, write, send, execute, and approve authority;
  • human review points and escalation owner;
  • run volume, cost owner, and budget boundary;
  • evidence and retention location;
  • last review date and decommissioning path.

This turns a list into an operating map.

Discover from more than questionnaires

Self-reported intake misses the agents teams forgot, inherited, or never classified as “AI.” Combine interviews and procurement data with technical discovery.

Useful signals include model-provider usage, API keys, OAuth grants, service accounts, workflow definitions, repository dependencies, SaaS audit logs, browser extensions, and cloud telemetry. Discovery should be proportionate and privacy-aware, but it cannot rely only on people remembering what they built.

Mark confidence and provenance for every record. “Confirmed from runtime logs” is different from “reported by owner” and different again from “suspected from spend.”

Define ownership before assigning risk

An agent without a named owner is already a governance finding. Someone must be able to answer whether it is still needed, whether its access is appropriate, and who should respond when it fails.

Business ownership and technical ownership may differ. Record both. The business owner is accountable for purpose and impact; the technical owner is responsible for implementation, operation, and evidence. Risk, security, legal, and finance provide controls and challenge, but they should not become the default owners of every agent.

Use the inventory to prioritize

Do not treat every record equally. Rank agents by consequence and authority.

Start with systems that can write to production, access sensitive data, communicate externally, trigger financial activity, make regulated recommendations, or delegate to other agents. Add exposure, frequency, reversibility, and evidence quality to the assessment.

The output is a control queue: which agents need access reduction, approval gates, stronger evidence, cost limits, evaluation, or retirement first.

Keep it alive

An inventory snapshot ages immediately. New tools are connected, credentials change, models are swapped, and a read-only proof of concept gains write access.

Tie review to lifecycle events: creation, material change, production promotion, access expansion, incident, owner change, and decommissioning. Reconcile the inventory against discovery signals on a schedule.

The inventory is not paperwork before governance begins. It is the shared surface through which governance operates.

Know what every agent did — and why.

Start with a 14-day audit of your agents, access, evidence, costs, and human checkpoints.

Explore the audit pilot