Shadow AI Is in 43% of Breaches — and Most of Your AI Tools Answer to No One
Shadow AI isn't an employee discipline problem — it's a third-party risk and data-governance gap your existing DLP and acceptable-use policies were never built to close. Here's a practical discovery-to-control model for UK SMEs.
A finance assistant at a Midlands manufacturer pastes a supplier contract into a free AI summariser to save twenty minutes. A developer installs a browser extension that promises to explain any code snippet. A sales rep connects their CRM to an AI note-taker they found on a product forum. None of them filed a ticket. None of them broke a rule they knew about. And every one of them just handed company data to a third party nobody in IT has ever assessed.
This is shadow AI, and the numbers have stopped being theoretical. IBM's 2025 breach research found that shadow AI was involved in 43% of breaches at organisations with high levels of unsanctioned AI use — and those breaches cost more and took longer to contain. Separate surveys of enterprise AI usage keep landing on the same uncomfortable figure: roughly 80% of the AI tools employees use day to day are invisible to the people meant to be governing them.
The instinct is to treat this as a behaviour problem. Tighten the acceptable-use policy, send a stern email, run a training module, move on. That instinct is wrong, and it's wrong in a way that will keep costing you. Shadow AI is not primarily about what your staff do. It's about where your data goes — and who you've quietly entered into a data-sharing relationship with.
Why your existing controls miss it
Most UK SMEs already have the two documents that are supposed to cover this: a data loss prevention (DLP) setup and an acceptable-use policy. Both were designed for a different shape of risk, and both have structural blind spots when it comes to generative AI.
Start with DLP. Traditional DLP watches for known patterns — card numbers, national insurance numbers, files labelled confidential — leaving by known channels like email attachments, USB drives, and uploads to a short list of flagged domains. It was built to catch a document moving from inside to outside.
GenAI breaks that model in three ways.
First, the data often doesn't move as a file. An employee types or pastes text directly into a chat box. There's no attachment to inspect, no file hash to match. The sensitive content is in the body of an HTTPS request to a domain your DLP has never heard of.
Second, the channel is the browser. A huge share of AI usage now happens through browser extensions and web apps rather than installed software. Your endpoint agent sees a Chrome process making an encrypted connection. It does not see that a Grammarly-style extension is reading the contents of every text field on the page, including the CRM record open in the next tab.
Third, the destinations multiply faster than any blocklist. New AI tools launch weekly. Even well-known providers spin up new API endpoints and subdomains. A deny-list approach is always a step behind, and an allow-list approach breaks so much legitimate work that people route around it — which is how you got shadow AI in the first place.
Now the acceptable-use policy. The problem there is simpler: a policy is a promise, not a control. "Don't paste confidential data into public AI tools" assumes the employee knows which tools are public, knows what counts as confidential, and remembers the rule in the moment they're under deadline pressure. It also assumes they can tell a legitimate AI assistant from a repackaged one that sends data to a server in a jurisdiction you'd never approve. They can't, because the interfaces look identical.
The part almost nobody is looking at: MCP servers
There's a newer layer that deserves attention because it turns a data-leak risk into an access risk. The Model Context Protocol (MCP) is a standard that lets AI assistants connect directly to tools and data sources — your files, your ticketing system, your database, your internal APIs. It's genuinely useful. It's also a way for an AI agent to be granted standing permissions to systems, often set up by a technical employee without anyone reviewing what the server can reach.
An MCP server configured on a developer's machine might hold credentials to a production system and expose them to whichever AI model the developer happens to be using. If that model is a third-party cloud service, you now have a third party with a live connection into internal infrastructure, mediated by software that was installed in an afternoon. This is no longer about a leaked contract. It's about delegated access you never granted and can't see.
Reframe it as third-party risk, because that's what it is
Here's the mental shift that makes the problem tractable. Every AI tool your staff use is a third-party processor. The moment data flows to it, you're in supplier-relationship territory — the same territory you'd be in if someone signed up for a new SaaS platform without telling you.
You already have instincts for third-party risk. You'd want to know who the vendor is, where they host data, whether they train on your inputs, what their security posture looks like, and whether a Data Processing Agreement exists. Under UK GDPR, if personal data goes into an AI tool, you are the controller and that tool is a processor — and you're obliged to have the right contractual terms and lawful basis in place. A free chatbot with no DPA and a privacy policy that says inputs may be used for training is not a tool. It's an unvetted sub-processor you've accidentally hired.
Once you see it this way, the solution stops being a lecture about behaviour and becomes a programme of discovery and governance.
A tiered discovery-to-control model
This is what works in practice for an SME, built in order.
Tier 1 — Discover. You cannot govern what you can't see. Start by finding out which AI tools are actually in use. This means inspecting outbound traffic for known AI domains and API endpoints, reviewing browser extensions deployed across managed devices, and auditing OAuth grants where staff have connected AI tools to Microsoft 365, Google Workspace, or your CRM. Those OAuth connections are gold: they show you exactly which third parties have standing access and to what. Most SMEs are genuinely shocked by the length of this list.
Tier 2 — Classify. Sort what you find into three buckets. Sanctioned — tools you've assessed and approved, with a DPA and sensible configuration. Tolerated — tools that are low-risk for low-sensitivity work, allowed with guardrails. Blocked — tools that train on your data, have no DPA, or host somewhere you won't accept. The classification should be driven by data sensitivity and vendor posture, not by how popular the tool is.
Tier 3 — Control. Now you apply enforcement that matches the tier. For sanctioned tools, provide a properly licensed, configured version so there's a legitimate option that's easier than the shadow one — this matters, because people use shadow AI when the approved path is slower. For blocked tools, enforce at the network and browser-extension level, not just in a policy document. For MCP servers and agent access, require that any connection into internal systems goes through a review, uses scoped credentials, and is logged.
Tier 4 — Monitor and revisit. New tools appear constantly, so discovery is not a one-off project. Run it on a schedule, and review OAuth grants quarterly to revoke access nobody remembers approving.
Where to start this week
If you do one thing, pull the list of third-party apps with OAuth access to your Microsoft 365 or Google tenant and read it. You'll find AI tools you didn't approve, with permissions you wouldn't have granted. That single audit reframes the whole conversation — from "our staff keep breaking the rules" to "we have a supplier-governance gap, and here's the list."
Shadow AI isn't going away, and banning it outright just pushes it further into the dark. The organisations handling this well aren't the ones with the strictest policies. They're the ones who can see what's connected, know where their data is going, and have made the approved route the easy one. If you'd like help running that first discovery audit across your environment, that's exactly the kind of work we do — and it tends to be a lot less alarming once you can actually see it.