What is shadow IT? Meaning, risks and how shadow AI changes it

Shadow IT is any app, device, cloud account or service that runs without IT's approval. With AI tools, people can create and build more easily than before, publishing apps in days, so more gets built and potentially forgotten, amplifying risk.

The business risk sits in what nobody owns, such as hosts nobody patches, databases anyone can read and subdomains left behind after a project ends.

To find shadow IT, check what is visible from the internet and what your cloud bills, code repositories and teams can tell you. Compare both with your inventory, then give each unknown asset an owner or shut it down. This guide covers what counts as shadow IT and shadow AI, the risks for the business, and how to handle each one with vulnerability management.

What is shadow IT, and what is shadow AI?

Shadow IT is technology used inside an organisation without IT's knowledge or approval. The UK National Cyber Security Centre (NCSC) defines shadow IT as "the unknown assets that are used within an organisation". Shadow AI is the AI part of the same problem.

Approval is the test. It does not matter who built the tool, or with what. A SaaS sign-up, a spreadsheet automation and a full web app all count if IT does not know they exist.

Examples of shadow IT

Common examples of shadow IT include:

• SaaS sign-ups: a team pays for a project tool on a company card.
• Personal cloud storage: staff move work files to a private account to share them faster.
• Devices: a router, storage box or test server gets plugged in without a ticket.
• Cloud accounts: a developer opens a side account to test an idea, and it keeps running.
• Apps and automations built outside IT: marketing publishes a campaign app, or finance builds a workflow that reads the accounting system.

Personal cloud storage is easy to miss because it looks like normal work. In Netskope's 2026 telemetry from its own customers, 31% of users in the average organisation uploaded data to personal cloud apps every month.

Where shadow AI fits

Shadow AI is AI use that IT has not approved. The NCSC describes shadow AI as "the use of AI technology which isn't captured in an organisation's approved systems and processes." It covers chat assistants, AI note-takers, automations and add-ons connected to approved tools.

The same approval test applies. An app built with approved AI coding tools, and approved by IT, is neither shadow IT nor shadow AI. It is ordinary software that still needs the same security checks as any other app.

How AI is boosting shadow IT

AI is boosting shadow IT by cutting the effort it takes to adopt a tool or build an app without IT. Anyone can sign up for an assistant in minutes, and a small team can ship a working app in days. It is the same old shadow IT, moving faster and with more parts.

AI use keeps growing even where companies have rules. Netskope's Cloud and Threat Report 2026 found that users of SaaS generative AI (genAI) apps tripled in a year, while prompts grew sixfold. Netskope says this happened "despite increased controls and governance around managed genAI applications."

GenAI app users tripled in a year, and prompts grew sixfold. The growth came despite more controls on company-approved AI apps.

People also bring their own tools. Microsoft and LinkedIn's 2024 Work Trend Index is a vendor survey of 31,000 people in 31 countries. It found that "78% of AI users are bringing their own tools to work".

Building has become cheap as well. Many apps, automations and agents built with AI coding tools outlive the project, and some keep running after the person who built them has left.

Approved does not mean safe, either. An approved AI tool can still connect to data, code or accounts that nobody reviewed. More people using and building with AI means more assets and data flows to track, and that can widen a company's attack surface.

What are the risks of shadow IT?

The main risk of shadow IT is that nobody looks after it. An asset IT does not know about gets no patches, no monitoring and no owner. If an attacker finds it first, the business pays for a system it did not know it had.

Exposed hosts nobody patches

Unknown servers and services miss every patch cycle. The NCSC says it has supported incidents on systems unknown to security and IT teams. Its guidance on responding to active exploitation advises checking shadow IT and development environments that sit outside normal scanning coverage.

Those missed patches give attackers a way in. The Verizon 2026 Data Breach Investigations Report found that exploiting a vulnerability is now the top way attackers first get in, ahead of stolen credentials.

Vulnerability exploitation is now the number one initial access vector for breaches. It overtook stolen credentials in the 2026 report.

Attack surface monitoring finds internet-facing hosts and services that are missing from your inventory, within the scope you set.

Forgotten subdomains taken over

A subdomain can outlive the service behind it. If its DNS (Domain Name System) record points to a deleted cloud resource, an attacker may claim it and serve content under your name.

The EU Agency for Cybersecurity (ENISA), citing third-party research in its ENISA Threat Landscape 2026, describes a group called Hazy Hawk. It hijacks abandoned subdomains of real organisations to host scams and malware. Our case study on how forgotten subdomains become breach paths shows another way an old subdomain turns into an entry point.

Open databases and keys in code

Apps built quickly outside IT often run on a hosted backend. Supabase backends are common in apps built with tools such as Lovable or Bolt. Supabase's own production checklist warns that "some AI tools embed API keys directly in code that users can access."

Three exposures are worth checking first:

• Tables readable without login: the Supabase row level security docs say "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." RLS (row level security) is the set of rules that decides who can read each row.
• Public storage buckets: in a public bucket, "anyone who possesses the asset URL can readily access the file", according to Supabase's storage docs.
• Secret keys in the app's code: the publishable key is meant to be public, but a secret key "bypasses every Row Level Security policy you have."

CVE-2025-48757, a Common Vulnerabilities and Exposures entry published on 30 May 2025, describes weak row level security in sites generated by one AI coding platform. The supplier disputes it, so treat it as an example of what to check. It does not show how common the problem is.

Before you call an exposure a flaw, ask whether it is meant to be public. A product page or a publishable key can be public by design.

Vornin's Supabase exposure checks look for all three issues on projects hosted on Supabase's own cloud. The checks are read-only, so nothing is written to the database.

Company data pasted into AI tools

Shadow AI also moves data out of the business. Netskope's 2026 telemetry counted an average of 223 genAI data policy violations per month, committed by 3% of genAI users on average. Netskope calls that figure likely an underestimate.

Source code made up 42% of those violations, ahead of regulated data and intellectual property. Netskope also found that 50% of organisations lack enforceable data protection policies for genAI apps.

No vulnerability scanner sees this risk, Vornin included. The controls that address it are a clear AI policy, approved tools people want to use, SaaS and browser controls, and data loss prevention.

Inventory duties under NIS2, DORA and ISO 27001

Shadow IT can also become a compliance gap. The NIS2 Directive lists asset management among its required security measures in Article 21(2)(i). Our guide to NIS2 compliance covers the other measures.

For DNS, cloud, data centre and managed service providers, the NIS2 implementing regulation (EU) 2024/2690 goes further. It asks for "a complete, accurate, up-to-date and consistent inventory of their assets".

Financial entities face a similar duty under DORA Article 8(4). They "shall identify all information assets and ICT assets", where ICT means information and communication technology.

ISO 27001:2022 has a matching control, A.5.9 "Inventory of information and other associated assets". For organisations outside those laws, the Center for Internet Security's CIS Control 1 asks them to "Actively manage (inventory, track, and correct) all enterprise assets".

Unknown means unranked

Every way to prioritise starts from a list of known assets. Severity scores, exploit data and fix deadlines only apply to assets someone has recorded. A host missing from the inventory never reaches the top of anyone's queue, however exposed it is.

How to detect and manage shadow IT

You detect shadow IT by comparing what exists with what your inventory says exists. To manage it, you find it, give it an owner, rank it by risk, fix it and keep the proof, the same loop vulnerability management already uses.

IT's job here is to know the attack surface well enough to secure it, without stopping people from building.

Find it

Start from the outside. Discovery from DNS records, certificate transparency logs (public logs of issued website security certificates) and passive sources shows which subdomains and services carry your name. The NCSC's shadow IT guidance agrees that "Security people should focus on finding where shadow IT exists".

Then look inside. Scan your own networks, including private ones, and check cloud accounts and code repositories for projects nobody registered. Some shadow IT never touches your DNS, so reconcile procurement records and cloud billing with your asset records and ask each team what they run.

Vornin's automatic subdomain discovery covers the outside view within your configured scope. Remote agents scan private networks without inbound firewall changes. Vornin also scans AWS, Azure and Google Cloud accounts and GitHub, GitLab or Azure DevOps repositories you connect. Billing checks and team interviews stay manual.

Give it an owner or shut it down

Every asset you find needs a named owner, or it gets shut down. When you shut something down, delete its DNS records too, or the subdomain stays open for takeover.

Ownership has to survive staff changes. When an owner leaves, reassign their apps, automations and accounts as part of offboarding.

In Vornin, each discovered asset can be tracked, ignored or promoted to a scanned target, so the assets you keep stay in your regular scans.

Rank it by risk

Not every shadow asset matters equally. Rank each one by how exposed it is and what it can reach.

An automation that summarises a public chat channel is a small risk. One running on a service account with access to customer data is a large one.

Vornin gives each discovered asset a risk score from 0 to 100, so you know what to investigate first. Once an asset becomes a scanned target, its findings get priority bands from four signals:

• CVSS: the Common Vulnerability Scoring System, which rates how severe a flaw is.
• EPSS: the Exploit Prediction Scoring System, which estimates how likely exploitation is.
• CISA KEV: the US Cybersecurity and Infrastructure Security Agency's catalogue of Known Exploited Vulnerabilities.
• Reachability: whether your code uses a vulnerable dependency.

Ranking findings on these signals is risk-based vulnerability management, applied to assets that went around IT.

Fix it and prove it

A finding on a shadow asset follows the same path as any other. In Vornin, it is assigned to someone on the IT or security team, with a deadline set by an SLA (service level agreement). A rescan confirms the fix.

Network findings can also be re-tested on demand. Each confirmed fix is recorded in a tamper-evident audit trail.

Leaked keys need one extra step first. GitHub's documentation on leaked secrets says that "as a first step you need to revoke and/or rotate that secret." Deleting the file does not make the key safe. Vornin's secret scanning can find keys, and owners can then rotate them if exposed.

The full loop is set out in our guide to the vulnerability management lifecycle.

Prevent the next one

Prevention starts with an easy approved route. If registering a new app takes five minutes, people register it.

The NCSC's asset management guidance says asset information "should be collected before, or at the time of, first use". Its shadow AI blog advises organisations to "provide approved alternatives".

Then add checks to your release pipeline. Approved repositories can take in code faster than anyone can review it, which is a volume problem rather than shadow IT.

A pass or fail check in CI/CD (the automated build and release pipeline) can stop a release when findings reach a severity you choose. Secret scanning flags keys and tokens left in code.

Gate what goes through the pipeline. Discover what went around it. Vornin's secret scanning and CI checks handle the first half, and discovery handles the second.

Neither sees everything. Discovery works within the scope you configure, and SaaS and AI-tool usage sit outside it. An app outside that scope and outside your connected repositories is missed by both.

Frequently asked questions

Conclusion

Shadow IT is a long-standing problem, and shadow AI is a new type of shadow IT. AI lets people build software faster than ever, so more gets built and potentially forgotten, which raises risk. Analyse and keep track of your environment and attack surface. The main risk of shadow IT is what nobody owns or maintains, because a host missing from your inventory never reaches your patch queue. Compare what is visible from the internet with your inventory, then give each unknown asset an owner or shut it down. Start with the external attack surface, the subdomains and services running under your name, because that is what an attacker sees first.

Read-only access · Working scan data deleted after each scan · EU-hosted