How to Manage Shadow AI in the Workplace (Now That Employees Are Shipping Apps, Not Just Prompts)

You manage shadow AI in the workplace by finding what people have already built, sorting it by how much risk it carries, giving builders safer default tools, and creating a fast path to move the good stuff into IT-owned infrastructure. Banning it does not work. Here's why, and here's the model.

I spent two weeks talking to IT leads and poking at vibe-coded apps myself. The pattern held: this isn't a tooling problem anymore. It's an application problem.

Shadow SaaS was a subscription. Shadow apps are software.

Shadow IT used to mean someone expensed a Trello plan without asking. Then it meant someone pasted company data into ChatGPT. Now it means a finance manager opens Lovable, describes a reimbursement tracker in plain English, and has a working app connected to a real database by lunch.

That's the shift. Seventy-eight percent of AI users at work already bring their own AI tools without IT approval, a habit even more common at small and mid-sized companies at 80 percent.¹ Seventy-five percent of knowledge workers now use AI at work, roughly double the rate from six months earlier, while 60 percent of leaders admit their company has no clear AI plan.¹ Employees are filling that vacuum, and now they're filling it with running software, not just chat sessions.

Vibe coding, building software by describing what you want rather than writing it, is the mechanism.²³ A marketing lead builds a customer tracker. An ops manager wires two systems together with a script an AI wrote. None of it goes through a dev cycle. None of it gets a security review. As Techstrong IT put it, this software "hasn't been properly tested for bugs or security gaps, lacks an explicit architecture, and certainly has no documentation."³

How big is the shadow AI problem, actually?

Bigger than most IT teams think. Gartner has projected that citizen developers will outnumber professional developers inside large enterprises by roughly 4 to 1.⁴ That was a low-code prediction made before generative AI made building even easier, so treat it as a floor, not a ceiling.

Enterprise assessments now find 350 to 430 distinct AI services or features in active use per organization on average, far more than what's on any approved vendor list.⁵ A single point-in-time approval process cannot keep pace with that. It isn't built to.

What goes wrong when employees ship their own AI-built apps?

I wanted to see if the scary numbers held up under scrutiny, so I dug into the two studies behind them. They held up.

Security researcher Dor Zvi and his team at RedAccess scanned 380,000 publicly accessible apps built on Lovable, Replit, Base44, and Netlify.⁶ They found more than 5,000 with virtually no authentication of any kind, and around 40 percent of those exposed apps leaked sensitive data: medical records, financial data, corporate strategy documents, and full chatbot logs containing customer PII.⁶ Zvi's line stuck with me: "Anyone from your company at any moment can generate an app, and this is not going through any development cycle or any security check. People can just start using it in production without asking anyone. And they do."⁶

A separate community scan of 20,052 launch URLs from indie product directories found an 11.04 percent exposure rate on Supabase-backed vibe-coded apps, with 2,325 critical exposures, many of them service_role keys left in client-facing code, the key that bypasses row-level security entirely.⁷ That's not a misconfigured setting. That's the master key sitting in the front yard.

The common thread: none of these apps look broken. They work. That's what makes them dangerous. Nobody audits software that already does the job.

Why banning shadow AI doesn't work

Banning shadow AI treats the symptom. Employees route around slow procurement and unclear AI strategy because the workaround is faster than the sanctioned path, and 65 percent of employees already use at least one AI tool their IT or security team hasn't approved.⁸ Shadow AI usage grew 250 percent between Q1 2023 and Q1 2024.⁸ Over half of employees say they wouldn't even tell their manager AI helped them finish a task.⁸ A ban just pushes the behavior further underground, where you get zero visibility instead of partial visibility. Gartner's own guidance backs this up: CIOs get better outcomes applying "enabling, protective governance" to citizen and AI-assisted builders instead of forcing traditional IT controls onto them.⁹

What does ungoverned AI-built software actually cost?

This isn't hypothetical risk. IBM's 2025 Cost of a Data Breach Report found 13 percent of organizations reported a breach of an AI model or application, and of those, 97 percent had no AI access controls in place at all. Not weak controls. None.¹⁰ Breaches involving high levels of shadow AI added $670,000 to the average breach cost compared to organizations with low or no shadow AI use, and were more likely to expose PII, in 65 percent of cases.¹¹ Sixty-three percent of breached organizations lacked a formal AI governance policy, and only 37 percent had any approval or oversight process running.¹¹ Governance is lagging adoption everywhere, not just at companies that are behind.

A governance model that doesn't kill the vibe

The practical sequence, borrowed from citizen-development governance and shadow-AI practitioners, has four moves. It starts before you write a single policy:

1. Discover. Inventory what's already running. You cannot govern what you cannot see, and most orgs are sitting on hundreds of AI-built tools they don't know about.⁵
2. Classify. Tier every app by what data it touches. A vibe-coded internal poll tool is not the same risk as one holding customer financial records.
3. Guardrail. Give builders sanctioned building blocks, authentication templates, pre-approved databases, secrets management, so the fast, easy path is also the safe one. If a non-engineer's default choice leaks a service_role key, the tooling failed them, not the other way around.⁷
4. Graduate. Build a fast lane, not a checkpoint, that moves validated apps from someone's personal Lovable account into IT-owned infrastructure with proper review, logging, and ownership. This is the step most governance frameworks skip, and it's the one that actually keeps builders on your side.

The security fundamentals for whatever code comes out the other end, review, dependency checks, access control, don't change just because an AI wrote it. Our earlier piece on securing AI-generated code covers the five rules that apply here directly.

Treat the good ones as assets, not liabilities

Here's the reframe that changes how this whole problem feels. A vibe-coded app that actually solves a workflow problem, one that survives three months of real use, is a software asset. Someone spent zero procurement dollars figuring out a real need and building something people use daily. That's valuable. Killing it on sight because it wasn't built the sanctioned way throws away work you'd otherwise pay a vendor to replicate.

The better move is hardening it: put it through a security pass, move its data off someone's personal account, give it an owner, and bring it under the same infrastructure discipline you'd want for anything running production workflows. A team that builds its own tools with Remy gets that discipline from day one instead of retrofitting it after an exposure scan finds the app first. That's the same instinct behind treating any internally built tool as something you own, not something you tolerate, a theme we've come back to when looking at why software ownership matters more broadly.

A starter checklist for this week

• Run a discovery pass: ask department leads directly what AI tools and apps their teams are already using for real work.
• Tag every app found by the type of data it touches: public, internal, customer PII, financial, regulated.
• Check the obvious exposure points first: authentication, API keys in client-side code, and database row-level security.
• Pick two or three sanctioned building blocks (auth template, database, secrets vault) and make them the default recommendation, not a mandate nobody follows.
• Set a graduation threshold: any app touching customer data or running more than 90 days gets a security review and an assigned owner, no exceptions.

The apps aren't going away. The people building them aren't going to ask permission first, most of them didn't know they needed to. The job now is making sure the fast path and the safe path are the same path.