Every enterprise we talk to has an AI inventory problem, and almost none of them know it yet. They have a list of the AI tools they bought. They do not have a list of the AI connections that exist.
Those are very different lists. The first is a procurement record. The second is a security boundary. And in 2026, the gap between them is widening every week, because connecting an AI agent to enterprise data has become something a single developer can do in an afternoon.
How Shadow AI Actually Happens
Shadow IT used to require a credit card and a SaaS signup. Shadow AI requires far less. The Model Context Protocol (MCP) made it simple to give an AI assistant structured access to a system of record. That is a genuine leap forward for productivity. It is also a new class of integration that most governance programs were never designed to see.
In our own testing, documented in Two Ways In, we found that ServiceNow's AI Control Tower automatically inventories MCP servers built on the platform's native console, but a fully authenticated external MCP server does not appear anywhere in that inventory. That is not a ServiceNow failure. It is a structural reality: governance tools can only see what is built inside the walls they watch.
Now multiply that across every platform in your estate. A developer wires an assistant into the ticketing system. A vendor stands up a connector during a proof of concept and never tears it down. A business analyst follows a tutorial and connects a local agent to a reporting database with a service account. Each connection is small. Together they form an attack surface nobody drew.
The riskiest AI in your enterprise is not the model you evaluated. It is the connection nobody registered.
Why Traditional Controls Miss It
- It looks like normal API traffic. An agent calling a REST endpoint with a valid OAuth token is indistinguishable from any other integration unless you know to look for it.
- It uses legitimate credentials. Most shadow agents are not breaches. They authenticate properly, often with a service account whose permissions were scoped for something else.
- It lives outside the platform. External servers run on laptops, containers, or vendor infrastructure. Your CMDB was not told they exist.
- It changes quickly. An agent's tool list can grow from read-only to read-write in a single commit, with no change request attached.
What a Real AI Inventory Includes
An AI inventory worth having answers four questions for every connection, not just every product:
- What is connected? The agent or server, where it runs, and who owns it by name.
- What can it touch? The explicit list of tables, endpoints, and operations, with read and write separated.
- As whom does it act? Does it inherit the end user's permissions, or does it run as a shared service account? This single answer determines most of your risk.
- Who approved it, and when? A record of the decision, tied to a review, not an assumption.
Four Moves to Make This Quarter
1. Hunt from the credential side. You cannot inventory what you cannot see, but you can inventory who holds credentials. Review OAuth clients, API keys, and integration users on your core platforms. Every one without a named owner and a documented purpose is a candidate shadow connection.
2. Make the governed path the easy path. Developers route around governance when it is slow. If registering an agent takes three weeks and building one takes three hours, you will lose. Publish a lightweight intake that takes minutes and gives developers something back, like pre-approved credentials and a reviewed template.
3. Prefer patterns the platform can see. Where a native, inventoried integration path exists, make it the default. Reserve external patterns for cases that genuinely need them, and require a named owner and a code-level allowlist for each.
4. Put vendors on the hook. Add a clause to every statement of work: any AI connection a vendor creates against your environment must be registered, documented, and removed at engagement close. Ask your current vendors today what they have already connected.
The Governance Conversation Has Changed
Two years ago, AI governance meant model evaluation, bias testing, and acceptable use policies. Those still matter. But the frontier has moved from what a model says to what an agent does. Agents read records, create tickets, update fields, and trigger workflows. Governing that requires the same discipline enterprises already apply to integrations and privileged access, applied to a new kind of actor.
The organizations that get this right will not be the ones that ban agents. They will be the ones that can answer, at any moment, exactly which agents are connected, what they can do, and who said yes.
Nya Akoma. Take Heart.