Volly
← Articles

Shadow AI Apps: The New Shadow IT Problem

Shadow IT used to mean an unsanctioned SaaS subscription on someone's expense report. The AI-build era version is worse, because now anyone can stand up a tool that touches real company data in an afternoon.

Shadow IT has a twenty-year history by now. Someone in marketing signs up for a project management tool with a company card because procurement takes six weeks, and six months later there's customer data sitting in a SaaS product nobody in security has ever heard of. IT teams built entire practices around finding and closing these gaps: expense report audits, SSO enforcement, network-level SaaS discovery tools.

The AI-build era version of this problem is worse, and most security teams haven't clocked it yet.

The old shadow IT problem required someone to sign up for an existing product. The new one doesn't require a product to exist at all. Give a nontechnical employee a Claude or ChatGPT seat, and they can build a working internal tool from scratch, one that queries a real database, calls a real API, and renders a page other people can open. No procurement step. No vendor security review, because there's no vendor. Just a person with a good idea and an afternoon.

Where this actually breaks

The failure mode isn't "the code is bad." Claude and Codex write reasonable code. The failure mode is that nobody thought about what happens after the tool works, because "after it works" was never part of the prompt.

Three things tend to go wrong, and they compound:

  • The tool ends up on a public URL with no login. Free hosting is fast and doesn't ask questions, so it's the default choice. That means anyone with the link, not just anyone at the company but anyone on the internet, can open it.
  • It reads from a real data source using credentials that were never meant to leave someone's laptop. A personal API key, a database connection string copied out of a .env file, pasted straight into a tool that's now sitting on the open web.
  • It ignores whatever access control the source data was supposed to have. Your CRM has role-based permissions for a reason, maybe sales reps see their own accounts and managers see the whole team. A tool built against that CRM's API in an afternoon usually doesn't replicate any of that. Everyone who opens the link sees everything.

None of this is because the builder did anything wrong. They solved the problem they had, a slow, manual workflow, using the tools available to them. Nobody gave them a secure alternative, so they used the one that worked.

The fix isn't "ban it"

Blocking Claude and ChatGPT access for nonengineers just pushes this back underground, and it throws away real productivity in the process — some of these homegrown tools are genuinely good, and the org loses them along with the risky ones. The fix is giving people a place to publish that handles the parts they were never going to think about: a login screen behind your company's existing SSO, granular access control instead of "public link," and a gateway that lets an app query real data without ever handing it a raw credential.

That's the actual shape of the governance gap right now. Not "who's allowed to use AI to build things," that ship has sailed, and everyone in the industry knows it. It's "where do the things they build actually live." Answer that, and shadow AI stops being shadow.