Right now, somewhere in your company, someone's probably pasting a chunk of source code, or maybe a client contract, or a spreadsheet full of customer data, into some chatbot that IT has literally never heard of. Not because they're trying to cause trouble. Usually it's the opposite — they just want to get the thing done before lunch, and waiting three days for a ticket to clear isn't going to help with that.
That small, well-meaning habit has a name now: Shadow AI. And honestly, it's turning into one of the messier security problems companies have dealt with in a while — not because people are being reckless, but because none of these tools were ever designed with a security team's blind spots in mind. They were designed to be fast and frictionless. That's basically the whole pitch.
Okay, But What Is It, Exactly
You've probably heard of Shadow IT — someone signing up for a personal Dropbox account, or a team quietly buying a SaaS tool without telling procurement. Annoying, but mostly a visibility problem. The data just sits somewhere IT doesn't know to look.
Shadow AI is a bit different, and honestly a bit weirder. These tools don't just store your data — they read it, chew on it, generate something new out of it, and in a lot of cases ship it off to a third-party model provider's servers in the process. And the category is way bigger than "someone has ChatGPT open in a tab." It covers coding assistants running on personal accounts, random AI browser extensions, writing tools, open-source models someone's running locally on a work laptop, AI features that quietly switch themselves on inside SaaS platforms nobody actively opted into, and — increasingly — little automated agents employees build to read documents or query a database with basically no one checking the output.
If it's touching company data and security didn't sign off on it, it counts.
The Gap Here Is Kind of Wild
The numbers are a little uncomfortable to sit with, honestly. Something like two-thirds of employees are already using AI tools at work in some capacity. Meanwhile, roughly one in five companies has an actual policy governing how that's supposed to happen. That's not a small gap — that's most of the workforce improvising.
Part of why this keeps happening isn't really about people being careless. It's structural. By the time a security team finishes evaluating this year's crop of AI tools and writes a policy around it, a newer batch has already spread through half the company. Policy is always playing catch-up with something that already happened.
There's a slightly ironic detail buried in the data too: when companies actually hand employees a decent, sanctioned AI tool, unauthorized use tends to fall off a cliff — some reports put the drop close to 90%. Which tells you something. And it's not like people are doing this because they get some thrill out of going around security. Most of them are doing it because the approved option is either missing entirely or just bad — and they've still got a job to finish by five.
Why It's So Hard to Actually Catch
This is the part that should bother security people more than the compliance angle does — most of the tooling built to catch this stuff literally cannot see it.
Nearly every AI platform runs over regular encrypted web traffic. Unless a company has SSL inspection deployed (and a lot of them haven't, for reasonable reasons — overhead, privacy, the usual tradeoffs), a request to an AI provider's API looks exactly like a request to any other website from the network's perspective. It's not that the monitoring failed. It was never built to tell "employee having a conversation with a model" apart from "employee loading a page."
Now add autonomous agents into the mix and it gets worse. Newer protocols that let AI agents call external tools and actually do things — read files, hit APIs, run commands — open up a genuinely new kind of exposure. If one of those connections isn't locked down properly, you're not just risking a leaked document anymore. You're potentially giving an unsupervised process the ability to act inside your own systems.
This Has Already Happened. More Than Once.
A few real examples make the shape of this problem a lot clearer than any stat does.
Back in 2023, engineers at a major electronics company were trying to debug some code faster and pasted proprietary source material and internal meeting notes into a public chatbot — three separate times, within a few weeks of each other. Once that information left the building there was no calling it back. The company ended up banning generative AI on corporate devices entirely.
Then there's the cloud infrastructure provider — and this one had nothing to do with anyone pasting text anywhere. Just an employee logging into some AI browser extension nobody had vetted, using their normal work credentials. That was it. That one login became the door attackers walked through to get into internal systems, grab customer configuration data, and try to extort a few million dollars out of the company.
And earlier this year, researchers found an app that had been rapidly built with AI development tools and shipped with a basic access control switched off — quietly exposing more than a million API keys and tens of thousands of user records to anyone who stumbled onto it. Again — nobody meant for that to happen. The tooling just made it fast enough to skip the review step that would normally have caught it.
Look at all three side by side and none of it screams malice, none of it screams incompetence either. It's just... nobody had a policy, nobody had visibility, and there was nothing sitting there ready to catch it before the data had already walked out the door.
And It's Not Cheap, Either
When a breach does trace back to shadow AI, it tends to cost more and take longer to notice than a typical incident — we're talking several hundred thousand dollars more on average, and a longer detection window, mostly because the activity blends into ordinary traffic so well that nothing ever trips an alarm. Sensitive stuff — the customer records, the source code, the health data — shows up disproportionately often in these cases, which tracks. That's exactly the kind of information people reach for an AI tool to process faster in the first place.
So What Do You Actually Do About It?
Banning AI outright feels like the obvious move, and it basically never works the way people hope. Take away the sanctioned tool and employees don't stop wanting to use AI — they just quietly switch to personal accounts that are even further off the radar. That's worse for visibility, not better.
What seems to actually help, based on what's out there:
- Give people a genuinely good, approved option. If it's not clunky, they'll actually use it instead of hunting for something else.
- Write policy around what data can never leave the building, instead of trying to blanket-ban whole categories of tools that'll just be replaced by next quarter's version.
- Get real visibility into what's happening — network traffic, browser activity, and especially OAuth/identity grants, since that's increasingly where the actual risk is hiding, not in the chat window.
- Treat autonomous agents as their own category of risk, with sandboxing and narrow permissions instead of quietly giving them broad standing access.
- Don't leave this to IT alone. It touches legal, security, and whichever business unit is doing the adopting — treating it as purely a tech problem is a big part of why it keeps slipping through.
Bottom Line
None of this is really about careless employees or some wave of brilliant attackers. It's about adoption running way ahead of the guardrails anyone bothered to build — a genuinely useful set of tools that quietly turned into one of the biggest unmonitored data channels most companies have ever had, without anyone really deciding that should happen. Companies that get this right won't be the ones slamming the door on every new tool that shows up. They'll be the ones who actually bother to find out how people are using this stuff — and who build a culture where nobody feels like they have to hide it in the first place.