Shadow AI Apps Are the New Shadow IT: A 2026 Guide for IT Leaders

Shadow AI apps are working applications that employees build with AI app builders and deploy outside IT’s inventory. They differ from classic shadow IT in kind, not degree: shadow IT was unsanctioned software your company bought; a shadow AI app is unsanctioned software your company now ships, often public by default, holding real data, with no owner.

That distinction is the whole problem, and it is why the response that worked for shadow IT, find the subscription and cancel it, does not work here. This blog covers what the security research has actually documented about AI-built apps in the wild, why prohibition fails, a discovery playbook you can run this week, and what to do with the apps you find.

From Shadow IT to Shadow AI: What Actually Changed

Shadow IT had a familiar shape. An employee expensed a SaaS subscription, a team quietly adopted a file-sharing tool, and IT eventually found out. The blast radius was a bill, a data silo, and a vendor risk review done late. The unsanctioned thing was a product someone else built, maintained, patched, and secured. When you discovered it, you could evaluate the vendor, negotiate a contract, or shut it off.

A shadow AI app inverts every one of those properties. The employee is no longer a buyer; they are a builder. The artifact is not a vendor’s product with a security team behind it; it is a one-off application generated in an afternoon, deployed to a public URL, and connected to whatever data the builder could reach. There is no vendor to review, because the vendor is your marketing coordinator. There is no patch cycle because nobody knows the app exists, including, within a few months, sometimes the person who built it.

Put simply, shadow IT added unsanctioned products to your stack. Shadow AI adds unsanctioned software vendors to your org chart, and they get utilized without a security review, an owner of record, or an entry in your asset inventory.

None of this requires malice or even carelessness. It requires exactly what AI app builders are designed to deliver: a person with a real business problem and no development background, producing a working app faster than the request would clear your intake queue. The intent is almost always good. The output is still an unowned, unaudited application, and the evidence on what those look like at scale is now well documented.

The Evidence: What Scans of AI-Built Apps Keep Finding

Two large independent scans, run by different firms on different populations months apart, found the same failure pattern. Both are worth reading in full; the figures below link to primary coverage. For the broader security record and what to do about it, see our guide to secure alternatives to vibe coding.

Escape.tech: 5,600+ publicly available apps, 2,000+ high-impact vulnerabilities

In October 2025, security firm Escape.tech scanned publicly available applications built with prompt-to-app tools including Lovable, Base44, Create.xyz, Vibe Studio, and Bolt. From the published methodology: the team analyzed over 5,600 publicly available applications and identified more than 2,000 vulnerabilities, 400+ exposed secrets, and 175 instances of PII, including medical records, IBANs, phone numbers, and emails. Escape characterized the vulnerabilities as high-impact. These were publicly available apps and live deployments, found from the outside, which is precisely the position a shadow AI app occupies: reachable by anyone, inventoried by no one.

Red Access: the full chain, 380,000 assets down to 2,000+ exposures

In May 2026, security firm Red Access published a larger sweep. The numbers deserve to be printed as a chain, not a headline. Red Access scanned 380,000 publicly accessible assets, meaning apps, databases, and related infrastructure built with tools from Lovable, Base44, Replit, and Netlify. Of those, roughly 5,000 looked corporate. Of those, more than 2,000 held sensitive data reachable at a public URL, often indexed by Google, with no exploitation required. No attack, no credential theft, no vulnerability chaining. The data was simply there.

Axios independently verified exposed examples, including a Brazilian bank’s internal financials, a UK health company’s active clinical trials, and a hospital app containing doctor-patient conversation summaries. eWeek’s coverage reports that both Axios and WIRED independently verified the findings.

One more detail matters, and it should be conceded rather than buried: the root cause Red Access reported was default-public privacy settings as much as flawed generated code. The builders did not know to change the default, and nothing in the tooling was responsible for knowing on their behalf. That concession is not a defense of the status quo; it is the indictment. A misconfiguration only becomes a months-long public exposure when nobody owns the output. The failure mode of shadow AI is structural, which is why the fix is discovery plus governance, not better prompts.

The corroborating signal: attributed CVEs are climbing

Georgia Tech’s Vibe Security Radar tracks CVEs attributed to AI coding tools through signatures in the code itself, such as AI co-author tags and bot emails in commits. As reported by Infosecurity Magazine in March 2026, monthly attributed CVEs rose from 6 in January 2026 to 35 in March. Because attribution is signature-based, the researchers describe their count as a floor, not a census. For an IT leader, the direction matters more than the absolute number: the population of AI-generated code in the wild is growing faster than anyone’s ability to attribute it, let alone inventory it.

Why Prohibition Fails

The instinctive response is a ban: block the builder domains, update the acceptable-use policy, send the memo. Three reasons that fails.

The demand is not a fad you can wait out. Gartner predicts that by 2028, 40% of new enterprise production software will be created with vibe coding techniques and tools (Gartner, May 2025, as reported by CIO Dive). Note the scope: Gartner’s usage covers AI-assisted development broadly, including professional developers, so read it as a volume forecast, not a verdict on citizen builders. But the volume premise alone is decisive. A workflow projected to produce a large share of new enterprise software is not something a firewall rule makes disappear; it is something that reroutes around the firewall rule.

The builders are not a population you can train your way around. Dor Zvi, CEO of Red Access, made the point bluntly in eWeek: “I don’t think it’s feasible to educate the whole world around security. My mother is [vibe coding] with Lovable, and no offense, but I don’t think she will think about role-based access.” The people building shadow AI apps are, by definition, the people who never absorbed secure-development training and never will. Security awareness programs were built for users, not for a workforce of accidental software vendors.

Bans convert visible risk into invisible risk. This is the oldest lesson of shadow IT, and it applies with more force here. An employee blocked from a builder at the office finishes the app on a personal laptop, on a personal account, on a personal card. The app still exists and still holds company data. The only thing the ban eliminated was your visibility into it. Prohibition does not reduce the population of shadow AI apps; it reduces the fraction of them you can find.

The workable posture is the same one that eventually tamed shadow IT: assume the behavior, discover the inventory, and give the demand a sanctioned place to land.

The Shadow AI Discovery Playbook

You cannot govern what you have not found. The following sweep is runnable by most IT teams inside two weeks, and every step produces a concrete artifact for your inventory.

1. Sweep expense reports and corporate cards. AI app builders bill like consumer SaaS, at price points small enough to clear a corporate card without review. Pull 12 months of card and expense data and search merchant names for the known builders (Lovable, Replit, Bolt, Base44, Create, and their payment processors). Every hit is a builder identity, and probably at least one deployed app.
2. Sweep SSO and identity-provider logs. Search OAuth consent grants and “sign in with Google/Microsoft” events for builder and deployment domains. This catches employees who signed up with their work identity even when no money moved, which is common on free tiers.
3. Review DNS and subdomains. Audit your DNS zones for CNAME records pointing at builder hosting infrastructure, and check your certificate-transparency logs for unfamiliar subdomains. Anything an employee wired to a company domain graduates from experiment to brand-bearing asset.
4. Check network egress against known builder domains. Your secure web gateway or DNS resolver logs will show sustained traffic to builder platforms and their deployment domains. Frequency matters: a one-time visit is curiosity; a daily session is a project.
5. Search the public index for your own exposure. The Red Access findings included data indexed by Google. Run targeted searches for your company name, product names, and internal project names across the builders’ public hosting domains. This is the same reconnaissance an attacker or a journalist would run, so run it first.
6. Open an amnesty inventory window. For 30 days, invite every team to register anything they have built with an AI tool, no penalty, no app shutdowns except on active data exposure. You will find more in one amnesty month than in a quarter of log forensics, because the builders know where the apps are and you do not. The price of amnesty is registration; the payoff for the builder is a legitimate path to keep what works.
7. Route every discovered app into a governance review. Discovery without disposition just produces a scarier spreadsheet. Each found app needs an owner of record, a data classification, an access model check, and a keep-migrate-retire decision.

Then make the sweep a cycle, not an event. Steps 1 through 5 are scriptable; schedule them quarterly and diff the results.

Give Builders Somewhere Legitimate to Land

Discovery and governance handle the apps that already exist. The durable fix is upstream: the demand that produced them needs a sanctioned default, because employees build in the shadows only when the sanctioned path is slower than the unsanctioned one, or priced per seat in a way that makes asking for access a budget negotiation.

That is a solvable platform-selection problem. A governed application platform gives business builders the speed they went around you to get, while every app they create is born inside controls IT already owns: roles and permissions, record-level security, and audit logs, deployed as fully hosted apps or embeddable components rather than orphaned public URLs. Caspio is built for exactly this posture, and its licensing removes the quiet driver of workarounds: unlimited users, so nobody spins up an outside tool because seats ran out.

For teams whose builders touch regulated data, the division of labor is the point: AI builds it; the platform it lives on carries annually certified HIPAA and SOC 2 Type II. The same logic now applies to the next wave of shadow demand: employees wiring chatbots to business data. An AI Agent added to a sanctioned Caspio app gives users a chat interface over their data that runs under the signed-in user’s role. Record-level security remains in effect, with field-level security applied at design time. That keeps “chat with our data” inside the inventory instead of in an ungoverned bot wired to last month’s export. For evaluation criteria across the category, see our guide to AI app builders for regulated industries.

The IT leaders who handled shadow IT best were not the ones who banned Dropbox hardest; they were the ones who deployed a sanctioned equivalent and made it the path of least resistance. Shadow AI rewards the same move, made earlier. Find the apps, govern the survivors, and give the builders a default that makes the shadow version the slower option.

Frequently Asked Questions

What is the difference between shadow AI and shadow IT?

Shadow IT is unsanctioned software your employees buy, typically SaaS subscriptions with a vendor responsible for security. Shadow AI apps are unsanctioned software your employees build and deploy with AI app builders. There is no vendor accountable for the output, the apps are often public by default, and they typically hold real business data with no owner of record.

How do I find AI-built apps in my company?

Run five sweeps: expense reports and corporate cards for builder subscriptions, SSO and OAuth logs for sign-ups to builder domains, DNS and certificate-transparency records for connected subdomains, network egress logs for sustained builder traffic, and public search-engine queries for your company’s name on builder hosting domains. Then open a 30-day amnesty window so builders self-report the rest.

How risky are shadow AI apps really?

The exposure is documented, not hypothetical. Escape.tech scanned 5,600+ publicly available vibe-built apps and found 2,000+ high-impact vulnerabilities, 400+ exposed secrets, and 175 PII instances including medical records. Red Access scanned 380,000 publicly accessible AI-built assets and found more than 2,000 corporate-looking apps exposing sensitive data at public URLs with no exploitation required.

Should we ban employees from using AI app builders?

No. Bans convert visible risk into invisible risk: blocked employees rebuild on personal accounts and devices, and the app still exists with your data in it. Gartner predicts 40% of new enterprise production software will be created with vibe coding techniques and tools by 2028, so the demand outlasts any ban. Discovery, governance, and a sanctioned platform work; prohibition does not.

What should a shadow AI policy include?

Four elements: a standing discovery process (quarterly log and DNS sweeps plus an amnesty registration path), a mandatory review for every found app (owner, data classification, access model, keep-migrate-retire decision), a procurement gate for new AI building tools, and a sanctioned governed platform so new demand has a legitimate default. A policy that only prohibits will be routed around.