AI Agent Discovery, Inventory and Posture Management: What Each One Means

What is AI agent discovery?

AI agent discovery is the work of finding every agent that exists in an organization, whether or not anyone registered it. Its output is a set of agents found, each with enough evidence attached to locate it again, and its measure of success is how few agents it misses.

Discovery has to be done from the places agents live, because asking people what they run and watching what crosses a gateway both undercount. Employees don’t always know that a tool they connected counts as an agent, and a gateway only sees the agents configured to use it. Reading the artifacts agents leave in code repositories, on endpoints, in cloud accounts and in browsers finds the rest, and in one engagement it surfaced 327% more agents than a French biotech company’s CTO and security team had expected.

What is an AI agent inventory, and what should it contain?

An AI agent inventory is the maintained record of every discovered agent, with enough fields to answer a question about any one of them without asking around. Discovery produces the list once, while the inventory keeps it current, so an inventory refreshed only when someone runs a survey is already out of date.

These are the fields an inventory needs, and the question each one lets you answer.

Field	What it records	The question it answers
Owner	The named person or team accountable for the agent	Who do we call about this agent?
Platform and harness	Where it runs and the framework it runs inside	Which controls can reach it?
Model	The model or models behind it	Which provider sees its data?
Identity and credentials	Whose credentials it acts under, human or service account	What can it do in our name?
Tools and capabilities	MCP servers, skills, plugins, extensions and connectors configured	What can it act on?
Data reach	The data sources and classifications it can read or write	What could it expose?
Permissions	Read, write, execute and delete rights on each system	What could it change that can’t be undone?
Last activity	When it last ran, and how often it runs	Is it live, dormant or abandoned?
Change history	When its tools, permissions or behavior last changed	Has it drifted from what was approved?

The test of a finished inventory is whether it can tell you who owns a given agent and what would break if you turned it off. A table of agents that can’t answer both is a count, which can’t support a decision about any single agent.

What is AI agent posture management?

AI agent posture management is the continuous practice of connecting three views of every agent in the inventory: what it is configured to do, what it can reach with its current credentials and tools, and what it does when it runs. The full entry on posture management sets out why those three views drift apart and why agent risk tends to accumulate in the gap between them.

The third view is behavioral observability, which configuration-based posture tools can’t provide because it can’t be read from a file. Two agents with identical configuration can carry very different risk depending on which of them is exercising capabilities the other never touches.

How do discovery, inventory and posture management differ?

Each produces a different artifact and fails in its own way, which is why treating them as a single product feature tends to leave one of them undone.

	Discovery	Inventory	Posture management
Question it answers	Which agents exist?	What is each agent, and who owns it?	Is each agent doing what it should, with only the access it needs?
Output	Agents found, with evidence	A maintained record with fields per agent	A connected view of configuration, reach and behavior
Cadence	Continuous, as agents are created	Continuous, as agents change	Continuous, as behavior and access shift
Depends on	Coverage of the surfaces agents run on	Discovery	Inventory, plus behavioral observability
Fails when	A surface isn’t read, or agents must be registered to be seen	Fields are filled once and never refreshed	Configuration is checked but behavior isn’t

Because each depends on the one before it, a weakness early in the chain caps everything after it, so an agent that discovery misses has no inventory record and no posture at all.

What do the three look like for a single agent?

The distinction is easiest to see by following one agent through all three. Suppose a finance analyst builds a small agent with an agent SDK that reads the accounts-payable mailbox, matches invoices against purchase orders in the finance database, and drafts a summary for the team each morning. Nobody outside the team knows it exists.

Discovery is what finds it, by reading the repository where the code lives and the cloud account where it runs on a schedule, and it produces one new line: an agent, where it lives, and the evidence that it exists. The inventory turns that line into a record, attributing the agent to the analyst, noting the model behind it, the service account it uses, its two tool connections, read access to the mailbox, read and write access to the finance database, and that it last ran at seven that morning.

Posture management is what notices, three weeks later, that the agent has started writing to a payments table that its brief never mentioned, because someone widened the service account for an unrelated project. Nothing in the agent’s own code changed, so the inventory record still looks the same, and only the combination of reachable access and observed behavior shows that the agent is now doing something nobody approved.

How do you find out how many AI agents you are running?

Start with a definition of an agent, then count from the environments rather than from people. A workable definition is an LLM reasoning core connected to at least one tool, which covers a single-tool assistant and a multi-agent system under the same rule.

Then compare three counts, because the gaps between them are informative. The first is what teams report in a survey, the second is what passes through any gateway you run, and the third is what reading configuration across cloud, code, endpoint and browser finds. In our engagements the third number has been the largest, and the difference between it and the first is a rough measure of how much of your agent estate is currently ungoverned. A count from a survey or spreadsheet is a starting estimate, and it should be labeled as one wherever it is reported.

How do you build an AI agent inventory across cloud, code, endpoint and browser?

Build it surface by surface, because agents live in different artifacts on each one and a method that works well on one surface is often blind on another.

Cloud. Agents run in managed agent services, serverless functions that call model APIs, and SaaS platforms with built-in agent builders. The evidence lives in cloud account configuration and platform admin consoles, along with the service identities those agents use.

Code. Agents are defined in repositories using agent frameworks and SDKs, alongside MCP configuration files, skill definitions and CI pipelines that run agents on every commit. Reading the repository finds agents before they reach production, and finds the ones that never go through a deployment process at all.

Endpoint. Coding agents and desktop assistants run on developer and employee machines, often with locally configured MCP servers and access to whatever the user’s credentials reach. These are the agents most likely to be missing from every other count, because they never touch central infrastructure.

Browser. Browser agents and AI-enabled extensions act inside the user’s authenticated sessions, so they reach SaaS data directly without generating any traffic a network control would attribute to an agent.

Once agents are found on each surface, join them into one record per agent, attribute each to an owner, and record its tools, data reach and permissions. Keep the record current by reading the same sources continuously, since a tool connection can be added in minutes and an inventory that waits for the next quarterly review will miss it.