Agentic AI Wiki
AI Blog / Discovery is not an inventory
AI Blog

Discovery is not an inventory

In four days three vendors shipped the same admission: nobody knows what agents are running. CrowdStrike put discovery in the endpoint sensor, AIR raised $50M for an inline firewall at the context boundary, and Tenable and OpenAI put a review in front of a registry. Each answer is complete about one place and silent everywhere else — and every governance regime you are being audited against assumes an authoritative register, not an estimate. The number to start tracking is the gap between the two.

By Agentic AI Wiki 15 min read

Three vendors shipped agent security in the same four days, and underneath three different products they made the same admission: nobody can say what agents are running in their own company. CrowdStrike put the answer in an endpoint sensor, AIR raised $50 million to put it in the request path, Tenable and OpenAI put it in front of a registry — and every one of those answers is a survey, complete about one location and silent about everywhere else. That matters because the regimes you are audited against do not ask for a survey. They ask for a register, and the useful metric this week is not how many agents you discovered. It is the size of the gap between what is discovered and what is registered.

At a glance

Four days, three announcements, three completely different places to stand.

ProductAnnouncedWhere it instrumentsWhat it primarily does
CrowdStrike Falcon Guardian 1 Sep 2026, at Fal.Con The Falcon sensor on Windows and macOS endpoints Discovers known and shadow agents, traces prompt to action, blocks unapproved ones
AIR 1 Sep 2026, out of stealth Inline, at the boundary where context is assembled Screens instructions, tools and data entering an agent's context before it acts
Tenable / OpenAI Exchange Inspector 3 Sep 2026 The CyberAgents Exchange registry, pre-deployment Reviews submitted agents, skills, MCP servers and playbooks before adoption
Coverage matrix: enumeration, runtime behaviour, enforcement and reach beyond the endpoint A four-by-four matrix. Rows are a self-service registry, pre-deployment review, an endpoint sensor, and an inline context firewall. Columns are how well each enumerates what exists, whether it observes runtime behaviour, whether it can block, and whether it reaches agents that never run on a managed endpoint. The self-service registry is weak on enumeration because registration is voluntary, sees no runtime behaviour and blocks nothing, but nominally covers every environment. Pre-deployment review is medium on enumeration within its own catalogue, sees no runtime behaviour, gates admission rather than execution, and is environment-neutral. The endpoint sensor is strong on enumeration and runtime behaviour and can block execution, but reaches nothing off the endpoint. The inline firewall is medium on enumeration, strong on runtime behaviour and blocking for traffic it sees, and reaches whatever is routed through it. What each layer can actually answer Enumerates what exists Sees runtime behaviour Can stop an agent Reaches beyond the endpoint Self-service registry Voluntary None No In principle Pre-deployment review Its catalogue only None Gates admission Environment-neutral Endpoint sensor Running + dormant Prompt to action Blocks execution No Inline context firewall What routes through Context contents Blocks in path If routed Strong Partial Weak or absent
Every row is strong somewhere and blank somewhere else. No row is strong across all four.

Read the top row first, because it is the one most organisations are relying on today. A self-service registry — the spreadsheet, the ServiceNow form, the wiki page where teams declare their AI systems — scores weakly on the only column that its whole purpose depends on. Registration is voluntary, and the agents you most need to know about are precisely the ones nobody filed a form for.

Three products, three places to stand

Three instrumentation points on the path an agent takes A left-to-right path: a component source such as a registry or marketplace, installation on a host, the running agent process that assembles context, the tool calls it makes to MCP servers and APIs, and the systems of record it finally touches. Three controls attach at three different points — a pre-deployment review at the component source, an endpoint sensor at the host, and an inline firewall at the boundary where instructions, tools and data enter the agent's context. Beneath the path sits a wide band showing the agents none of the three observe: a workflow inside a SaaS product, an agent in a CI runner, one in a personal cloud account, and a browser extension in an unmanaged profile. Where each control attaches The path an agent takes Component source Registry, marketplace, repo, skill file. Install on a host User space, running as the user, no admin step. Agent process Assembles context, decides, calls tools. Tool calls MCP servers, APIs, shell, browser. Systems of record Data, money, identity, production config. Pre-deployment Review before anyone installs it. Endpoint sensor Enumerates what is actually running. Inline context firewall Screens instructions, tools and data on the way in. Each control is complete about the point it sits on, and silent about every agent that never passes it. Outside all three A workflow inside a SaaS product An agent in a CI runner A container in a personal cloud account A browser extension, unmanaged profile The register that governance frameworks assume is authoritative; every line above produces an estimate.
The same path, three interception points — and one band underneath that none of them touch.

CrowdStrike: the sensor already on the laptop

Falcon Guardian is the successor to Falcon AIDR, which went generally available in December and picked up shadow-AI discovery and endpoint runtime protection at RSAC in March. The Guardian pitch is that the Falcon sensor already sits on every managed Windows and macOS machine, so it can enumerate agents the way it has always enumerated processes: a live inventory of running and dormant agents, who deployed each one, and its current security status. Agent Runtime Visibility then links agent behaviour to ordinary endpoint telemetry, tracing prompts, identities, tool calls and skill use through to the downstream system actions they produced. Agent Access Controls define which agents may run on a managed endpoint and block the rest. Managed services and an AI gateway are stated as planned rather than shipping.

The strategic move is the unglamorous one. CrowdStrike is not claiming a novel detection technique; it is claiming that the enumeration problem is an endpoint problem and it already owns the endpoint. On the population of agents that are ordinary desktop processes — a coding agent, a local MCP server, an assistant a developer installed on Tuesday — that claim is basically correct, and no registry-based approach competes with it.

AIR: the firewall in front of the context

AIR left stealth on the same day with $50 million in seed funding led by Sequoia and Greenoaks, a founding team of Yair Saban and Niv Hoffman, twenty-plus customers concentrated in financial services and pharma, and a product that sits inline and screens what enters an agent's context: instructions, tools, and data, evaluated before the agent acts. Its published research is the part worth keeping: more than 17,800 public AI add-ons, representing some 6.7 million installations, rely on untrusted external instruction sources — that is, they pull text at runtime from somewhere the installer does not control.

That number is a good description of why the pre-deployment model has a ceiling. A skill or MCP server that fetches its instructions at runtime is not a fixed artefact you can review once; it is a channel. Reviewing the manifest tells you what it was on the day you looked. This is the same argument that makes agent supply chain security awkward, and it is why an inline control is not redundant with a catalogue review.

Tenable and OpenAI: review before adoption

Tenable launched the CyberAgents Exchange in August as an open-source, security-native registry for agents, skills, MCP servers and multi-agent playbooks, and it holds more than a hundred community-submitted components after the SWARM build event at Black Hat. The Exchange Inspector, announced on 3 September, is the review process in front of it: an assessment using OpenAI's GPT cyber models, skills inspection through Tenable One AI Exposure, and human review by Tenable researchers, examining LLM instructions, tool-chaining permissions and prompt-injection exposure.

This is the most conventional of the three and the easiest to underrate. A curated catalogue with a published review process is how every other component ecosystem eventually got usable, and the alternative — every security team reading every skill file themselves — does not scale past a handful of teams. The limit is equally conventional: it governs what comes through the front door, and the front door is not where most things arrive.

The premise all three share

Strip the products away and the same sentence is underneath each of them: the register does not exist. Every AI governance regime currently being implemented opens with an inventory obligation. The EU AI Act's provider and deployer duties presuppose you know which systems you operate. ISO/IEC 42001 wants a documented scope. NIST's AI RMF opens with Map, and Map begins with enumeration. Every one of those frameworks is written as though an authoritative list is obtainable by asking.

It is not, and the reason is structural rather than cultural. A classic enterprise application arrived through procurement, needed a server, and left a paper trail whether anyone wanted one or not. An agent arrives as a command-line install running in user space under the user's own credentials, or as a checkbox inside a SaaS product the department already pays for, or as a workflow someone built in an automation tool over a lunch break. None of those crosses a control point that produces a record. The authority it runs with is the user's, already granted, and nothing in the flow ever asks an administrator a question.

So when three vendors independently ship discovery in the same week, the correct reading is not that agent security got a new capability. It is that the market has conceded the registry was never going to be filled in, and is now selling you estimates of it from wherever each vendor happens to have a sensor. That concession is honest and useful. It is also easy to mistake for a solution to the obligation, and it is not one — a census taken from a single vantage point is not a register, and calling it one in an audit is a statement you cannot support.

What each one cannot see

What each control can enumerate, and what it is blind to Three columns. Pre-deployment review enumerates components submitted to a registry and is blind to anything installed from elsewhere. The endpoint sensor enumerates processes on managed Windows and macOS machines, including dormant ones, and is blind to agents that run off the endpoint entirely. The inline context firewall enumerates the skills, plugins and MCP servers on traffic routed through it, and is blind to any agent configured to talk directly to a model provider. Enumerates / blind to Pre-deployment review Components submitted to one registry, inspected before anyone installs. Endpoint sensor Running and dormant agents on managed Windows and macOS. Inline context firewall Skills, plugins and MCP servers on traffic that routes through it. Blind to Blind to Blind to Anything installed from a repo, a gist, a vendor bundle or an employee. Every agent that never touches an endpoint: SaaS, CI, cloud, mobile. Any agent pointed straight at a provider with a personal key.
Each control's blind spot is not a gap in the product. It is the definition of where it sits.

Compare the three on the same axis and the pattern is clean: each is authoritative exactly over the traffic that passes its own chokepoint, and each has a large, named population it will never observe. The endpoint sensor is superb on a developer's laptop and structurally blind to an agent running inside a SaaS vendor's product, in a CI runner, in a container on a cloud account expensed to a personal card, or on a phone. The inline firewall is authoritative over what routes through it and invisible to an agent configured with a personal API key pointed straight at a model provider. The pre-deployment review governs its own catalogue and says nothing about the skill file a developer copied out of a blog post.

None of that is a criticism of any of the three. It is what "instrumentation point" means. The mistake available here is the one enterprises made with CASB a decade ago: buy the sensor, watch the discovered count climb, and read a rising number as improving coverage — when a rising number is equally consistent with a growing population you are sampling ever more of, or ever less of.

Note also that two of the three sell enforcement alongside discovery, and enforcement is where the layers stop being interchangeable. Blocking an unapproved agent binary on a managed endpoint is a real control over a real population. But the authority that makes an agent dangerous usually lives in a token, not in a process — the OAuth grant a user clicked through, the API key in a config file, the service account someone reused. Killing the process on the laptop does not revoke the grant, and the same grant will happily serve the next process. That is the argument in delegated access and consent records, and none of this week's products replaces it.

The number worth tracking

If discovery is an estimate and the registry is a wish, the useful instrument is the difference between them. Concretely:

  • Keep the registry, and stop treating it as the inventory. Its job changes from "the list of what exists" to "the list of what someone has accepted responsibility for". That is a genuinely valuable artefact and a much more honest claim, and it is what agent inventory and registry is actually for.
  • Reconcile discovered against registered, on a schedule, per environment. Two counts and one join key. The join key is the hard part, and the one worth arguing about in design review: an endpoint sensor names a process and a deploying user; a registry names a system and an owner. Whatever links those two is the piece nobody sells you.
  • Track the delta as a trend, not a level. A big gap in month one means your discovery started working. A gap that grows through month six means agents are being created faster than anyone is claiming them, which is a governance finding independent of whether any single agent is risky.
  • Report coverage by environment, not in aggregate. "94% of agents discovered" is meaningless if it means 94% of endpoint agents and no visibility into SaaS. Break the number down by where you can instrument, and let the environments with no sensor show up as blank rather than as zero.
  • Close the loop on what discovery finds. An unregistered agent that gets discovered, then registered, then owned, is the whole point. If your discovered-and-unclaimed count is flat month over month, you bought telemetry, not governance.

The uncomfortable corollary: your inventory's completeness is now a property of your security vendor's sensor coverage, which means the agent inventory has quietly moved from the platform team to the security team. Whoever owns the sensor owns the count, and the count is what the auditor reads. That is worth settling deliberately rather than discovering during the audit.

When to reach for which

If your problem is…Pre-deployment reviewEndpoint sensorInline context firewall
"I don't know what's running"Only within its catalogueBest available, on managed hostsOnly what routes through it
"Developers install random skills"Strong — this is its caseDetects after the factScreens the instructions at runtime
"A skill fetches instructions at runtime"Weak — review is a snapshotSees the resulting actionsStrong — this is its case
"Agents in SaaS products I don't host"NoNoOnly with a routing mandate
"I need an auditable register"Contributes a catalogueContributes a censusContributes traffic

The bottom row is the one to sit with. Three vendors, three genuine contributions, and the artefact the regulation asks for is still assembled by you.

FAQ

Is an endpoint sensor enough to satisfy an AI inventory obligation?

No, and claiming so is a defensible-sounding position that collapses on the first question about SaaS. An endpoint sensor produces a strong census of agents that run as processes on managed Windows and macOS machines. Obligations under the EU AI Act, ISO/IEC 42001 and similar regimes are scoped to the AI systems you provide or deploy, which includes plenty that never touch a laptop.

Why does discovering dormant agents matter?

A dormant agent still holds its credentials and its tool grants, and it typically still has a trigger — a schedule, a webhook, a hotkey. Enumerating only running processes gives you a count that varies with the time of day and misses anything waiting to be woken.

Does an inline firewall replace prompt-injection defences in the agent itself?

It adds a layer and removes none. Screening what enters the context catches known-bad instruction sources and excessive permission requests; it does not make an agent safe to hand hostile text to, because the classifier has a failure rate and the payloads that work rarely contradict your instructions. See prompt injection defence in 2026 for the control taxonomy.

If the registry is unreliable, why keep it?

Because ownership cannot be discovered. A sensor can tell you a process exists and which account launched it; it cannot tell you who is accountable for what it does, what it is allowed to touch, or whether anyone reviewed it. That information only exists if a human writes it down, which is what the registry is for once you stop asking it to be complete.

What is the single cheapest thing to do this week?

Pick one environment where you already have telemetry, count the agents in it, count the agents registered for it, and put both numbers on one slide. Most teams have never seen the two numbers next to each other, and the gap generally settles the budget conversation without further argument.

Further reading

On this wiki:

Sources: