Shadow IT

Shadow AI: How to Detect, Manage and Reduce Unsanctioned AI Usage

Nikolai Fomm

COO and co-founder

August 24, 2026

minute of reading

What is shadow AI?
The three layers of shadow AI most teams never see
Shadow AI vs shadow IT: what actually changes
Why mid-market companies are the most exposed
The five real risks of shadow AI, ranked by likelihood
How to detect shadow AI with what you already have
Approve, restrict, replace or block: the arbitration grid
Governing AI usage continuously
Shadow AI and EU compliance: AI Act, GDPR, NIS2
Your first 30 days
How Corma helps you find and govern shadow AI
Frequently asked questions

Introduction

Something changed in the way IT teams talk about artificial intelligence over the past twelve months. The question stopped being "should we adopt AI?" and became "how many AI tools are already running here without our knowledge?"

The search data tells the same story. Google Ads volume for the query shadow ai in the United States rose from 1,600 monthly searches in July 2025 to 4,400 in June 2026, an increase of roughly 175 percent in a single year. The narrower query what is shadow ai followed the same curve, from 590 to 2,900 monthly searches. Nobody searches for a definition of a problem they do not already have.

Yet most of the content answering those searches was written for a different reader. It assumes a security operations centre, a cloud access security broker, a secure web gateway and a data loss prevention platform already in place. A 200-person company with three people in IT has none of that, and it still has the problem.

This guide takes a different route. It treats shadow AI as what it operationally is inside a mid-sized organisation: not a network filtering problem, but a SaaS and identity problem. That reframing matters, because it means you can start detecting shadow AI this week using systems you already pay for, which is what the rest of this article walks through. If you are looking for a broader overview of the risks shadow AI introduces, that companion piece covers the threat landscape in more depth.

What is shadow AI?

Shadow AI is the use of artificial intelligence tools, models or embedded AI features inside an organisation without the knowledge, review or approval of IT, security or data protection teams. It covers standalone applications such as a personal ChatGPT account used for work, AI features silently switched on inside software the company already licenses, and AI agents or integrations granted access to corporate data through OAuth.

The term borrows its structure from shadow IT, and the parallel is useful, but the two are not interchangeable. Shadow IT is a visibility problem about which applications exist. Shadow AI is a visibility problem about where your data goes. An unapproved project management tool holds the data your team puts into it. An unapproved AI assistant may transmit that data to a third-party model, retain it, and in some configurations use it for training.

That difference explains why shadow AI escalates faster than shadow IT ever did. Adoption requires no procurement, no installation and no budget. A browser tab and a work email address are enough.

What shadow AI is not

Three clarifications worth making early, because they shape how you respond:

It is not necessarily malicious. In the overwhelming majority of cases, employees adopting unsanctioned AI are trying to work faster, not trying to exfiltrate anything. Treating shadow AI as an insider threat problem produces the wrong policy.
It is not solved by a ban. Blocking known AI domains moves usage to personal devices and personal accounts, where you lose the last remaining visibility you had. The consensus across security vendors on this point is unusually strong.
It is not only about chatbots. The chatbot is the visible tip. The two layers underneath it are where the harder problems live, which is the subject of the next section.

The three layers of shadow AI most teams never see

Most published guidance on shadow AI describes a single category: employees using unapproved AI applications. That description covers perhaps a third of real-world exposure. In practice, shadow AI operates on three distinct layers, each requiring a different detection method.

The three layers of shadow AI

Standalone AI applications

An employee signs up to an AI service with a work or personal email and pastes company material into it. No procurement, no security review, no data processing agreement.

Detected by: browser telemetry, identity provider logs, expense data. Visibility: moderate.

AI features inside approved software

Your CRM ships AI summarisation. Your helpdesk adds an AI reply generator. The vendor was approved, the contract is signed, and the security review covered a product that no longer behaves the same way.

Detected by: vendor change tracking, contract and DPA review. Visibility: near zero. Invisible to network monitoring.

AI agents and OAuth integrations

An employee connects an AI assistant to Google Workspace or Microsoft 365 through a consent screen. Nothing was installed and no password was shared, but a token now allows a third-party model to read corporate mail, files or calendar continuously.

Detected by: third-party app grant review in the IdP admin console. Visibility: available today, and almost never checked.

Why this matters: most published guidance covers layer 1 only, which accounts for roughly a third of real exposure. Layers 2 and 3 require different detection methods, and layer 3 carries the highest severity because access is continuous rather than one-off.

Layer 1: standalone AI applications

The familiar case. An employee signs up to an AI service with a work email address or a personal one, pastes company material into it, and no procurement or security review ever happens. This layer is detectable through browser telemetry, identity provider logs and expense data.

Layer 2: AI features inside already-approved software

The blind spot almost nobody covers. Your CRM vendor ships an AI summarisation feature. Your helpdesk adds an AI reply generator. Your note-taking tool activates an AI assistant by default in a minor release. None of this appears in any application inventory, because the application was already approved. The vendor is on your list, the contract is signed, the security review was completed eighteen months ago against a product that no longer behaves the same way.

This layer is invisible to network monitoring, because traffic goes to a domain you already allow. It is only detectable through vendor change tracking and contract review, which is precisely why it goes unmanaged.

Layer 3: AI agents and OAuth integrations

The fastest-growing layer. An employee connects an AI assistant to Google Workspace or Microsoft 365 through an OAuth consent screen, granting it read access to mail, files or calendar. No software was installed. No password was shared. A token now allows a third-party model to read corporate data continuously.

This layer is the closest thing to a genuine emergency, and it is the one your identity provider can actually show you today. It also connects directly to the wider question of AI agent governance, which becomes unavoidable as agentic tools spread.

Shadow AI vs shadow IT: what actually changes

Shadow AI is a subset of shadow IT, but treating it as merely a new flavour of the same problem leads teams to reuse controls that do not transfer. The table below sets out where the two diverge.

Shadow AI vs shadow IT

Dimension	Shadow IT	Shadow AI
What is unmanaged	An application or device nobody approved	A data flow into a third-party model nobody approved
Barrier to adoption	Sign-up, sometimes install, often payment	A browser tab and a work email address
Primary risk	Data stored in an unvetted location	Data retained, processed, or used to train an external model
Where it hides	Outside the approved application list	Also inside already-approved software, as a new AI feature
Detected by	Application inventory, expense data	Inventory plus OAuth grant review plus vendor change tracking
Reversibility	Revoke access and the data stays with the app	Revoking access does not retrieve data already submitted
Offboarding exposure	Account known, usually revoked	Account unknown, so it survives the departure
Regulatory frame	GDPR, ISO 27001, NIS2	GDPR, ISO 27001, NIS2, plus the EU AI Act
Core takeaway	Inventory the applications	Inventory the data flows and the granted permissions

The practical consequence: an application inventory is necessary but no longer sufficient. You need an inventory of data flows and granted permissions, not just of installed software. This is the same structural shift that made SaaS sprawl a governance topic rather than a licensing one.

Why mid-market companies are the most exposed

Companies between 50 and 500 employees sit in the worst possible position on shadow AI, for four structural reasons.

Enough autonomy to adopt, not enough process to govern. Teams have budget authority and tool freedom. Departmental purchasing is normal. Nobody centrally reviews a 20 euro monthly subscription.
No dedicated security function. IT is typically two to five people covering support, infrastructure, networking and compliance. There is no analyst whose job is to watch AI adoption.
None of the tooling the literature assumes. No CASB, no SWG, no SOC, no dedicated DLP. The controls recommended by most published guidance are simply not available.
Real regulatory exposure regardless. A 200-person European company processing customer data falls under GDPR in full. If it operates in a covered sector, NIS2 applies too. Company size reduces neither obligation.

The result is a governance gap that widens by itself: adoption accelerates, oversight capacity stays flat.

The five real risks of shadow AI, ranked by likelihood

Most risk lists on this topic rank by severity, which produces a catalogue of worst-case scenarios that few teams recognise. The ranking below is by likelihood, which is more useful when deciding what to fix first.

1. Data exposure through prompts (near certain)

The default assumption should be that it is already happening. Employees paste customer records, contract clauses, source code and financial figures into AI interfaces because it is the fastest way to get an answer. Reporting by Infosecurity Magazine in September 2024 found that 38 percent of employees admitted sharing sensitive work information with AI tools without their employer's permission. That figure predates the current adoption wave, so treat it as a floor rather than a current estimate.

2. Regulatory exposure under GDPR and the EU AI Act (high)

Where personal data enters an AI tool with no data processing agreement, no documented transfer mechanism and no record in your processing register, you have a compliance gap that predates any breach. Under Article 83(5) of the GDPR, the upper tier of administrative fines reaches 20 million euros or 4 percent of total worldwide annual turnover, whichever is higher. The exposure is not theoretical simply because no incident has occurred yet.

3. Orphaned AI accounts after offboarding (high, and almost never checked)

This risk appears in virtually no published guidance on shadow AI, which is remarkable given how mechanical it is. An employee creates an AI account tied to their work email. They leave. Their mailbox is deactivated, their SSO access is revoked, and the AI account remains active, holding whatever they put into it, sometimes still billed to a company card. Because the tool was never inventoried, it never enters the offboarding checklist and never appears in an access review.

Any organisation running structured automated onboarding and offboarding closes this gap by design. Organisations relying on a manual checklist do not, because the checklist only covers known applications.

4. Uncontrolled and duplicated AI spend (high)

Shadow AI is treated almost universally as a security topic, which hides its financial dimension. The same organisation frequently pays for three overlapping AI subscriptions across three teams, at individual seat pricing, on personal cards reimbursed through expenses. Nothing appears in the software budget because nothing was procured. Bringing this into view is the purpose of dedicated AI spend management.

5. Output quality and decision risk (moderate)

Unreviewed model outputs entering client deliverables, financial analysis or code carry error and bias risk that no one has assessed. Real, but slower-moving than the four above, and more effectively addressed by training than by tooling.

How to detect shadow AI with what you already have

This is where most guidance stops at "monitor network activity" and moves on. Here is the operational version, built around five data sources a mid-sized company already owns. No new security platform is required to complete the first pass.

Five sources you already own to detect shadow AI

Source	Where to look	What it reveals	What it misses
1. OAuth grants Highest yield, start here	Google Workspace admin console, third-party app access. Microsoft Entra ID, enterprise applications	Every AI tool already authorised to read your mail, files or calendar, plus the scope granted and who granted it	Tools used without any connection to your tenant
2. Identity provider logs	Sign-in and application logs in Google Workspace, Entra ID, Okta or JumpCloud	AI tools accessed through corporate SSO, with frequency and user counts	Anything accessed with a personal email or a standalone password
3. Spend and card data	Expense reports, corporate card statements, accounts payable, app store receipts	Paid AI subscriptions bought outside procurement, including duplicates across teams	Free tiers, which is where the majority of shadow AI sits
4. Browser and endpoint telemetry	Managed browser reporting, endpoint agent, DNS or proxy logs if available	Actual visits to AI domains on managed devices, including free usage	Personal devices, and anything on a network you do not control
5. HR to access reconciliation	Leaver list from your HR system, matched against every account discovered above	Orphaned AI accounts still active after an employee has left	Accounts created on personal emails with no corporate trace
Combined	Reconcile all five	A defensible inventory across the three layers of shadow AI	Residual gap: personal devices on personal networks

Two principles govern how these sources combine.

Start with OAuth grants, not with network logs. Reviewing third-party application access in your Google Workspace admin console or Microsoft Entra ID enterprise applications panel takes under an hour and surfaces the highest-severity layer of shadow AI: tools already authorised to read corporate data. Most teams have never opened this screen. It is the single highest-yield hour available on this topic.

Reconcile identity against spend, then against usage. Each source alone produces an incomplete picture. Your identity provider shows what people log into through SSO but misses everything using personal credentials. Expense data catches paid tools but misses free tiers, which is where most shadow AI lives. Browser telemetry catches free usage but not what happens on personal devices. Overlapping three sources converts a partial list into a defensible inventory, and this reconciliation logic is exactly what a SaaS management platform automates.

A structured discovery pass typically surfaces two to three times more AI tools than the IT team expected. That gap, not any single tool, is the finding that changes the conversation with leadership.

Approve, restrict, replace or block: the arbitration grid

Discovery produces a list. A list without a decision rule produces paralysis, which is why so many shadow AI programmes stall after the audit. Every credible source agrees that banning outright backfires, but almost none supply the criteria for what to do instead.

Four outcomes cover every discovered tool. The determining variables are the sensitivity of data involved and whether a sanctioned equivalent exists.

Shadow AI arbitration grid: what to do with each discovered tool

Decision	Apply when	Concrete actions	Owner
Approve	Real business value, low data sensitivity, or an enterprise plan with a data processing agreement is available	Move to a business tier, sign the DPA, enable SSO, add to the inventory, include in access reviews and offboarding	IT plus data protection
Restrict	Genuine value but sensitive data involved, and usage can be scoped to a defined team or use case	Limit to a named group, define which data classifications are permitted, disable training on your data, log usage	IT plus the requesting team lead
Replace	An approved tool already covers the need, or several teams pay for overlapping tools	Consolidate onto one contract, migrate users, cancel duplicate subscriptions, capture the saving	IT plus finance
Block	No acceptable data terms, no business case, or regulated data would leave the EU without a transfer mechanism	Revoke OAuth tokens first, then remove access, and name the approved alternative the same day	IT plus security
Rule that makes it work	Never block without naming a replacement. A block with no alternative is a request to work slower, and it will be bypassed.		IT leadership

Two rules make this grid work in practice.

Every block needs a named alternative on the same day. A block without a replacement is a request that people work slower, and it will be ignored. This is the single most common failure mode in AI policy rollouts.
Consolidation is where the budget argument lives. Three teams paying for three similar AI tools become one contract with volume pricing, central administration and a data processing agreement. The cost saving funds the governance work, which is what makes the programme survive its first budget review.

Governing AI usage continuously

A one-off audit has a shelf life of roughly a quarter in this category. Governance means the inventory maintains itself. Four mechanisms carry the load.

A live AI application inventory. Not a spreadsheet refreshed when someone remembers. Continuous discovery, so a new AI tool appears in the inventory within days of first use rather than at the next audit.

AI tools inside access reviews. If your automated access reviews cover only your core systems, every AI tool is out of scope by default. Adding them turns a periodic compliance exercise into the mechanism that catches orphaned accounts and over-privileged integrations.

AI tools inside the joiner-mover-leaver process. Every AI account discovered should enter the offboarding sequence immediately. When user provisioning and deprovisioning run on automation rather than a manual list, coverage extends to newly discovered tools without anyone rewriting a procedure.

A policy that permits rather than forbids. The AI usage policies that hold up in practice name what is approved for which data classification, explain the reasoning, provide a fast route to request something new, and get refreshed quarterly. Policies built as prohibition lists age badly and are routinely bypassed.

Shadow AI and EU compliance: AI Act, GDPR, NIS2

For European companies, shadow AI sits at the intersection of three regulatory frameworks that arrived within eighteen months of each other. Each imposes an obligation that ungoverned AI use directly undermines.

Shadow AI under EU regulation: what each framework requires

Framework	Relevant obligation	How shadow AI breaks it	What closes the gap
GDPR	Lawful basis, processor agreements, documented transfers, records of processing. Fines up to 20 M EUR or 4 percent of worldwide turnover under Article 83(5)	Personal data enters an AI tool with no DPA, no transfer mechanism and no register entry. The gap exists before any breach	Inventory of AI tools, a signed DPA per approved tool, register updated, transfers documented
EU AI Act	AI literacy obligation for staff using AI systems (Article 4), plus transparency duties depending on system category	You cannot train staff on systems you do not know they use, and cannot classify what is not inventoried	A maintained AI system inventory, a usage policy per data classification, documented staff training
NIS2	Risk management measures, supply chain security and incident reporting for covered entities	Unknown AI vendors are unassessed third parties inside your supply chain, and outside any incident scope	Third-party AI tools brought into the vendor risk process and the incident response plan
ISO/IEC 27001:2022	Annex A control A.5.23, information security for the use of cloud services	Unsanctioned AI services are cloud services acquired with no control, no review and no owner	AI tools treated as in-scope cloud services, with an assigned owner and periodic review
Common precondition	All four obligations depend on the same thing: an inventory. Discovery is a compliance activity, not only a security one.

The through-line across all three is that you cannot document, assess or report on AI usage you have not inventoried. Every one of these obligations has an inventory as its precondition, which is why discovery is a compliance activity and not just a security one.

Data residency deserves its own note. When an employee uses a consumer AI service, the processing location is whatever the vendor's default is, typically outside the European Union, with no transfer mechanism documented on your side. For organisations that have committed to EU data residency contractually or in a certification scope, shadow AI can quietly invalidate that commitment. Corma addresses this at the platform level: data is hosted in the European Union and the platform is certified to ISO/IEC 27001:2022, whose Annex A control A.5.23 covers information security for the use of cloud services, the exact category unsanctioned AI tools fall into. Teams working through NIS2 requirements will recognise the same inventory dependency there.

Your first 30 days

A sequence that produces a defensible inventory and a first set of decisions inside a month, with no new tooling in weeks one and two.

Shadow AI: your first 30 days

Window	Action	Output
Days 1 to 3	Open the third-party application access screen in your identity provider. Review every AI tool holding an OAuth grant, note the scope and the requester. Revoke anything with write access nobody can justify	A first list of the highest-severity exposure, produced in under an hour of work
Days 4 to 10	Pull identity provider sign-in logs and twelve months of expense and card data. Search for known AI vendors and for recurring small subscriptions	A combined list of SSO-accessed and paid AI tools, with duplicates flagged
Days 11 to 15	Review your top ten SaaS vendors for AI features added since their last security review. Check release notes and the current DPA	The layer 2 inventory: AI running inside software you already approved
Days 16 to 20	Match every discovered account against the leaver list from your HR system	Orphaned AI accounts identified and closed
Days 21 to 25	Run each tool through the arbitration grid: approve, restrict, replace or block. Name a replacement for everything blocked	A decision per tool, with an owner and a date
Days 26 to 30	Publish a one-page AI usage policy stating what is approved for which data classification, plus the request route for new tools. Add every approved AI tool to access reviews and to the offboarding sequence	Governance that runs without a second audit
End of month 1	Inventory built, decisions taken, controls wired into existing processes	Continuous discovery replaces the one-off audit

How Corma helps you find and govern shadow AI

Shadow AI is a discovery problem followed by an identity problem. Corma is a European platform that covers both in one place, which is the reason it appears on this topic at all: most vendors address either the SaaS visibility side or the access governance side, not the two together.

Continuous SaaS and AI discovery. Corma builds and maintains the inventory across the three layers described earlier, including OAuth-connected applications and integrations reaching into your Google Workspace or Microsoft 365 tenant. This is the full visibility layer that prevents shadow IT from becoming permanent, applied to AI tools.
Native identity provider connectors. Google Workspace, Microsoft Entra ID, Okta and JumpCloud connect directly, so the reconciliation between identities, applications and permissions happens without manual exports.
Converged SaaS management and IAM. Identity and access management and SaaS management operate on the same inventory, which is what allows a newly discovered AI tool to enter access reviews and offboarding automatically rather than through a separate process.
Spend visibility alongside risk. Duplicate and orphaned AI subscriptions surface next to the security findings, which typically funds the governance work rather than competing with it.
European by construction. EU data hosting, GDPR alignment, ISO/IEC 27001:2022 certification and NIS2-ready reporting, without the transfer questions a United States platform raises. Corma was also recognised in the 2025 Gartner® Magic Quadrant™ for SaaS Management Platforms.
Deployment measured in weeks. Full onboarding for a mid-sized company typically completes in under a month, which matters when the inventory is the blocker on everything else.

For a concrete example in a regulated environment, the identity governance deployment at Satelia shows how discovery and access governance work together in healthcare.

See your own AI and SaaS inventory before deciding anything: request a Corma demo.

Frequently asked questions

What is an example of shadow AI?

The most common example is an employee using a personal ChatGPT or Claude account to summarise internal documents or draft client-facing material, with no IT approval and no data processing agreement in place. Two less obvious examples matter more: an AI feature activated by default inside software your company already licenses, and an AI assistant granted OAuth access to your Google Workspace or Microsoft 365 data through a consent screen.

What are the main risks of shadow AI?

Five, ordered by how often they actually occur: sensitive data exposure through prompts, regulatory exposure under GDPR and the EU AI Act, orphaned AI accounts that survive employee offboarding, duplicated and uncontrolled AI spend, and unreviewed model outputs entering business decisions. The third and fourth are the ones most organisations have never checked.

How do you detect shadow AI?

Start by reviewing third-party OAuth application grants in your identity provider admin console, which takes under an hour and surfaces the highest-risk category. Then reconcile three data sources: identity provider sign-in logs, expense and card transaction data, and browser or endpoint telemetry. No single source is complete, so the overlap is what produces a reliable inventory. A SaaS management platform automates this reconciliation continuously.

What is the difference between shadow AI and shadow IT?

Shadow IT is the use of any unapproved software or hardware. Shadow AI is the narrower case of unapproved AI tools and features, and it carries two risks shadow IT does not: data submitted in prompts may be retained or used for model training by a third party, and AI capabilities can appear inside software you already approved, making them invisible to an application inventory.

Should we simply ban AI tools at work?

No, and the evidence on this is consistent across security vendors. Blocking known AI domains pushes usage onto personal devices and personal accounts, where you lose visibility entirely. The approach that works is to inventory what is in use, approve a small set of tools with proper contractual terms for each data sensitivity level, and publish a fast approval route for anything new.

Why do employees use unsanctioned AI tools?

Speed, almost always. They are trying to finish work faster, not to bypass security. The three recurring drivers are time pressure, the absence of an approved tool that does the job, and no awareness that pasting company data into a consumer AI service creates a compliance problem. This is why an AI policy that only prohibits fails: it addresses none of the three.

Does shadow AI affect GDPR or EU AI Act compliance?

Yes, on both counts. Under GDPR, personal data entering an AI tool without a data processing agreement, a documented transfer mechanism or an entry in your processing register is a gap that exists before any breach occurs, with fines reaching 20 million euros or 4 percent of worldwide annual turnover under Article 83(5). Under the EU AI Act, the AI literacy obligation in Article 4 assumes you know which AI systems your staff use, which is impossible without an inventory.