What is shadow AI? Meaning, risks, and how to bring AI-built apps into the open

IBM defines shadow AI as employees or end users using AI tools or applications without the organization's approval. That includes a personal chatbot account used for work, an AI feature switched on inside approved software without review, and an internal app someone built with an AI coding agent and shared with colleagues.

The problem is not that people use AI. It is that nobody responsible for the data, the security or the outcome knows the tool exists, so nobody can check what it reads, who can use it or what happens when it breaks.

• IBM: what is shadow AI? →

Shadow IT is any software or hardware used without IT approval. Shadow AI is the AI-specific part of it, and it raises questions shadow IT does not: what data was sent to a model, whether its output can be trusted, and who decided to act on it.

Scroll sideways to see all columns. With the table focused, use the arrow keys.

Treat them separately: each one is found and fixed differently.

• AI assistants on personal accounts: employees using their own chatbot subscriptions for work, often with company data in the prompt.
• AI features inside approved tools: assistants and agents switched on in software the company already uses, without a review of what data they can reach.
• AI-built applications: dashboards, request forms and small workflow tools employees build with Claude Code, Codex, Cursor or similar tools, then run from personal hosting accounts and share by link. This is the kind SpringRoll exists to bring into the open.

These are typical patterns, not reports about any particular company.

• A sales manager pastes this quarter's pipeline into a personal chatbot to draft a forecast.
• A finance analyst builds a purchase approval tracker with Claude Code and shares its public URL in a team chat.
• A support lead publishes a Claude artifact with a shared tracker, and colleagues start typing customer details into it.
• An operations app built over a weekend reads the production database with the builder's own credentials, embedded in the app.
• A team's tool runs on someone's free personal hosting plan, and stops when its monthly limit runs out or the builder leaves.

• Why personal hosting plans do not fit company apps →
• When a Claude artifact should become a deployed app →

MIT's Project NANDA, in its report State of AI in Business 2025, found that employees at over 90 percent of companies regularly use personal AI tools for work, while only 40 percent of companies had bought official LLM subscriptions. Fortune's coverage called the result a shadow AI economy flourishing under the radar.

The gap matters because it shows where demand is. People are not waiting for approval; they are getting work done with whatever is available. The same is now true of building software: when an employee can produce a working internal app in an afternoon, a request queue measured in weeks will lose.

• Fortune on MIT NANDA's shadow AI economy findings →

IBM lists data leakage, noncompliance fines and reputational damage as the main risks. In AI-built apps they take concrete forms worth checking for directly.

• Data leaving approved systems: prompts and uploads sent to tools nobody reviewed.
• Credentials in the wrong place: database passwords or API keys copied into generated code or a browser bundle.
• Open links: an app shared by URL that anyone holding the link can open, including former employees.
• No owner: when the builder moves on, nobody can fix, update or switch off the app.
• No review: a generated change goes live without anyone checking what it does to data or permissions.
• No record: when something goes wrong, there is no history of who deployed which version or who could use it.

• Pre-launch security checklist for AI-built apps →

Start by asking. A short, no-blame inventory request (which tools and apps do you rely on, who built them, what data do they touch) finds more than any scan, because the builders usually want their tools supported.

• Review OAuth grants in your identity provider for AI tools and hosting services employees have connected with company accounts.
• Look in web proxy or DNS logs for app hosting domains such as vercel.app, pages.dev and workers.dev, and for shared artifact links.
• Check expense reports for personal AI and hosting subscriptions.
• Scan code repositories for committed keys and for projects that deploy outside approved accounts.
• Ask each team which internal links they bookmark, and who to call when one breaks.

Banning coding agents pushes the work further out of sight. SpringRoll takes the other route: builders keep using Claude Code, Codex or Cursor, and the sanctioned way to share what they build becomes the fastest way. One command connects their agent to SpringRoll, and the agent can deploy from there.

Every app deployed through SpringRoll gets a named owner and a release history, runs on a managed Vercel or Cloudflare account rather than a personal one, and reaches colleagues through the App Portal, where the owner chooses who may open it. Releases go straight to Production or through a reviewer, as an administrator decides. When an app needs company data, it requests specific fields and a data owner approves them, so the app never holds a database credential. The agent cannot approve its own release, and every call is recorded in an audit log.

For shadow apps that already exist: record what is running and who relies on it, redeploy the source through SpringRoll, test access with one colleague inside the audience and one outside it, then retire the old link and rotate any secret it held.

claude mcp add --transport http springroll https://springroll.dev/api/mcp

• A governance policy template for employee-built apps →
• Hand an app to an accountable owner →
• SpringRoll's identity, access and audit controls →