Here is the uncomfortable part: you do not have a shadow AI problem in the future tense. You have one right now. The marketing team is pasting customer lists into a consumer chatbot to draft a campaign. An engineer is letting a code assistant you never licensed autocomplete against your private repo. Someone in finance has a browser extension summarizing board decks. None of it shows up in your asset inventory, and almost none of it went through procurement.
This is not a fringe behavior anymore. Survey data from across 2025 and into 2026 consistently puts unsanctioned AI use at the overwhelming majority of organizations, with a large share of employees reaching these tools through personal accounts or personal devices specifically so IT does not see it. The reported numbers vary by who is counting and how, but every credible source lands in the same place: this is mainstream, it is happening on your network today, and the people doing it mostly do not think they are doing anything wrong. They are trying to get work done faster. That is the whole problem and the whole opportunity.
Why "ban it" is a fantasy
The instinct of a lot of security leaders is to block the domains and move on. It does not work, and it has never worked for any shadow IT category. When IBM and others studied unsanctioned cloud apps a decade ago, the lesson was that blocking pushes usage underground rather than eliminating it. Shadow AI is worse, because the tools are more useful, more personal, and a browser tab away. Block the corporate-network path and people move to their phone. You have not reduced the data exposure; you have just blinded yourself to it.
There is also a real cost to getting this wrong. Reporting on AI-related breaches in 2025 found that organizations hit by them overwhelmingly lacked formal AI governance and proper access management, and breach-cost analyses have begun attributing a measurable premium to incidents involving shadow AI. I will not quote a precise dollar figure as gospel here because the estimates differ wildly between vendors, but the direction is not in dispute: ungoverned AI use makes breaches more expensive and harder to scope, because you cannot answer the first question an incident responder asks, which is "what data went where."
Discovery comes before governance
You cannot govern what you cannot see, so the work starts with discovery, not policy. There are three practical signals, and you want all of them:
- Network and egress telemetry. Your secure web gateway, firewall, or enterprise browser already sees DNS and TLS connections to AI endpoints. This is the cheapest place to start. It tells you which services are in use and roughly how heavily, even if it cannot see payloads.
- Identity and OAuth grants. A surprising amount of shadow AI enters through OAuth. An employee grants a third-party AI app read access to their mailbox, drive, or calendar, and now an unvetted vendor has a standing token into your data. Auditing OAuth grants in your identity provider surfaces tools that never touched your network perimeter at all, and it doubles as a hunt for token-theft exposure.
- Endpoint and browser visibility. Extensions, desktop assistants, and IDE plugins live on the endpoint. This is also where you catch the category people forget: AI baked into tools you already approved, quietly turned on by a vendor update.
The output of discovery should be a living inventory, not a one-time report. New AI features ship weekly inside SaaS you already pay for, so a point-in-time scan is stale within a month.
DLP for GenAI is a different animal
Classic data loss prevention was built to stop a file from leaving over email or a USB stick. GenAI breaks the model because the exfiltration channel is a text box, the data is often pasted rather than attached, and the "destination" is a model that may retain or train on whatever it receives. Inspecting an attachment is easy; inspecting a 4,000-word prompt that happens to contain a customer record in the middle is not.
The teams getting this right are moving the control point closer to the interaction. That means inline inspection of prompts at the browser or gateway layer, classification of what is being sent rather than just where it is going, and policies expressed in terms of data sensitivity, not domain names. The goal is not to block the marketer from using AI. It is to stop the specific paste that contains regulated data, and ideally to tell them why in the moment, so they learn the boundary instead of resenting it.
Vibe coding is shadow AI with commit access
The developer slice of this deserves its own section, because it carries a sharper edge. "Vibe coding," letting an AI assistant generate large chunks of an application from natural-language prompts, has gone from novelty to daily practice. A meaningful share of developers admit to using code assistants their employer never sanctioned. The risks stack up fast: proprietary code pasted into a third-party context, AI-suggested dependencies that do not exist or that an attacker has pre-registered to exploit hallucinated package names, and subtle vulnerabilities introduced by code nobody fully read before merging.
The supply-chain angle is the one I would lose sleep over. When an assistant confidently suggests a package, developers tend to trust it, and that trust is the attack surface. If you are not capturing an accurate bill of materials for what actually ships, including the AI-generated and AI-suggested components, you are governing the parts of your software you can see and ignoring the parts you cannot.
The agentic turn raises the stakes
The 2026 conference circuit, RSAC in the spring and the European shows through the summer, has converged on a blunt framing: AI agents are the new shadow IT. The reason is that an agent does not just read your data, it acts. It holds credentials, calls tools, and chains steps without a human approving each one. An unsanctioned chatbot is a data-exposure risk. An unsanctioned agent with an OAuth token and tool access is a data-exfiltration and unauthorized-action risk, operating outside any approval workflow.
There is real regulatory pressure arriving alongside this. The EU AI Act's general-purpose AI obligations and the activation of the AI Office's enforcement powers land on August 2, 2026, while standalone high-risk obligations were pushed later under the 2026 Digital Omnibus revisions. The exact dates have moved and may move again, so treat any single deadline as provisional and confirm against the current text. The durable point is that "we did not know our employees were using it" is rapidly ceasing to be a defensible answer to a regulator or an auditor.
What actually works
The pattern that holds up is boring and effective: discover continuously, govern by data sensitivity rather than by ban, and give people a sanctioned alternative that is genuinely good. Shadow AI thrives in the gap between what people need and what you officially offer. Close that gap with an approved tool, clear and short guidance on what data is fair game, and inline nudges instead of silent blocks, and the underground usage shrinks on its own because there is no longer a reason for it.
How Safeguard Helps
Safeguard treats shadow AI as a supply-chain and governance problem, not a game of domain blocking. We help you build a live inventory of the AI tools, agents, and AI-suggested components in use, including an AIBOM that captures what your developers are actually shipping, and we enforce that inventory through policy gates and a vendor policy registry so unvetted tools and tokens surface before they become incidents. Because our verification and orchestration layer sits above any single model, you can govern bring-your-own-model usage without betting the program on one vendor. If you want to see what shadow AI looks like in your own environment, reach out and we will walk through a discovery exercise with you.