Guide for IT

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

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.

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

01Definitions

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.

Checked 25 October 2026. Sources: Retool AI Governance Report 2026 (a vendor survey, June 2026), summary of Red Access’s research on The Hacker News (a contributed article, May 2026).

02The real risks

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.

03Step by step

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.

04Copy this

A vibe coding policy you can adopt

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

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.

Want it as plain text? The Markdown version of this page has the policy ready to paste (in English).

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.

05A sanctioned place

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.

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.

06FAQ

Questions people ask

All questions and answers

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.

Early access

Give your builders one approved place to deploy.

Every plan is open now, and builders can try it free for 14 days with no card. Your company is ready right away, and builders can deploy the same day.

Try free for 14 daysOr subscribe now

No card for the trial. Then from $19 a month, cancel any time.

Not ready? Get updates

Use your work email. We write rarely, and only when there is news worth sending.

Questions go to hello@teamonly.dev, and a person answers.