Shadow AI: Your Employees Brought Their Own Models

Somewhere in your company, right now, an employee is pasting customer data into a public chatbot.

They're not a bad person. They're not trying to exfiltrate anything. They've got a deadline, the sanctioned tools are slow or useless, and the chatbot on their phone writes a better summary in ten seconds than the approved software manages in ten minutes. So they paste, they summarize, they move on. Multiply by a few thousand employees and you've got a data governance problem wearing a productivity costume.

This is shadow AI, and it's the return of a very old movie. A decade ago it was shadow IT — employees spinning up cloud accounts on personal credit cards because procurement took six months. Before that it was shadow Dropbox, shadow Gmail, shadow everything. The pattern never changes: official channels are too slow, people route around them, and security finds out a year later during an audit.

The standard corporate response is also unchanged: ban it. Block the domains, write a policy, send a stern email from Legal. And it fails the same way every time, because the ban doesn't remove the need — it just moves the behavior somewhere you can't see it. Employees don't stop using the tools. They stop using them on the corporate network. Congratulations, you've traded a visible risk for an invisible one.

So let's talk about what actually works, starting with the hardest pill: you have to give people something better.

If your sanctioned AI tool is worse than the public one — slower, dumber, wrapped in so many guardrails it can't answer a simple question — nobody will use it, and your policy is fiction. The approved path has to be at least as good as the unapproved one. That's not a security requirement, it's a product requirement, and security teams ignore it at their peril.

Second: data classification that humans can actually follow. Most classification schemes are written by lawyers for auditors, and employees treat them accordingly — as background noise. If your policy says "don't put confidential data in AI tools" but nobody can tell you what counts as confidential without a flowchart, the policy doesn't exist. Three tiers, plain language, examples from real work. That's the whole trick.

Third: make the sanctioned tools the path of least resistance. Enterprise agreements with the major model providers, SSO integration, data processing terms that keep company data out of training sets. When the approved chatbot is one click away and the sketchy one requires a personal account and a VPN dodge, most people take the easy road. Most people aren't adversaries. They're just busy.

Fourth: logging, not surveillance. There's a difference between "we can see which sanctioned tools are being used and what data classes flow through them" and "we read everyone's prompts." The first is governance. The second destroys trust and drives the behavior further underground. You want visibility into the sanctioned path so you can improve it — not a panopticon that teaches employees to hide better.

And here's the part I want the security folks to sit with: the employees doing this are your allies, not your problem. They're showing you exactly where your tooling falls short. Every pasted spreadsheet is a feature request. The person summarizing support tickets with a public chatbot is telling you, for free, what your internal tools should have done two years ago. Treat them like informants, not criminals, and you'll learn more in a month than a year of surveys.

The companies that get this right won't be the ones with the strictest bans. They'll be the ones that looked at the shadow behavior, understood the need behind it, and built the sanctioned version worth using.

You can't ban the tide. You can build a harbor.

The Non-Human Identity Explosion

Here's a number that should make you uncomfortable: in most enterprises, machine identities — service accounts, API keys, workload identities, automation credentials — outnumber human identities by something like fifty to one. Fifty to one.

Now here's the follow-up question: can you name all of yours?

Most organizations can't. They know their employees — HR onboards them, IT offboards them, there's a ticket for everything. But the service account created three years ago for a migration that never got decommissioned? The API key baked into a container image that's been copied across four environments? The automation credential with admin rights that nobody remembers issuing? Those live in the dark, and there are thousands of them.

This is the identity crisis nobody budgeted for. We spent two decades building mature processes for human identity — joiners, movers, leavers; SSO; MFA; quarterly access reviews. And the entire time, the machine population was quietly multiplying in the background, with none of that discipline attached.

The consequences are exactly what you'd expect. Stale credentials with excessive privilege. Keys that never rotate because rotating them might break something and nobody knows what. Service accounts owned by people who left the company two reorgs ago. Every one of these is a standing invitation, and attackers have figured that out — compromising a forgotten service account is quieter than phishing an executive and often more powerful.

I work in key management, so I have opinions about the fix, and the fix is aggressively unglamorous.

First: inventory. You cannot secure what you cannot see. Every non-human identity needs to be discoverable — who created it, what it can access, who owns it now. This is tedious work. Nobody wants to do it. Do it anyway.

Second: least privilege, for real this time. The service account that needs to read from one bucket does not need write access to the whole project. The CI pipeline does not need production admin. We say "least privilege" about human accounts and then hand machines the keys to the kingdom because it's convenient. Stop that.

Third: rotation with an owner and a schedule. A credential that never rotates is a credential waiting to leak. And rotation only works if someone owns the credential — an actual human, with a name, who gets paged when the rotation breaks something. "Owned by the platform team" is not ownership. "Owned by Priya" is ownership.

Fourth: deprovisioning. Machines need offboarding too. When the migration finishes, when the project sunsets, when the vendor contract ends — the identities go with them. Build the offboarding into the project plan, not as an afterthought six months later when someone finally asks "what is this account for?"

Notice what's not on this list: a shiny new product. The industry would love to sell you an NHI security platform, and some of those tools are genuinely useful for the inventory problem. But no product fixes the underlying disease, which is that organizations treat machine identity as plumbing instead of as identity. The discipline is the product.

There's a deeper point here about how security thinking lags reality. Our mental model of "identity" is still a person with a username, because that's what the last twenty years trained us on. But the population inverted while we weren't looking. The machines are the majority now, and they're the ones with the broad access and the thin oversight.

The good news: this is a solvable problem. It's not a cryptography breakthrough or an AI moonshot. It's inventory, least privilege, rotation, and offboarding — the same boring fundamentals that work everywhere else in security, applied to the population we forgot to count.

Boring is underrated. Boring is what keeps the lights on.