Shadow AI isn't a policy gap. It's an inventory gap.

Salesforce spent 10 September 2026 announcing an AI Control Plane whose first two verbs are “discover and register”. ServiceNow’s expanded AI Control Tower, generally available since August, leads with “discover” as well. Okta now registers every AI agent as a first-class identity in its directory. Three of the largest enterprise software vendors have arrived at the point this article made in April: shadow AI governance starts with an inventory, not a policy. You cannot govern what you cannot see.

What they are selling is the easy half of the inventory.

TL;DR: Shadow AI is an inventory gap before it is a policy gap. EMA’s August 2026 survey of 202 enterprise IT and security leaders, commissioned by Cequence, found 47% cannot reliably inventory the agents running in their environment while 46% are already scaling agentic AI across departments. The new control planes automate discovery, but discovery runs through connectors and finds agents on the platforms it is wired to, which is not where shadow AI lives. VentureBeat’s July 2026 survey put the average enterprise on 3.1 agent platforms, so any single control plane is one registry among several. The inventory that governs is the one the enterprise owns: every agent, its owner, what it can reach, the credential it runs on, how it is stopped, and whether it is still alive. The policy comes second.

Policy without inventory is theater

The standard corporate response to AI risk is still a document. An acceptable-use policy goes around, everyone clicks “acknowledged,” and leadership feels governed. Meanwhile the AI actually in use runs outside that policy: in browser tabs, on personal accounts, in half-built automations nobody registered.

HiddenLayer’s 2026 AI Threat Landscape Report, a March 2026 survey of 250 IT and security leaders, found 76% now describe shadow AI as a definite or probable problem, up from 61% in 2025. The same survey found 31% of organisations don’t know whether they experienced an AI security breach in the past twelve months. You can’t know whether something breached if you don’t know what’s running.

A policy is a rule applied to a known set of things. If you don’t know what AI systems exist, what data they can reach and who runs them, the policy applies to the slice you happen to know about, and the risk lives in the slice you don’t. Picture the real surface. An analyst pastes a customer list into a consumer chatbot to “clean it up.” A sales team wires an agent to the CRM through a no-code tool on someone’s personal key. An engineer stands up a retrieval system over a folder of contracts. None of it is malicious. All of it is invisible to whoever signed the policy.

You haven’t deployed an agent in these cases. You’ve deployed an incident with a delay.

The vendors now agree, and sell the easy half

Salesforce’s Trusted Enterprise AI Harness, announced 10 September 2026, is built around six capabilities and an AI Control Plane that, in Salesforce’s words, lets companies “discover and register agents and AI capabilities, establish identity and policy, manage lifecycle, evaluate performance, observe behavior and outcomes, and control cost across Salesforce and third-party AI.” The new capabilities start rolling out early in Salesforce’s fiscal 2028, which begins in February 2027. ServiceNow’s expanded AI Control Tower, announced in May with general availability in August, runs on five verbs: discover, observe, govern, secure, measure. Okta’s Agent SSO, generally available since 24 August, registers each agent as an identity in Universal Directory and issues short-lived tokens in place of stored credentials.

Read the ServiceNow announcement closely and you’ll see what discovery is. It “finds AI assets deployed across the organization” through 30 new enterprise integrations spanning AWS, Google Cloud, Microsoft Azure, SAP, Oracle and Workday. That is a list of places the tool knows how to look. It’s a good list. It is also a description of the agents that were never the problem: the ones built on a governed cloud account, through a sanctioned integration, by a team that follows procurement.

The agents the word “shadow” describes are the ones built where there is no connector. The n8n instance on a laptop. The browser extension with a personal key. The script a contractor left running on a VM nobody remembers provisioning. Connector-based discovery cannot see them, by construction, and a dashboard that shows every agent it can see looks exactly like a dashboard that shows every agent.

Then there’s the count. VentureBeat’s own July 2026 survey of 107 respondents at organisations with 100 or more employees, which VentureBeat itself calls self-selected and directional, found 85% run two or more agent orchestration platforms, averaging 3.1. Take it as direction, not decimals. The direction is that a control plane arrives into an enterprise that already has three registries, one per platform, each with its own definition of what an agent is. A fourth product that promises to govern all of them is a fourth registry until someone reconciles the other three into it. Reconciling is a job, not a feature. Three platforms means three inventories, and now a fourth place where the inventory can be wrong.

What the survey data says about inventory

EMA’s survey is the most specific public data on this I’ve seen. Asked to describe their ability to discover and inventory all AI agents currently operating in their environment, including those deployed by individual teams, 53.0% of respondents said they had an automated, centralised inventory. 18.3% had a manual inventory process. 28.2% had partial visibility into some teams or systems. 0.5% had none. EMA’s summary: 47% cannot reliably tell you what agents are running, and they’re in that position “while simultaneously running dozens of agents in production.” More than 43% of the same respondents run between six and twenty distinct agents; nearly 40% run more than twenty.

EMA/Cequence, Aug 2026, n=202	Share of respondents
Automated, centralised agent inventory	53.0%
Manual inventory process	18.3%
Partial visibility into some teams or systems	28.2%
No visibility	0.5%
Pilots paused indefinitely	18.8%
Pilots formally discontinued or abandoned	11.9%
Pilots restarted from scratch	12.4%
Can produce a complete 30-day audit trail for an agent easily	54.0%
Can produce it only with significant manual effort	33.2%
Can produce it only partially	11.9%

Source: EMA Research Report, “Agents Without Guardrails: The Agentic AI Governance Gap in the Enterprise,” commissioned by Cequence Security, 202 enterprise IT and security leaders at organisations with 1,000+ employees.

The more interesting finding is why the inventory is incomplete, and it isn’t a tooling gap. EMA reports that nearly 68% of respondents have had a security, identity or governance review directly delay, scale back or stop an agent project, and describes what teams do next: they “learn to avoid triggering formal security checkpoints through informal deployments, shadow agent inventories, and production deployments that live in the governance record as ‘still in pilot’ long after they are running at meaningful scale.”

That’s the whole mechanism in one sentence. A registry is only as honest as the incentive to register. “Register” is a verb with a subject, and the subject is a team that has learned that registering gets its project stopped. No control plane fixes that. The security review that arrives after the build creates the shadow population it later fails to find.

Accountability is diffuse in the same data. When an agent produces a harmful outcome, EMA found responsibility “distributed almost evenly across four functions”: the deploying team, a dedicated AI team, central IT and GRC. No function holds more than a third of it. Only 2% admit there’s no clearly defined owner, which means 98% believe someone is accountable and nobody in particular is. An inventory row without a name in the owner column isn’t an inventory row.

The inventory has to include the dead

EMA’s finding I’d put on the wall: 30% of agentic pilots have been paused indefinitely or formally discontinued, and another 12.4% were abandoned and restarted from scratch. In EMA’s words, these “were real deployments, provisioned with credentials, granted access to production systems, and integrated into operational workflows. When those pilots were discontinued, many were not cleaned up.” The report’s third conclusion is that “decommissioning is a security event, not a project closure task.”

A control plane registers an agent at birth. Nothing in “discover and register” fires at death. A pilot that ended in a status meeting but not in the identity provider is shadow AI that used to be sanctioned, and it’s the worst kind, because it appears in last year’s inventory as governed. This is the lifecycle problem: retirement has no trigger unless someone writes one. The inventory has to carry a status column, and “retired” has to mean the credential is revoked, not that the Jira epic is closed.

Why inventory is hard, and why it’s the whole job

It’s hard because AI usage doesn’t look like software procurement. There’s no purchase order, no install, no server to find. It’s a browser session and an API key, adopted bottom-up, faster than any governance process built for quarterly software reviews.

So the first real governance work isn’t writing rules. It’s the same move as in every domain I work in: make the thing legible before you try to control it. Discover what’s actually in use, sanctioned or not. Map what each system can reach, not what it’s supposed to reach. Put a name on every one of them.

What the working version looks like

Not a fourth dashboard. A register the enterprise owns, in a table the enterprise controls, with the control planes feeding it rather than replacing it. One row per agent: owner, systems it can reach, credential and where it lives, permitted actions and limits, kill path, logging status, lifecycle status including retired. Populated from three feeds, and none of them is an AI product.

Identity first. Every service account and API key issued to something that isn’t a person. In most companies this is the most complete list of agents that exists, because every agent needs a credential and credentials get issued somewhere. Okta’s directory is one such feed; so is the cloud IAM console, so is the model provider’s key page. A key with no owner in its metadata is a shadow agent by definition. The tell I look for is a service account created fourteen months ago, last used yesterday, with no ticket attached to it.

Money second. The inference invoice. Model providers and cloud accounts bill by project or key, and if someone is paying for tokens, something is running. Reconcile the bill against the register every month. The line items nobody can explain are the inventory gap, priced. Companies that never wired the AI meter to an owner discover this feed is the one that finally finds the agent finance has been paying for since spring.

Platform discovery third. The control planes, all 3.1 of them, exported into the same register, with the register as the system of record and each platform’s list as an input to reconcile against. The moment two platforms disagree about whether an agent exists, you’ve found something.

Then containment, which is architecture rather than a memo. Scope each agent to the minimum data and actions its job needs; a drafting assistant doesn’t need write access to production. Route enterprise data access through a governed layer instead of letting every agent hold its own keys to every system. That is what an internal MCP server is for: governed, audited, permission-scoped access to enterprise data, so “what can the AI reach” becomes one enforced contract instead of dozens of scattered credentials. I’ve built this layer. It’s the difference between agents inside a fence and agents on the honour system. And every agent that can act needs a way to be stopped and a record of what it did. EMA found 46% of organisations can’t easily produce a complete audit trail of an agent’s last 30 days. If you can’t halt it and can’t reconstruct it, you don’t have an agent under management. You have a liability that happens to be useful today.

Notice none of this starts with the model. Governance, like everything else in this practice, is a process-and-integration problem. The model is the last and smallest part.

The operator read

The organisations that handle AI risk well won’t be the ones with the strictest policies. Strict policies on an unknown surface are confident ignorance. They’ll be the ones that treated governance as an inventory-and-architecture problem: one register they own, fed by identity, money and discovery, with a name on every row and a status that includes dead.

Write the policy too. Write it second, after you can see what it’s governing. The vendors have productised the half of discovery that was never hard. The other half has a subject and a verb: someone, registering, because they have a reason to.