Shadow AI vs Shadow IT: Which Controls Carry Over

Most organisations meet shadow AI with the shadow IT playbook they already own, and find that it covers the tool but misses the prompt, the OAuth grant and the agent. Shadow IT is about an unknown asset holding company data. Shadow AI adds three things: data that leaves inside free text the moment a user types it, delegated access that lets an outside service read and act on corporate accounts long after the browser tab is closed, and agents that run with a user's or a developer's credentials on local machines. This guide compares the two problems control by control, shows which shadow IT controls carry over unchanged, which need extending and which do not apply, and gives a decision checklist and a worked scenario. It is written for security architects, SaaS and identity owners and AI governance leads who already run some form of shadow IT programme.

Key takeaways

The asset model breaks first. Shadow IT asks "which app holds our data?"; shadow AI also asks "what did users type into it, what can it reach through our accounts, and what can it do?"
Inventory, procurement and no-blame culture carry over. The NCSC advice on asset registers, fast request handling and avoiding punishment applies to AI tools as it does to any unsanctioned service.
App-level allow and block decisions are not enough. A prompt can carry source code to an allowed domain, and an OAuth grant keeps working after the website is blocked.
OAuth grants and agent credentials are non-human identities. Treat each grant, API key and MCP server token as an identity with an owner, scope, expiry and revocation path.
Govern by the path, not only the tool. A sanctioned route with corporate sign-in, admin-approved consent and an AI gateway for API traffic removes most of the reason for shadow use.

The short answer

Keep your shadow IT programme and extend it in four places. First, add content-aware controls for prompts and uploads, because the data loss happens inside allowed sessions. Second, put OAuth consent under admin control and review existing grants to AI apps, because a grant is a standing credential. Third, inventory agents, MCP servers and model provider API keys on endpoints and in code, because they never appear in proxy logs as a "cloud app". Fourth, publish a sanctioned path that is easier than the shadow one. The overview of what goes wrong is in Top 10 Shadow AI Risks; this page is about which controls to reuse and which to add.

Shadow IT and shadow AI side by side

The NCSC describes shadow IT as the unknown assets used within an organisation for business purposes, and now includes unauthorised AI tools in that definition. The overlap is real, but the risk sits in different places.

Dimension	Shadow IT	Shadow AI
Typical asset	Unmanaged device, file-sharing or project SaaS, personal cloud storage	Consumer chatbot, AI feature inside sanctioned SaaS, browser extension, coding assistant, local agent or MCP server, personal model API key
How data leaves	Files uploaded or synced, usually as whole documents	Free text pasted into prompts, file uploads, connectors that pull data on demand, agents that read repositories and mailboxes
Where data ends up	Stored in the service, retrievable and deletable	Prompt logs, retention under the vendor's terms, possibly training data; the Samsung case showed pasted code could not be retrieved
Access the tool gets	Usually only what the user uploads	Often delegated OAuth scopes on mail, files and calendars; agent tools that can write, send and execute
Identity involved	User account in the unsanctioned service	User account plus OAuth refresh tokens, API keys and agent credentials that act without the user present
Can it act on systems?	Rarely	Yes, through tools and plugins; OWASP LLM06:2025 Excessive Agency describes the risk
Discovery signal	Proxy and firewall logs, CASB catalogue match, expense claims	Same, plus OAuth grant logs, browser extension inventory, endpoint process and configuration files, code and CI scanning for provider keys
Speed of change	New apps appear, but feature sets are fairly stable	New tools weekly; vendors add connectors and agent features to already approved apps
Main remediation	Migrate data, approve or block the app	Revoke grants and keys, steer to a sanctioned tenant or gateway, restrict consent, coach on prompt content

What changes: data flows into prompts

Threat model: the leak is a typing action, not a file transfer. A developer pastes a function to fix a bug, an analyst pastes a customer list to summarise it, a manager pastes meeting notes. OWASP LLM02:2025 Sensitive Information Disclosure notes that users need to understand the risk of unintentionally providing sensitive data that may later be disclosed in model output, and that application owners should offer terms that let users opt out of training on their data. In the Samsung ChatGPT source code leak, staff entered equipment measurement source code, yield analysis code and a meeting transcript within weeks of the tool being allowed, and the company said the data could not be retrieved.

Why shadow IT controls miss it: a CASB or secure web gateway that allows or blocks by app sees a permitted session to an AI domain and records nothing about the content. File-based DLP rules tuned for attachments and uploads do not see text typed or pasted into a web form unless an inline or browser control inspects it.

Controls to add:

Inline prompt inspection: DLP that inspects paste, typed input and upload events in the browser or at an inline proxy with TLS inspection, with policies for source code, credentials and regulated personal data. See GenAI DLP vs Traditional DLP.
Vendor terms as a control: record training use, retention and data location for each AI service in the app register; these terms decide whether a stance is acceptable.
Coaching at the moment of use: a prompt that names the approved alternative changes behaviour more than an annual training slide. See Block vs Sanction vs Coach.

Failure modes: blocking the best-known chatbot while leaving dozens of smaller tools open; relying on a system prompt or vendor promise as the only data control; and DLP rules that match keywords but not code or structured identifiers.

What changes: OAuth grants and agent access

Threat model: many AI productivity tools ask to connect to a mailbox, drive or calendar. The user clicks consent once, and the vendor now holds a refresh token that reads corporate data continuously, with no browser session to observe. If the vendor is breached, that token becomes the attacker's. In the Vercel Context.ai OAuth breach, an employee had granted a consumer AI suite full access to a corporate Google account; after the AI vendor was compromised, a stolen token was used to take over that account and pivot into Vercel. ATT&CK models these steps as T1528 Steal Application Access Token and T1550.001 Application Access Token.

Why shadow IT controls miss it: network discovery sees the user visit the AI site once; the ongoing API calls run between the vendor's cloud and your SaaS provider and never cross your proxy. Blocking the domain afterwards does not revoke the grant.

Controls to add:

Restrict high-risk scopes: in Google Workspace, API controls let admins mark apps Trusted, Limited or Blocked, set the behaviour for unconfigured third-party apps, and set Gmail and Drive to Restricted for high-risk OAuth scopes; switching a service to Restricted revokes tokens of untrusted apps that use it. See How to Inventory third party oauth apps in google workspace.
Restrict user consent: in Microsoft Entra ID, Microsoft recommends allowing user consent only for apps from verified publishers, for permissions you classify as low impact (the built-in policy microsoft-user-default-low), with the admin consent workflow enabled so users can request review. Changes apply only to future consent; existing grants stay in place and must be reviewed separately. See the Entra ID Applications and Consent Guide.
Treat grants as identities: each AI app grant gets an owner, a scope review and an expiry, and is revoked when the vendor reports a breach or the app falls out of use. See the SaaS and OAuth App Governance Guide.
Agents and MCP: the MCP authorisation specification (version 2025-06-18) requires clients to send RFC 8707 resource indicators and servers to accept only tokens issued for themselves; token passthrough is forbidden. The MCP security best practices also require one-click local server installs to show the exact command and get explicit consent, and recommend sandboxing local servers with minimal privileges. Shadow agents rarely meet these expectations, which is why they belong in the sanctioned path. See the MCP Security Guide.

Failure modes: tightening consent settings and assuming old grants disappeared; approving an AI app once and missing the connector and agent features the vendor adds later; and personal model API keys used for company work, billed to a personal card and invisible to every corporate control. See the LLMjacking Guide.

What changes: discovery methods

Shadow IT discovery relies mostly on traffic logs matched against an app catalogue. CASB cloud discovery typically builds reports from uploaded or forwarded firewall and proxy logs, or from endpoint agents, scores each app against a vendor risk catalogue, and only recognises apps that are in that catalogue. That method still finds the large consumer AI services. It misses the rest.

Shadow AI form	Seen by traffic logs and CASB catalogue?	Signal that finds it
Consumer chatbot in the browser	Yes, if the device routes through the proxy	SWG or CASB app category, DNS logs
Personal account on an approved AI service	Domain only; the NCSC notes a CASB cannot see unapproved use of approved services without intercepting encrypted traffic	Tenant or instance restrictions with TLS inspection, sign-in logs
AI feature inside sanctioned SaaS	No, it uses the SaaS vendor's domain	SaaS admin settings review, vendor release notes
AI app with an OAuth grant	One visit at most	IdP and SaaS OAuth grant inventory, audit logs for consent events
AI browser extension	Partly, depending on API domains	Managed browser extension inventory. See the AI Browser Extensions Security Guide
Local agent, coding assistant or MCP server	Rarely	EDR process and file telemetry, MCP configuration files
Model provider API key in code or CI	Only as egress to an API endpoint	Secret scanning in repositories and pipelines. See How to find LLM API keys in code and CI

The trade-offs between network, browser and endpoint telemetry are covered in depth in Network vs Browser vs Endpoint Shadow AI Discovery and the Shadow AI Discovery Guide. The point for this comparison is that a shadow IT programme with only proxy-based discovery will report a falling shadow AI count while grants, extensions and agents grow.

Which shadow IT controls carry over

Shadow IT control	Verdict for shadow AI	What to change
Asset and app register	Carries over, extend	Add fields for training use, retention, connected data sources, OAuth scopes, agent capabilities and underlying model. NIST AI 600-1 GV-1.6-001 asks organisations to enumerate GenAI systems for the AI inventory
Procurement and vendor due diligence	Carries over, extend	NIST AI 600-1 GV-6.1-009 asks for GenAI to be built into due diligence, including embedded GenAI in software you already buy
Approved app list	Carries over	NIST AI 600-1 GV-6.1-007 suggests approved lists of GenAI providers and an inventory of third parties with access to organisational content
Acceptable use policy	Carries over, extend	Add prompt content rules, personal accounts and keys, agents. NIST AI 600-1 GV-6.1-010 covers updating acceptable use for GenAI
CASB or SWG app block	Partial	Useful for prohibited services; add tenant restrictions and inline content inspection
File-based DLP	Partial	Extend to paste and typed input in the browser
Device controls (802.1X, UEM)	Carries over	Unmanaged devices remain the main blind spot for both
No-blame reporting and fast approvals	Carries over unchanged	The NCSC notes punishment discourages reporting and that slow request processes drive shadow use
Data migration into supported platforms	Does not transfer well	Prompt data cannot usually be recalled; focus on prevention and grant revocation
Consent and OAuth governance	New for most programmes	Admin consent, scope restriction, grant review
Agent and MCP inventory	New	Endpoint and code discovery, sanctioned MCP registry or gateway

Sanctioned-path policy

The NCSC observes that shadow IT is rarely malicious and usually means sanctioned tools fall short. That is even more true for AI, where demand is high and tools change monthly. A sanctioned path is the set of approved routes for each kind of AI use, published so that the right route is also the easiest one.

Chat and writing: one or two enterprise AI tenants with single sign-on, contractual terms on training and retention, audit logging and tenant restrictions that block personal instances from managed devices.
Connected assistants: admin-approved OAuth apps only, with scopes reviewed against the use case and connected data sources limited to sites whose permissions have been cleaned up.
Developer and API use: model access through an approved AI gateway with workload identity or managed keys, spend limits and logging; personal keys blocked at egress where practical. See the AI Gateway and LLM Gateway Guide and Workload Identity vs API Keys for LLM API Access.
Agents and MCP servers: an internal registry of reviewed servers, sandboxed local execution and least-privilege scopes, with a request route for new ones.
Exceptions: a request form with a published turnaround, so a user with a real need asks instead of signing up.

Write the rules down in the Shadow AI Policy Template and the AI Acceptable Use Policy Template. Use AI Gateway vs CASB/SSE for Controlling Shadow AI to decide which enforcement point covers which route.

Decision criteria for small and large organisations

Small organisation, cloud identity, no proxy: start with identity controls, which are cheap and need no new tooling: restrict user consent, review OAuth grants, pick one sanctioned AI tenant, and publish the policy. Browser management with an extension allowlist is the next step.
Mid-size, SSE in place: add the generative AI app category to the existing SSE, turn on tenant restrictions for the sanctioned AI service, then extend DLP to paste and upload events.
Large or regulated: add an AI gateway for API traffic, EDR-based discovery of agents and MCP configuration files, secret scanning for model keys and a governance board that reviews new AI features in sanctioned SaaS.
High developer population: prioritise coding assistants, API keys and MCP servers over chatbot blocking; that is where the code and credentials are.
Strict data classes (source code, regulated personal data): block for all unsanctioned AI regardless of stance elsewhere, and enforce with content inspection, not only app rules.

Worked scenario

A 2,000-person software company runs a mature shadow IT programme: SSE with a CASB catalogue, an app register and quarterly reports. The quarterly report shows generative AI use falling after two chatbots were blocked. A review finds a different picture. Grant logs show 140 users have consented to AI note-taking and writing apps with mail and drive read scopes. The managed browser inventory shows eleven AI extensions with page-reading permissions. Secret scanning finds personal model provider keys in nine repositories. Developers run MCP servers locally that hold access tokens for the code hosting platform.

The response follows this page. Identity first: user consent is restricted to verified publishers and low-impact permissions with an admin consent workflow; every existing AI app grant is reviewed, and grants to apps with no business owner are revoked. Then the sanctioned path: an enterprise AI tenant with SSO, tenant restrictions and logging is announced on the same day the two chatbot blocks are replaced by coaching pages pointing to it. Developers get a gateway with team keys and spend limits; personal keys are revoked and rotated. An internal MCP registry is created, and EDR rules flag unreviewed MCP configuration files. Three months later the metrics, not the block count, show whether it worked.

Detection and measurement

Sanctioned share: proportion of AI sessions on sanctioned tenants versus all AI sessions seen.
AI OAuth grants without an owner: count of active grants to AI apps with no named business owner; target zero.
High-risk scope grants: grants to AI apps with mail, drive or write scopes, trended monthly.
Prompt DLP events: blocked and coached events for source code, credentials and personal data per 1,000 AI sessions.
Unmanaged agent footprint: endpoints with unreviewed MCP configuration or agent processes.
Exception turnaround: median days from AI tool request to decision.

Log consent events in the identity provider, grant changes in each SaaS platform, inline DLP decisions, and gateway requests with user or workload identity, and send them to the SIEM with a shared app identifier so a single AI service can be traced across all four.

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev 5	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A	ATT&CK
AI app and service inventory	ID.AM-02, ID.AM-04	CM-8, SA-9	2.1	A.5.9
Unsanctioned tools and use rules	PR.AA-05	CM-10, CM-11, AC-20	2.3	A.5.10, A.5.23
Prompt and upload data loss	PR.DS-01	AC-21	3.1	A.8.12	T1567
OAuth grants and agent access	PR.AA-05, GV.SC-04	AC-6, SA-9	6.1	A.5.15, A.5.19	T1528, T1550.001, T1199

Common failure patterns

Measuring blocks, not paths: a falling block count after a ban often means use moved to personal devices, as the NCSC warns when tools are locked down without alternatives.
Leaving old grants alive: consent settings changed, but existing AI app tokens kept working; the Vercel case shows what a forgotten grant can do after the vendor is breached.
Treating approval as permanent: a sanctioned SaaS tool adds an assistant with connectors, and nobody reviews it.
Missing developers: chatbots are blocked while personal API keys and local agents with repository tokens go unseen.
Punishing early reporters: disciplinary messages after the first incident stop the reporting that discovery depends on.

Practitioner checklist

Add AI-specific fields (training use, retention, scopes, connected data, agent capabilities) to the existing app register.
Restrict user OAuth consent and enable an admin consent workflow in every identity provider and major SaaS platform.
Review all existing grants to AI apps; revoke those without an owner or a current use case.
Extend DLP to paste, typed input and uploads in the browser for source code, credentials and personal data.
Turn on tenant restrictions for each sanctioned AI service so personal instances are blocked on managed devices.
Inventory AI browser extensions, local agents and MCP configuration files through browser management and EDR.
Scan repositories and pipelines for model provider keys and move API use behind an approved gateway.
Publish the sanctioned path with an exception route and a turnaround target, and keep a no-blame reporting message.
Report sanctioned share, ownerless grants and prompt DLP events monthly, not just block counts.

Shadow AI vs Shadow IT: Which Controls Carry Over and Which Fail