# Shadow AI apps: what IT can do about tools staff build with AI

> Canonical: https://teamonly.dev/guides/shadow-ai-apps

Last updated 25 October 2026. Written by TeamOnly. We make one of the places builders can deploy to, and we say so where it comes up.

**Quick answer:** Assume these apps already exist. Find them without blame, then give builders one approved place to deploy: behind your company login, with a named owner for every app. A one-page policy covers the rest.

Banning AI tools rarely works. It moves the apps somewhere you can't see. This page covers what shadow AI is, the real risks of AI-built internal apps, how to find what already exists, and a policy you can copy.

## What is shadow AI?

Three terms that get mixed up. They describe the same habit at different stages.

- **Shadow IT:** software and services people use for work without IT knowing or approving. A personal file-sharing account, a project tool paid on someone's card.
- **Shadow AI:** the same, with AI tools. Staff paste company data into chat assistants or AI features that IT has not reviewed.
- **Shadow AI apps:** the newer part. Staff use Claude Code, Cursor, Lovable, Replit, Bolt or v0 to build a working app, publish it, and send the link to coworkers. The app holds company data and keeps running.

The third one is different because it lasts. A chat is over in a minute. An app has users, data and a link that keeps working, often on the builder's own account.

**Vendor research:** In a Retool survey of 307 CTOs, CIOs and CISOs in May 2026, 8% said they had strong governance of AI-built internal tools, and 5% were very confident they could see everything running. Security company Red Access reported finding more than 380,000 publicly reachable assets on the main vibe-coding platforms. About 5,000 looked like company tools, and more than 2,000 of those held sensitive business, operational or personal data.

Checked 25 October 2026. Sources: [Retool AI Governance Report 2026](https://retool.com/blog/ai-governance-report-2026) (a vendor survey, June 2026), [summary of Red Access's research on The Hacker News](https://thehackernews.com/2026/05/what-2000-exposed-vibe-coded-apps.html) (a contributed article, May 2026).

## What can go wrong with AI-built internal apps?

The code is rarely the main problem. Where the app lives, and who can open it, usually is.

- **Public links with company data.** Many app builders publish to the open web unless you pay for, or find, the private option. A link nobody was told about still gets shared, and sometimes indexed by search engines.
- **Shared passwords.** A password on the whole app ends up in chat threads and emails. The app can't tell who did what, and people who leave still know it.
- **Apps on personal accounts.** The app runs on whatever platform the builder signed up for, billed to their card, under their login. The company has no admin access to it and may not know it exists.
- **No owner when someone leaves.** When the builder leaves, the app either keeps running with nobody responsible for it, or stops when their card is cancelled. Either way, the team that relied on it finds out last.
- **No list of what exists.** You can't review, fix or retire an app you don't know about. Without a list, every one of these risks is invisible.
- **Secrets in code, databases left open.** AI tools sometimes write API keys into code that runs in the browser, where anyone who opens the app can read them. A hosted database with row-level security turned off can be read without going through the app at all.

## How do I find the apps that already exist?

No single tool finds them all. These steps, together, find most of them in an afternoon.

1. **Ask, without blame.** Send one short message: "If you built a tool with AI that coworkers use, tell us. Nothing gets switched off, we want to help you keep it running safely." Builders are usually glad someone asked.
2. **Check expense reports and card statements.** Look for Lovable, Replit, Bolt, Vercel, Netlify, Supabase, Cursor and Claude subscriptions. A builder platform on an expense report usually means an app somewhere.
3. **Check what people signed in to with their work account.** Google Workspace and Microsoft Entra both list the third-party apps people connected with their work account, and sign-in logs show which ones they use. Builder platforms show up there when people sign up with "Sign in with Google" or Microsoft.
4. **Look for app addresses.** Search DNS or web proxy logs, and your company chat, for addresses like `*.lovable.app`, `*.replit.app`, `*.vercel.app`, `*.netlify.app` and `*.pages.dev`. Links in chat are often the fastest way to find the apps people actually use.
5. **Check browser and device inventories, if you have them.** If you manage browsers or laptops, the inventory shows AI extensions and apps like Cursor or Claude installed. That tells you who is building, not what they built, so follow up by asking.
6. **Write it down.** One row per app: name, owner, where it is hosted, what data it holds, who uses it. That sheet is your first inventory, and it tells you which apps to move first.

## A vibe coding policy you can adopt

Short enough that people read it. Change the parts in [brackets] and send it.

```text
Policy: tools built with AI

1. What this covers. Any app, script or tool built with AI help (Claude Code,
   Cursor, Lovable, Replit, Bolt, v0 or similar) that someone other than its
   builder uses.
2. Building is allowed. Anyone may build tools for their own work. You don't
   need permission to try an idea.
3. Where apps live. Apps that coworkers use are deployed to [our approved
   host]. Not on a personal account, and not on public hosting.
4. Login comes first. Every app asks for a company account before it shows
   any screen or data. No shared passwords and no public links.
5. Data. Internal work data is fine. Customer personal data, payment card
   data, health data and passwords to other systems need a check with IT
   first. Company data never goes into an app on a personal account.
6. Keys and passwords. API keys and passwords go in the host's secret
   settings. Never in the code, and never in chat.
7. Every app has an owner. The owner keeps it working and decides who can
   open it: the whole company or a named list of people.
8. When someone leaves. Before someone leaves or changes role, their apps are
   handed to a new owner. An app nobody takes over is turned off.
9. Report, without blame. If you find an app with company data that anyone
   can open, tell [IT contact]. Nobody gets in trouble for reporting.
10. Review. IT reviews the list of apps every [quarter]. Apps nobody has used
    in [90 days] may be deleted after asking the owner.
```

### Why not just ban it?

People build these tools because they solve real problems. A ban doesn't remove the problem, it moves the tool to a personal account. One approved place to deploy gets you the same tools, behind your login, in a list you can read.

## Give builders somewhere safe to deploy

The policy works when the approved host does the hard parts, so builders can't get them wrong. This is what TeamOnly does.

- **Login before any app code runs.** Every request to every app is checked first. People who are not signed in never reach the app. There is no setting to make an app public.
- **Only company accounts.** Coworkers sign in with work Google, work Microsoft or a code sent to their work email. Only your domains get in, and personal accounts are refused.
- **Every app listed.** The dashboard shows every app in your company, its owner, who can open it and every deploy. Access is the whole company or a named list.
- **A new owner when people leave.** Admins hand an app to a new owner in the dashboard. Turn off someone's work account and new sign-ins stop. Admins choose how long app sign-ins last, from 8 hours to 30 days.
- **Sign out everywhere.** An admin can sign a builder out of every terminal and the dashboard at once.
- **Apps kept apart.** Each app has its own database, file storage and secrets, and its session cookie is scoped to its own address. Keys are set with `npx teamonly secrets set`, outside the code.

Builder is $19 a month for one builder and 3 apps. Team is $249 a month for unlimited apps and builders. People who only use apps are free. [Pricing](https://teamonly.dev/pricing).

**Business plan:** On Business ($899 a month), Okta, OneLogin or other SSO, audit logs, offboarding, data region and paying by invoice are included, and we set them up with your IT team when you join.

What it doesn't do: TeamOnly hosts internal web apps with a React front end and a JavaScript or TypeScript API. It doesn't host public websites or Python apps, and we have no SOC 2 or ISO certification today. [Security details](https://teamonly.dev/security).

## Questions people ask

### What is shadow AI?

Shadow AI is staff using AI tools for work without IT knowing or approving, often with company data in them. It started with chat assistants. It now includes working apps that staff build with AI and share with coworkers.

### What is the difference between shadow IT and shadow AI?

Shadow IT is any software or service people use for work outside IT's view, like a file-sharing account or a project tool paid on a personal card. Shadow AI is the same thing with AI tools. Shadow AI apps go one step further: the staff member is not just using a tool, they built one, and it holds company data.

### Should we ban vibe coding?

A ban rarely removes the need. People build these tools because they solve real problems, so a ban moves them to personal accounts where you can't see them. Most companies do better with a short policy and one approved place to deploy.

### How do we find the AI-built apps people already made?

Ask, without blame. Then check expense reports for Lovable, Replit, Vercel and similar subscriptions, the list of third-party apps people connected with their work account in Google Workspace or Microsoft Entra, and DNS or chat logs for addresses like `*.lovable.app` or `*.vercel.app`.

### What should a vibe coding policy include?

What people may build, where apps must be deployed, that every app needs a company login, what data is allowed, where keys and passwords go, who owns each app, and what happens when the owner leaves. The policy on this page fits on one page and can be copied as is.

### Are AI-built apps a security risk?

For internal tools, the bigger risk is usually where the app lives, not the code: a public link, a shared password, a personal account, keys written into the code, or nobody responsible once the builder leaves. Each of those can be fixed by the place the app is deployed to.

## Keep reading

- [TeamOnly for IT](https://teamonly.dev/for-it)
- [Security details](https://teamonly.dev/security)
- [Pricing](https://teamonly.dev/pricing)
- [Share an AI-built app with your team](https://teamonly.dev/guides/share-an-ai-built-app-with-your-team)
- [Company-only login](https://teamonly.dev/company-login)

Try it free for 14 days, no card: https://teamonly.dev/pricing#trial. Or subscribe: https://teamonly.dev/pricing#subscribe (Builder $19/mo, Team $249/mo, Business $899/mo)
For IT: https://teamonly.dev/for-it