Your Enterprise AI Inventory Is Three Times Your Model List

The thesis fits in a multiplication: whatever list of models your company believes it is using, its real AI surface is roughly three times larger. Help Net Security published it on 5 August in this analysis of the enterprise AI footprint, and the ratio matches what we find every time we audit an environment.

The reason is not that models are hidden in a closet. It is that almost nobody counts what surrounds the model, and that is where the real risk lives.

What falls outside the inventory

SaaS with AI enabled by default: the CRM, the ATS, the office suite and the support tool added assistants in updates nobody read.
MCP servers: each one is a data access path running with the permissions of the user who launched it, not those of an audited service account.
Assistants inside the IDE and browser extensions, installed by individual decision, with access to repositories and already authenticated sessions.
API keys scattered across environment variables, local configuration files and some .env that ended up inside a backup.
Internal agents someone built for one specific task, still running, never reviewed again.

None of those elements shows up when someone answers the question of which models we use. All of them show up when the question is where our data can leave through.

The distinction matters because controls apply to connections, not to models. Blocking a vendor achieves nothing if the same capability comes in through a browser extension or through a feature the CRM maker switched on in its latest release.

The inventory that actually works

Counting models is counting vendors. The useful inventory is built by connections and it is a fairly mechanical exercise:

Locate MCP configuration files on machines and in repositories: claude_desktop_config.json and .mcp.json are a good starting point.
List the hooks configured in Claude Code. They are shell commands that run on their own on lifecycle events, so they are code with permissions, not harmless configuration.
Review which OAuth integrations users have authorized against AI tools, from the Google Workspace or Microsoft 365 console.
Ask every SaaS vendor for the list of AI features active in your tenant and in which region the data is processed.
Cross check the spend: API invoices reveal projects that appear in no inventory.

Why it matters now

Because both the European regulatory framework and the certification schemes companies are adopting start from the same boring requirement: knowing which AI systems you use, for what and with which data. Without an inventory there is no risk assessment, and without a risk assessment the compliance documentation is fiction.

There is a second reason, less formal. The cost of an incident with an agent does not resemble a classic leak, because the agent does not only read: it acts. An MCP server with write permissions over a production system is, in practical terms, one more user with permanent access, no password expiry and nobody watching its activity.

Who this is useful for

For security leads who need a measurable figure to open the conversation in a committee. For small IT teams, who usually discover half of these connections the day one of them fails. And for anyone about to sign an AI usage policy: writing rules on top of an incomplete map produces apparent compliance, which is worse than having no policy.

In the integrations we build, the number of connections always surprises more than the number of models: a handful of vendors and dozens of contact points is a common split. If there is room for only one thing this quarter, do the count before the rulebook.