Shadow AI Isn’t the New Shadow IT. Here’s What Actually Changed — and Why ‘Shared Responsibility’ Won’t Fix It

A finance manager at your company opens Lovable on Sunday night, pastes in a few spreadsheets, and ships an internal budget-tracking app by Monday morning. It’s wired into your CRM through credentials she was issued for legitimate work. It’s reachable at a URL anyone can type. Nobody on your security team knows it exists.

This isn’t hypothetical. In research Red Access published earlier this year — covered by WIRED, Axios, and VentureBeat — we identified more than 380,000 vibe-coded applications sitting on the open web. About 5,000 originated inside corporate environments. More than 2,000 held sensitive business data, often with administrative control granted to whoever reached the URL. That is what Shadow AI looks like in 2026 — not employees pasting into ChatGPT, but employees becoming shadow software vendors.

The question most journalists and analysts are asking right now is who owns this problem. Everyone already knows the answer: the CISO does. The real question is whether the telemetry underneath that ownership makes it survivable.

Key takeaways

• Shadow IT was unauthorized consumption of technology. Shadow AI is unauthorized creation of it. The application is custom-built, the data is custom-loaded, and the artifact often lives on a public URL.
• Shared responsibility doesn’t produce the visibility that ownership requires. Four security tools each see a fragment of the user’s AI session. None of them sees the session itself.
• Blocking moves AI use to personal accounts. It doesn’t remove the risk — it hides it. Verizon’s 2026 DBIR puts non-corporate AI use at 67% of all enterprise AI users.
• Inventory alone is a static list of a world that’s already moved. An agent approved to summarize documents in February can become a CRM exporter in May without appearing as a new asset.
• The enforcement surface for Shadow AI is the session — the browser or web-connected desktop app where the data gets typed, pasted, connected, and published.

What is the difference between Shadow IT and Shadow AI?

Shadow IT is an employee’s use of unauthorized third-party software — a personal Dropbox, an unsanctioned SaaS account — where the data leaves the company but stays with a known vendor under contractual terms. Shadow AI, in its 2026 form, is an employee building and deploying their own AI-powered software — custom-built on platforms like Lovable, Replit, or Base44, loaded with corporate data through credentials they were issued, and often published to a public URL. Shadow IT was a control problem the industry eventually learned to solve. Shadow AI changes what has to be controlled.

Why Shadow AI Isn’t Just Shadow IT 2.0

Treating Shadow AI as a continuation of Shadow IT leads to the wrong playbook. Shadow IT was bounded — an unsanctioned SaaS vendor was still a vendor, with an identity, a contract, retention policies, and audit logs. You could discover it with a CASB. You could block it at the firewall. The data stayed with the vendor. The industry spent fifteen years learning how to see Shadow IT, and it mostly worked.

Shadow AI inverts every one of those properties. The application is custom-built by the employee. The data is custom-loaded by the employee. The integrations connect directly to the CRM, the ERP, the production database — using credentials the company issued. And the artifact is often published on the open internet.

What this changes for CISOs: the discovery and containment tools that solved Shadow IT don’t map onto Shadow AI. There’s no vendor to subpoena, no contract to invoke, no audit trail to pull. There is a builder, a platform, and a URL — and IT, mostly not in the room.

How Shadow AI Differs from Shadow IT

Four properties inverted between the two categories, and each inversion closes a control path security teams used to rely on.

Who builds it. Shadow IT involved an employee choosing software that someone else built. Shadow AI, in 2026, increasingly involves the employee being the builder — shipping a spreadsheet automation on Replit, a client dashboard on Lovable, a reporting tool on Base44 over a weekend.

Who loads the data. Shadow IT moved company data into a vendor’s product. Shadow AI loads company data into an application the employee just wrote — with integrations that connect directly into Salesforce, the ERP, or the production database using credentials the company already issued.

Where it lives. Shadow IT data sat inside a vendor tenant under that vendor’s contractual terms. Shadow AI applications are often deployed to public URLs. The platform underneath (Lovable, Replit, Base44) may be audited. The application built on it isn’t.

How you discover it. A CASB could reliably inventory Shadow IT in most environments by 2020 — an unauthorized SaaS app had a login page, a known domain, a recognizable OAuth footprint. Shadow AI operates through at least seven surfaces that don’t register consistently: personal accounts on approved platforms, browser extensions, AI features embedded inside sanctioned SaaS, developer-tool integrations, locally running LLMs, vibe-coded applications deployed to the open internet, and autonomous agents running on employee credentials.

On the record. Look at what’s already reached the public record. On May 11, 2026, CB Financial Services — the parent of Community Bank — filed a Form 8-K with the SEC disclosing an internal incident involving non-public customer information “handled using an unauthorized artificial intelligence-based software application.” Customer names, Social Security numbers, dates of birth. The filing never names which AI tool was involved, because the regulator didn’t need to know. It needed to know the data was gone. Samsung engineers submitting source code to ChatGPT in 2023 was the warning. CB Financial Services in 2026 is what it looks like once it reaches the SEC.

What this changes for CISOs: the default assumption — that discovery tools will surface AI the way they surfaced SaaS — doesn’t hold. Discovery has to extend to the surfaces where employees now build and deploy, not only to the ones where they consume.

Why Shared Responsibility Doesn’t Solve Shadow AI

The industry’s answer so far has been to assign the problem to a committee. Give it to Security. Loop in IT, Data Governance, Legal. Make it everyone’s.

Two things about that.

First, a problem that is everyone’s is nobody’s. In OneTrust’s 2026 data, only 48% of organizations reported clear visibility into both sanctioned and unsanctioned AI use. Okta found that just 19% of CISOs strongly agreed they could identify every AI agent in their environment. Those numbers describe a shortage of ownership, not a shortage of meetings.

Second, even if you appointed a single accountable owner tomorrow, the problem wouldn’t go away. The cross-functional model assumes the data exists somewhere and only needs to be coordinated. It doesn’t. The firewall sees traffic to a subdomain. The DLP sees a prompt that may or may not match a rule. The identity system sees an OAuth grant. The EDR sees a browser process. Not one of those tools sees the session — the only layer where those fragments resolve into one sentence: the finance manager built an app, connected it to Salesforce, and published it at a public URL.

On the record. Put the CISO, the CIO, the CDO, and the general counsel in a room every Tuesday for a year. If none of the tools underneath them can produce that sentence, the meeting is theater — not because the people are wrong, but because they’re being asked to coordinate data that was never captured in the first place.

What this changes for CISOs: before investing another cycle in cross-functional governance, audit the underlying telemetry. If no tool in the stack can describe a Shadow AI incident as one coherent event, the ownership model isn’t the blocker. The visibility is.

Why Blocking and Inventory Alone Don’t Reduce Risk

The two most common responses — block the tools, build an inventory — both fall short for the same reason.

Blocking moves the risk; it doesn’t remove it. Netskope’s own 2026 data shows the number of GenAI applications it tracks grew fivefold year over year, while the average number used per organization rose only from six to eight. Blocking reduces access to known services. It does not reduce AI use. The moment you block, you have challenged your users to find the shadow — and they do. In Netskope’s July 2026 data, 44% of enterprise AI users still relied on personal AI accounts. Verizon’s 2026 DBIR found that 67% of AI users accessed AI through non-corporate accounts on corporate devices.

Inventory is a snapshot of a world that’s already moved. A shared registry records that an AI agent exists and was approved in February to summarize documents. It does not record that in May, a developer connected the same agent to the CRM and granted it permission to export records. The asset didn’t change. Its risk profile did. Only 21% of organizations surveyed by the Cloud Security Alliance in early 2026 maintained a real-time inventory of their AI agents. The rest were describing a world that had already moved.

On the record. Visibility without enforcement is observation. A static list is observation of a world that is no longer there. Both controls are necessary. Neither is sufficient.

What this changes for CISOs: the useful metric for a Shadow AI program isn’t “how many AI tools are blocked” or “how many agents are inventoried.” It’s whether the organization can see an unauthorized AI action — a paste, an API connection, a public deployment — as it happens, and stop it inline.

How Shadow AI Becomes Shadow Infrastructure

This gets structurally worse before it gets better — not because employees get sloppier, but because the capability matures.

The arc. In September 2026, Gartner warned that employees are building AI agents faster than enterprises can govern them, including agents produced through vibe coding and embedded SaaS features. The progression is deliberate. Employees moved from using AI (pasting into a chatbot), to building with it (shipping an app on Lovable or Base44), to deploying it (publishing that app to a URL), to letting it act (giving it credentials and a workflow it runs on its own). Each step is a different risk surface. They stack.

On the record. That’s why the “Shadow IT 2.0” framing is dangerous. Shadow IT meant employees adopting software outside the stack. Shadow AI means employees building it. Agentic AI means that software can act on its own. Three categories of risk, one on top of the next — and almost all of it happening inside sessions the existing stack was never designed to inspect.

What this changes for CISOs: the Shadow AI control surface in 2026 is not the same as the Shadow AI control surface in 2024. A program designed around chatbot governance will not catch an employee-built app with CRM access, and a program designed around application inventory will not catch an autonomous agent that gained new permissions after approval. The surface moves. The controls have to move with it.

What Actually Reduces Shadow AI Risk

Four categories of control address different parts of the Shadow AI problem. Three are necessary and insufficient. The fourth is where the first three resolve into enforcement.

Control	What it does	Where it breaks	Owner
Known-tool block lists	Prevents access to a specified set of AI services	Doesn’t cover personal accounts, embedded SaaS AI, or tools the list hasn’t caught up to	Security + IT
AI asset inventory	Documents approved agents, applications, and integrations	Doesn’t capture permission changes, new data connections, or runtime behavior	Data governance + Security
Cross-functional review	Coordinates policy across Security, IT, Data, Legal	Depends on telemetry that fragmented security tools don’t produce	Executive sponsor
Session-layer inspection + account enforcement	Sees and governs the actual action — the paste, the OAuth bind, the public deployment — inside the browser or desktop AI app where it happens	Doesn’t replace the three above; doesn’t cover pure background daemons running outside any session	Security

That last row is where Red Access operates. Work has expanded beyond the browser to AI tools and desktop apps built on web technologies — Claude Desktop, ChatGPT Desktop, Electron-based assistants, embedded webviews inside SaaS, vibe-coding platforms — and Red Access adds in-session security there. Architecturally: a one-line dynamic configuration, pushed through MDM, Intune, or GPO, tells the endpoint how to reach Red Access — no MSI, no extension, no persistent install, no reboot. When a browser or web-connected desktop app opens a session, Red Access delivers a lightweight security engine into that session in-flight, before the page loads. The engine lives in the session and enforces policy locally — decisions happen at the edge, not through a cloud round-trip — which is why users don’t feel it and SaaS apps don’t break. We are not a proxy. Proxies transfer data. We inspect actions. In the opening scenario, that means Red Access sees the moment the finance manager pastes the spreadsheet into the Lovable prompt — and, if policy says that data class doesn’t leave, blocks the paste before a single record reaches Lovable’s servers. Same engine, same session, same enforcement point for the OAuth bind to Salesforce or the click that publishes the app to the open web.

What Red Access doesn’t cover: pure background daemons that run outside any session, agent-to-agent communication that never touches a web surface, and the server-side logic of an MCP server once it’s running on its own back end. Those belong to EDR, identity governance, and API-gateway controls — alongside the tool-side settings in the agent’s own configuration. A session-layer product doesn’t replace the three other rows above. It completes them.

Shadow IT didn’t get solved because the industry figured out who owned it. It got solved — to the degree it got solved — because the tooling caught up with the pattern. Shadow AI won’t be different. The only question is whether, this time, the catching up starts before the next 8-K.

FAQs

Is Shadow AI the same as Shadow IT?
No. Shadow IT involves the unauthorized use of third-party software, where data leaves the company but stays with a known vendor under contract. Shadow AI, in its 2026 form, involves employees building and deploying their own AI-powered software — often loaded with corporate data through issued credentials and published to public URLs. The control models that worked for Shadow IT (CASBs, block lists, acceptable-use policies) don’t map cleanly onto Shadow AI.

Who owns Shadow AI inside an enterprise?
In practice, the CISO. The 8-K gets signed by a human, not a department. Analyst frameworks often call for shared ownership across Security, IT, Data Governance, and Legal, but shared accountability without underlying telemetry produces coordination without visibility. The operational question is whether security tools in the stack can see and govern AI actions as they happen, not which committee meets about them.

What is the most common Shadow AI risk in 2026?
Data exfiltration through unauthorized AI applications — where an employee uses an unsanctioned AI tool or builds an AI-powered application that processes customer records, credentials, or sensitive business data outside the company’s security controls. IBM’s 2025 Cost of a Data Breach report associates shadow AI with $670K in additional average breach cost. Verizon’s 2026 DBIR now lists Shadow AI as the third most common non-malicious insider action.

Does blocking AI tools reduce Shadow AI?
Partially. Blocking reduces access to known services, but it doesn’t reduce AI use overall — employees shift to personal accounts, embedded AI features inside approved SaaS, or applications they build themselves. Netskope’s 2026 data shows 44% of enterprise AI users still relied on personal AI accounts; Verizon found 67% accessed AI through non-corporate accounts on corporate devices. Block lists are necessary but insufficient.

What is the CB Financial Services 8-K about?
On May 11, 2026, CB Financial Services — the parent of Community Bank — filed a Form 8-K with the SEC disclosing an internal incident involving non-public customer information “handled using an unauthorized artificial intelligence-based software application.” The disclosed data included customer names, Social Security numbers, and dates of birth. The filing does not name the specific AI tool involved. It’s the first SEC filing to formally characterize an incident this way, and a template other breached companies may follow.

How do vibe-coded apps relate to Shadow AI?
Vibe coding — the practice of building functional applications through natural-language instructions on platforms like Lovable, Replit, or Base44 — turns employees into software authors. When employees build AI-powered internal tools, load them with corporate data, and deploy them to public URLs without IT involvement, those applications become Shadow AI assets. Red Access research identified more than 380,000 vibe-coded applications on the open web; about 5,000 originated inside corporate environments, and more than 2,000 held sensitive business data accessible to anyone with the URL.

---

Read the research: The Shadow Builders Inside Your Organization — Red Access’s full report on how vibe-coded applications are being built, deployed, and exposed inside and outside enterprises today. Download the report →