The Shadow AI Governance Gap

Key takeaways

• The shadow AI governance gap is the distance between where your policy looks for AI and where AI actually runs. It is not a tooling problem. It is a definition problem.
• Shadow AI is at least five different things: public GenAI apps, enterprise copilots, low-code agents, custom-built agents, and local agents. A secure browser will never see a Bedrock agent, so no single tool covers all five.
• In a live Cyera webinar poll (August 2026), only 14% of attendees said they can see every AI app and agent in use. About 60% cannot see even half.
• Most shadow AI questions are not AI questions. They are data and identity questions: what sensitive data can this thing reach, acting as whom, and what is it doing with it?
• Where to start: inventory before policy, classify the data before the AI, and pick controls per surface, not one tool for everything.

Your shadow AI policy was probably written in 2023. Back then, shadow AI meant employees pasting text into ChatGPT, so you blocked a few domains, bought an enterprise license, and added a paragraph to the acceptable-use document. For that problem, it worked.

The problem moved. You now have a copilot inside your productivity suite with your users' full permissions, agents that business users assembled in Copilot Studio over a lunch break, agents your developers wired to internal systems on Bedrock or Azure AI Foundry, and coding assistants on laptops with access to local files and credentials. Almost none of it passes through the proxy your 2023 policy was built around. You are looking exactly where the policy told you to look. The AI is somewhere else.

That is the shadow AI governance gap, and it is not a tooling problem. It is a definition problem: you are treating five different things as one.

The 5 types of shadow AI

Most governance programs fail at the first step because they define shadow AI as "employees using unapproved chatbots." That was true in early 2023. It is now the smallest and easiest part of the problem. The actual surface breaks down roughly like this.

1. Public GenAI apps used by employees. ChatGPT, Claude, Gemini, Perplexity, and a long tail of niche tools for slides, code, transcription, and image generation. Mostly reached through the browser, often on personal accounts, which means no enterprise data retention terms apply. This is the category everyone already has a policy for, and the category that policy covers least.

2. Enterprise copilots and chatbots. Microsoft 365 Copilot, Gemini for Workspace, Glean, the assistant bundled into your CRM. These are sanctioned, which is exactly the problem. They inherit the user's full entitlements, and most organizations have years of over-permissioned SharePoint sites, shared drives, and "Everyone" groups. A copilot does not create oversharing. It makes oversharing searchable in natural language.

3. Low-code and platform agents. Copilot Studio, Agentforce, Workato, and similar builders where a business user can wire an agent to a document library or a CRM object in an afternoon. No ticket gets filed because nothing was "deployed" in the sense IT recognizes. These agents run under service identities or delegated user permissions, and they persist long after the person who built them has moved on.

4. Custom-built agents on model platforms. Bedrock, Azure AI Foundry, Vertex, Snowflake Cortex, or a self-hosted framework. Built by developers, connected to internal data and internal tools through APIs and increasingly through MCP servers. These are the most powerful and the least visible, because they live in cloud accounts the security team monitors for infrastructure risk, not for AI behavior.

5. Local and desktop agents. Coding assistants, desktop automation agents, and browser agents running on employee endpoints with access to local files, cached credentials, and whatever the user can reach. The endpoint is where "the AI" and "the human" become hardest to tell apart.

Each of these shows up in a different place. A secure browser will never see a Bedrock agent. A CASB will never see a Copilot Studio flow. A cloud API log will never see a prompt typed into a personal ChatGPT tab on a phone. The governance gap persists because most programs pick one of these surfaces, instrument it well, and declare the problem solved.

How to get full visibility into shadow AI: 7 questions to answer

In August, I delivered a webinar together with my friend Zain Malik, Director of Product Marketing at Cyera, on the topic of how to become agent ready with Cyera. In it, we ran a live poll with one question: how much visibility do you have into the AI apps and agents running in your organization? Only 14.29% said they can see everything in use, which is either very impressive or the most confident group of people we have ever polled.

Set aside the optimists. About 60% of the room, by their own account, cannot see even half of the AI in their environment, and the single largest group describes their visibility as limited. That is not a tooling gap you close by adding one more dashboard. It is a definitional gap: most teams have not yet decided what "seeing an AI asset" should mean.

For every AI application or agent in the environment, you should be able to say:

1. That it exists, and what kind of thing it is. A SaaS app, an embedded copilot, a platform agent, a custom agent, a local tool. Sanctioned or not.
2. Who is behind it. The user, team, or developer who introduced it, and whether they are using a personal or a corporate account. That single distinction changes the data retention terms, the legal exposure, and the response.
3. What identity it runs as. A human's delegated permissions, a service principal, an API key, an OAuth grant. Agents act through non-human identities, and most organizations have no owner of record for either the agent or the identities it uses.
4. What data it can reach, and what data it actually touches. These are two different numbers and the gap between them is the risk. A human touches a small fraction of what they are entitled to over a career. An agent will use all of it the first time a task requires it.
5. What tools it can call. Read-only search is one risk profile. Send email, write to a database, post to a webhook, execute code is another. Tool access defines the blast radius.
6. Where its output goes. Back to the user, into a document, out to a third-party API, into another agent. The last one matters more every month.
7. What it was built to do versus what it is doing. Declared intent against observed behavior. An agent approved to summarize support tickets that starts querying the HR system has drifted, whether through misconfiguration, prompt injection, or a well-meaning developer adding "just one more connector."

Items four, five, and six together are the ones to lose sleep over. Simon Willison, who coined the term "prompt injection," named the combination the "lethal trifecta" in June 2025: an agent with access to sensitive data, exposure to untrusted content, and a channel to send data out. In September 2025 a researcher hid white-text instructions in a PDF, uploaded it to Notion's AI agent, and watched it pull a client list and push it out through its own web search tool. Nobody clicked anything. Your inventory should be able to tell you which of your agents have all three legs today, and which are one connector away.

Notice that most of these questions are not AI questions. They are data and identity questions wearing an AI costume. That is the most useful reframe available to a security team right now, and it is the reason shadow AI governance cannot be bolted on as a separate program.

You cannot govern AI without governing data and identity first

Two things have to be true before any of the inventory above means anything. 

The data has to be classified because "this agent can read 14 S3 buckets and a SharePoint site" is not a risk statement, while "this agent can read every customer record you hold" is. Without data classification, every AI asset looks roughly the same and triage runs on gut feel; with it, the inventory sorts itself, and the same semantic understanding of what data is has to apply at rest, in motion, and inside the prompt, or you end up with three inventories that cannot be reconciled.  

In addition to the data. The identity has to be mapped as well, because every AI asset acts as someone or something, and the identity is what determines access. If an agent runs under a service account with standing read access to the finance warehouse, the agent's own guardrails are secondary; the access was the problem before the agent arrived. Put together, the governing question for every AI asset becomes simple: what sensitive data can this thing reach, acting as whom, and what is it actually doing with it? Answer that and most of the policy writes itself.

How to close the shadow AI governance gap.

Three principles, in order.

Inventory before policy. You cannot write a sensible AI acceptable-use policy for agents you have not found, and the policy you write for the chatbots you have found will not cover the agents.

Classify the data before the AI. The risk of any AI asset is the risk of the data behind it. Classification is what turns a list into a priority queue.

Pick controls per surface, not one tool for everything. Each of the five categories lives somewhere different, so each needs a sensor that lives there too. A browser extension cannot see a Bedrock agent, and an inference log cannot see a paste into a personal ChatGPT tab. What should be shared is the data and identity context underneath, not the chokepoint.

Shadow AI is not going to get smaller. Gartner expects up to 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025. The people building them are not waiting for security to catch up. The teams that close the governance gap will be the ones who stop treating AI as a new thing to secure and start treating it as the newest consumer of the data and identities they were already responsible for.

Cyera Agent Guardian finds every agent you have, wherever it runs, keeps each one doing the job it was built for, and stops agents from reaching data they should not. Visit the Agent Guardian page or book a personalized demo to see it in your environment.