You Can't Govern AI Tools You Don't Know About

Shadow AI is AI usage that bypasses your organization's provisioning process. Mundane, productive, and completely invisible to your security team. An employee signed up for a writing assistant with their personal email, pasted client data into it, and finished a deliverable in four minutes that would have taken forty. The tool never touched your identity provider, never appeared in your app catalog, never generated a log entry you could query. It was never assigned to a user, never scoped to a role, never subjected to a terms-of-service review. From a governance standpoint, it doesn't exist.

The reason this is the first lesson in this section is simple: you cannot write policy for tools you don't know about, attribute data exposure to workflows you can't see, or assess risk on integrations that never hit your identity stack. Shadow AI is the gap underneath every other enterprise AI governance problem. Access control, role-based permissions, audit trails. All of it depends on closing this gap first.

• Definition: Shadow AI is AI adopted by employees outside organizational provisioning and oversight. It is, first, a visibility failure, and it is the precondition for every other AI governance problem.

The numbers, with appropriate caveats

IBM's 2025 Cost of a Data Breach Report, researched by Ponemon Institute across 600 organizations in 16 countries and regions, puts a dollar figure on the problem. Among organizations that experienced a breach, 20% attributed the incident to shadow AI. Organizations with high levels of shadow AI paid a $670K cost premium over those with low or no shadow AI.

Hold those numbers precisely. The $670K is a comparative premium, not a per-incident cost. It's the delta between high-shadow-AI organizations and low-shadow-AI organizations when both get breached. And the 20% is self-reported by the breached organizations, not independently verified through forensic attribution. IBM's methodology section notes the sampling frame skews toward organizations with more mature security programs, which means the real picture at less mature organizations could be worse. These are the best numbers available. They measure what organizations believe caused their breach, not what an investigator proved. That distinction matters when you're citing them in a conversation.

On the adoption side, IDC's 2025 survey found 56% of employees use unauthorized AI tools while only 23% use what IT provides. The methodology on that survey is less transparent than IBM's, but the ratio is consistent with what practitioners report. The gap between sanctioned and unsanctioned AI usage is structural. It's load-bearing. It holds up the entire shadow AI problem.

The productivity delta explains why. An employee who can generate a first draft, summarize a 40-page RFP, or reformat a dataset in minutes will not wait for IT to finish a security review that takes weeks. Bans don't fix this. The approved alternative either doesn't exist, takes too long to provision, or can't do what the unsanctioned tool does. And even when organizations try to enforce bans, most lack the infrastructure to do it: sixty-three percent of breached organizations in IBM's study either lacked an AI governance policy entirely or were still developing one. Of those with policies, only 34% performed regular audits for unsanctioned AI. A ban creates a compliance problem layered on top of the visibility problem. Now you have two problems and the employee still has their personal ChatGPT tab open.

The pattern is familiar to anyone who lived through early SaaS sprawl: the tools arrive before the governance does, and the governance arrives before the discovery mechanism does.

• Scale: IBM's 2025 data shows a $670K breach cost premium tied to shadow AI, with 20% of breached organizations attributing their incident to it. Bans fail because the productivity gains are too high and most organizations don't have the governance infrastructure to enforce them anyway.

Three tiers and a request form

The practical alternative to a ban is a classification framework. The model most governance teams converge on uses three tiers: approved, limited, and prohibited.

Worth being precise about provenance here: no standards body published this taxonomy. You won't find it in NIST AI RMF or any OMB memo. It's practitioner-convergent convention. Enough CISOs and governance teams arrived at the same structure independently that it became the default. Multiple CISO-facing governance guides use it with minor naming variations. If your buyer asks where this framework comes from, the honest answer is "everywhere and nowhere." It's how practitioners implement the governance that the policy memos require without prescribing.

Approved tools are fully provisioned. They've passed security review, their data handling terms are acceptable, they're integrated into the organization's identity and access management stack. Employees can use them with work data.

Limited tools are conditionally permitted. Approved for non-sensitive use cases, prohibited for anything involving PII, export-controlled data, or client information. The restrictions are specific and documented. "You can use this for brainstorming. You cannot paste contract language into it."

Prohibited tools are explicitly banned, with the ban tied to a specific reason: unacceptable data retention terms, no SOC 2, jurisdiction issues. Naming the reason matters. It tells employees what would need to change for the tool to move tiers, and it tells the vendor what's blocking the sale.

The mechanism that makes classification operational is the request-to-allowlist lifecycle. An employee encounters an AI tool they want to use. They submit a request. Security reviews the tool's data practices, terms of service, integration requirements, and risk profile. The tool gets classified into a tier. If approved, it gets provisioned through the identity stack. If limited, the restrictions get documented and communicated. If prohibited, the employee gets told why and, critically, pointed toward an approved alternative that covers the use case. Without that last step, you're back to the ban problem. And if the lifecycle itself takes three weeks while the employee needs an answer Tuesday, you've just created a different path to the same shadow AI outcome. The governance mechanism has to be fast enough to compete with the ungoverned alternative.

The list is living. Tools move between tiers as their capabilities, terms, and risk profiles change. A tool that was limited because it lacked SSO support moves to approved when the vendor ships it. A tool that was approved moves to prohibited when it changes its data retention policy. Classification is a snapshot. It decays the moment the vendor pushes a new ToS update.

The three-tier model only works for tools you know about, though. Every tool employees adopt outside the request process sits in a fourth, unnamed category: unknown. Unknown is worse than prohibited, because prohibited at least means someone evaluated the risk and made a decision. Unknown means nobody knows there's a decision to make.

• Classification: The approved/limited/prohibited model is practitioner convention, not standards-body doctrine. It only governs tools that enter the request-to-allowlist lifecycle. Tools adopted outside the process remain unclassified, which is the worst tier.

The conversation you're walking into

Federal agencies are already deep in this problem, and the way they frame it is useful even if your account isn't federal. The core of it is a discovery problem, and discovery is where identity enters.

Under M-25-21, executive agencies must maintain and publicly release annual AI use case inventories. The 2025 inventory logged 3,611 individually reported use cases across 41 agencies, a nearly 70% increase from the prior year. More than three-quarters of CFO Act agencies reported deploying at least one major AI chatbot to 10,000 or more employees. But the reporting is self-identified. There is no standardized technical mechanism for automated discovery at the federal governance level. The CFPB's compliance plan says the quiet part plainly: its Office of Cybersecurity discovers unauthorized AI use "using the same approach as 'Shadow IT' discovery." Honest, and also an admission that the tooling hasn't caught up.

Individual agencies are building classification frameworks organically, without anyone handing them the model. The VA has explicitly prohibited all publicly available generative AI services for use with VA-sensitive data, naming ChatGPT, Gemini, and Claude specifically, while offering employees a single approved internal alternative. The Federal Reserve maintains a list of approved models and libraries and evaluates new requests on an ongoing basis. They arrived at the three-tier structure because the constraints demanded it.

So when you're sitting across from a CAIO or CISO in a public sector account, the ship on "should we use AI" sailed when 75% of major agencies deployed chatbots to tens of thousands of employees. The live questions are: what AI is actually running in your environment, how did it get there, what data can it see, and who decided it could?

Every one of those questions resolves through identity infrastructure. The buyer will frame them as AI governance, AI risk management, inventory compliance. The provisioning and discovery gap runs through all of them. Your job is to hear it. The discovery gap. The classification gap. The fact that their three-tier model, however well-designed, only covers the tools that walked through the front door.

• Practical frame: Federal agencies are building AI use case inventories under M-25-21 with no standardized discovery mechanism, while employees adopt tools faster than governance can classify them. The buyer's AI governance conversation runs on provisioning and discovery infrastructure, and that's where identity enters.