Your AI Inventory Is a Graph, Not a Spreadsheet
Most AI inventories answer "what do we have?" and go stale the same week. The questions worth answering are what's connected to what, and what changed since.
Every CISO I talk to about agentic AI opens with the same question: What AI do we have?
It sounds like the easy part. Get a list, put it somewhere, move on to the hard problems. A year into most AI programs, it's still unanswered—because we're treating it as an asset management exercise, and it isn't one.
I've written that the way out of vendor confusion is to start with the architecture rather than the product list. This is the layer underneath it. Before you can choose capabilities, you have to see what you're governing. Most inventories being built today can't carry the weight that's about to be put on them.
There isn't one inventory
"What AI do we have?" isn't a single question.
The answer may need to include AI applications, models, copilots, agents, MCP servers, tool connections, APIs, datasets, prompts, memories, vector databases, vendors, plugins, autonomous workflows, identities, permissions, service accounts, and secrets.
That's not one list. It's closer to eighteen, maintained by different teams in different systems on different refresh cycles. Ask three groups for the AI inventory and you'll get three documents that don't reconcile, all of them accurate.
Two entries get left out more than the rest: memories and retrieval sources. If an agent makes decisions based on what it retrieves, then the things it retrieves from are part of what you're governing. When nobody owns that list, nobody notices when something poisoned enters it.
The list isn't the point. The edges are.
Knowing an agent exists tells you almost nothing.
What matters is which model it uses, which tools it can invoke, which APIs and datasets it reaches, which credentials it holds, which identity it acts as, who owns it, and which other agents it can call.
I've argued that "we have 300 agents" tells you nothing until you name the layer—orchestrator, agent, sub-agent, tool. The same holds one level down. Without the connections, a count is just a number.
The risk lives in the connections. An agent with modest permissions that can call another agent with broad ones creates a privilege escalation path, and it shows up in neither row of a spreadsheet. It exists only in the edge between them.
The inventory isn't the list.
The inventory is the graph.
That distinction pays off the moment someone asks a real governance question. Rows can't answer these. Relationships can.
- Which agents can ultimately reach production?
- Which agents share the same credential?
- What breaks if this MCP server goes away?
- Which approvals become invalid if this model changes?
- Which workflows touch regulated data?
Every node still needs business context: a named owner, a business purpose, production or experimental status, a data classification, and a criticality rating. Without those, you have technical metadata, not governance. What governing those identities looks like is its own subject. This is the step before it.
The inventory was true on Tuesday
A point-in-time inventory of an agentic environment goes stale almost immediately. Not the way a CMDB drifts over quarters. On some platforms, within hours.
Be precise about which drift this is. In a detection context, drift is behavioral—an agent deviating from its baseline at runtime, which is a rogue-agent problem for the SOC. This is different. Here the agent is behaving exactly as configured. The configuration has moved away from what was approved.
Tools get connected. Permissions expand. A model gets updated underneath a workflow nobody re-reviewed. Retrieval sources, prompts, and memories evolve. A guardrail gets relaxed to unblock a release.
In many organizations, none of that generates a request. Someone connects another tool and the work continues.
The gap between the system you approved and the system that's running widens every day.
What I want from an inventory isn't a snapshot. I want to know, on any given morning: What tools did this agent gain yesterday? What permissions changed? What guardrails moved?
Detection and reassessment are not the same job
This is the distinction I'd most like teams to make explicit. Collapsing the two is why so many programs have change data and still get surprised.
An agent is approved with access to Jira and Confluence. Months later, someone connects GitHub and a deployment tool. Nothing breaks. Nothing alerts. But the original approval assumed read-only documentation access, and that assumption is now false.
Detection is the inventory noticing the change. It's a technical capability. It fires on a diff.
Reassessment is governance deciding whether the original approval still holds. It's a judgment, and it belongs to whoever owned the approval.
Different capability, different owner, different system of record. A platform can be excellent at the first and give you nothing on the second—a stream of change events routed to a team with no authority to act on them, or a risk function that finds out during the annual review.
The test is simple: when an agent gains a new tool, does anything reopen the decision that was made when it was approved?
A dashboard is detection.
A workflow with an owner and a deadline is reassessment.
Continuous doesn't mean constant. Most changes are noise. The value is in the routing—deciding in advance which changes reopen a decision. A new tool connection, a permission expansion, or a change in autonomy level are the three I'd wire to a person. The rest can accumulate for periodic review.
Start at intake, not at discovery
The cheapest place to build an inventory is at intake, before anything is deployed.
Discovery-only inventories are archaeology. You reconstruct intent from artifacts, and the two fields that matter most—why this exists and who owns it—were never written down.
Intake fixes that, and not because security wants another form. It's the one moment when someone who understands the business purpose is in the room and motivated to explain it.
What problem does this solve? Who owns it? What systems and data will it reach? How autonomous is it meant to be? Does it call external services?
Five questions, asked once, when the answers are cheap.
You still need discovery because shadow AI is real, and intake only catches what comes through the door. But intake plus discovery creates a fundamentally different inventory than scanning alone.
What I'd ask a platform to show me
The product questions I'd put to any AI security vendor I've written about before. The inventory-specific version is short, and it isn't the count of supported asset types—that's the easiest number on any datasheet to inflate.
Does it map relationships, or only enumerate objects?
Does discovery actually trigger a governance workflow, or does it stop at a dashboard?
I'd rather have a platform that discovers fewer things and understands how they connect than one that hands me a spreadsheet full of disconnected objects.
In agentic systems, risk doesn't emerge from the assets themselves. It emerges from the relationships between them—and from how those relationships change over time.
You can't govern what you haven't found.
And you can't monitor what nobody owns.
