Shadow AI Detection: How to Find Unsanctioned AI Use

According to a Gartner survey of cybersecurity leaders, 69% of organizations suspect or have evidence that employees use prohibited public generative AI. Gartner urged chief information officers to run regular shadow AI audits. Those audits depend on shadow AI detection, which finds the AI tools and integrations people use without approval.

This guide explains what shadow AI detection covers, which risks justify an investigation, and what each kind of evidence can and cannot prove. It also follows detection into embedded SaaS features and agents. It ends by tracing how findings become inventory records, permission reviews, and policies.

What Is Shadow AI Detection?

Shadow AI detection finds AI tools, features, accounts, and integrations people use without formal approval, then collects enough evidence about each to support a decision. Shadow AI is a subset of shadow IT that also covers unsanctioned SaaS applications. Its main risk lies in what people type into prompts and what an AI system can reach. Shadow AI takes five common forms, each leaving traces in different places:

• Standalone Chatbots and Personal Accounts: Employees use public generative AI through their own logins, outside enterprise identity controls.

• Browser Extensions: AI add-ons can read page content and sometimes change data on every site.

• Embedded SaaS Features: AI summarization, drafting, or search appears inside already-approved applications.

• Coding Assistants: These tools send code context, sometimes including credentials, to a cloud model.

• Agents and Third-Party Integrations: These connections act for a user through delegated OAuth tokens, API keys, or Model Context Protocol (MCP) servers.

An application inventory records what software exists but misses active AI features, personal-account sign-ins, and token-holding integrations, so detection has to reach below the app level. Abnormal's AI Governance can help at the application level by discovering approved and shadow AI tools and assigning an owner to each.

Which Shadow AI Risks Need Investigation?

Shadow AI risks justify an investigation when AI use could move sensitive data, credentials, or access outside the organization's control. Three hypothetical cases show how the needed evidence can differ:

• Customer Data in a Free Chatbot: An employee pastes a customer record into a free chatbot, which raises a disclosure question.

• Source Code in a Coding Assistant: A developer routes proprietary code, and any secrets in it, through a coding assistant.

• Audio in a Transcription Tool: A sales team's meeting-transcription tool sends audio and transcripts to a third party on every call.

Other risks concern reach rather than content, because broad OAuth permissions and autonomous agents keep acting on data after the session ends. AI proxies and aggregators hide that reach behind one outbound connection that relays requests to several models.

Traffic to an AI service establishes contact, but disclosure needs its own proof. A log entry showing a laptop reached a chatbot domain says nothing about what the employee typed. Proving sensitive data left takes content-level or permission-level evidence.

How Shadow AI Detection Methods Establish Evidence

Each shadow AI detection method establishes only part of the evidence (contact, attribution, permission, or content), so investigations combine sources. Content appears only through Transport Layer Security (TLS) inspection, endpoint data loss prevention (DLP), or platform logging set up in advance. Four method families differ in the telemetry they need, what they can prove, and where they go blind:

Across the four families, network and browser telemetry mostly establishes contact, and identity records establish attribution and permission.

Network and Browser Signals Depend on the Observed Path

Network detection works only on traffic that crosses a point the organization monitors. DNS resolver logs record which domains a host queried, and the Server Name Indication (SNI) field in a TLS handshake often carries the destination hostname. Detection tools match both against a catalog of known AI domains, so an uncatalogued service passes unnoticed until an analyst adds it.

Encryption erodes both signals, because DNS over HTTPS sent to an outside resolver removes the query from enterprise DNS logs unless policy forces it through the corporate resolver. ECH encrypts the SNI, so passive observers on the network no longer see the hostname.

Remote and personal devices whose traffic skips the corporate path leave no network record. TLS inspection can recover prompt content, though it carries security and privacy risks that some organizations judge too high.

From the device side, managed extensions and endpoint DLP can record visits to AI sites and audit or block pastes and uploads of sensitive content. These controls cover only enrolled devices and supported browsers with the extension installed, and they see nothing in an unmanaged browser or a personal profile.

Identity and API Logs Add Attribution and Permission Context

Identity and API records show who or what acted and what it may access, something network data cannot show. OAuth consent logs record which user authorized which application with which scopes.

Identity platforms can also export every user who authorized an app, and SSO sign-in logs show when people used onboarded apps. Because users often accept permission prompts without close review, a consent record is frequently the clearest view of what an AI integration can reach.

SaaS audit events and model-invocation logs extend attribution into specific platforms. Cloud control-plane logs can record calls to a hosted model, and invocation logging can capture full requests and responses. On some platforms, invocation logging is off by default, so prompts go unrecorded until an administrator turns it on.

Identity and API logs see only the systems that produced them. An employee who signs up for an AI service with a personal email never appears in the IdP, and apps outside SSO leave no sign-in trail. Each provider's logs cover only its own platform, and shared API keys blur who made a given call.

Why Approved Apps Can Hide Active AI Features and Agents

Finding an approved application or known AI destination does not show which AI features inside it are active or which agents act through it. At an ISC2 panel on AI sprawl, Dheeraj Gurugubelli of EY-Parthenon described a healthcare company whose AI inventory turned up more than 80 agents in its sales organization alone, all spawned from one approved tool. Network, browser, identity, and platform signals locate the application, and feature-level and permission-level review looks inside it.

Embedded SaaS Features Can Outrun the Approved App Inventory

Embedded AI features can arrive through routine updates to sanctioned apps, so an app's approval may not cover the AI inside it. A hypothetical collaboration application, approved years ago, adds AI meeting summaries and drafting in a recent update. Network logs show the same domains as before, and the inventory still lists the app as approved, yet content may now flow to a model the original review never assessed. Four questions about the feature decide whether the original approval still covers it:

1. Admin Console Reports: Some platforms offer AI usage reports and per-app adoption figures backed by audit logs, and others expose little beyond an on/off setting.

2. Feature Settings: The review records whether the feature is on by default, which workspaces it covers, and whether users can turn it on themselves.

3. Ownership: A named business owner decides whether the feature stays on.

4. Data Flow: The review traces which content the feature processes, whether a sub-processor or third-party model handles it, and what the vendor's terms say about training on customer data.

Because some reports show adoption but not prompts, an approved application record cannot stand in for feature-level visibility. Each AI feature needs its own inventory line, setting, owner, and evidence source.

Agents and MCP Connections Extend Access Beyond a Chat Session

An agent's connection keeps reading and changing data after the chat window closes. For example, an employee connects an AI assistant to a corporate drive, calendar, and mailbox through an OAuth grant or an MCP server. These connections typically inherit the data permissions of the user who created them, a core problem in securing non-human AI identities, so the agent can read, and sometimes change, whatever that user can.

The consent record anchors the investigation by naming the user, the application, the scopes, and the grant date. Endpoint evidence can add local agent runtimes, command-line tools, and API keys stored in environment variables, and the target platform's API logs show which calls the integration made. Correlating the consent record, endpoint evidence, and API logs gives a fuller account than any one source.

Local MCP servers and command-line tools can still escape notice, because they may never generate traffic that stands out and MCP server registries list only the servers an administrator added. Abnormal's AI Agent Security, in private preview, is designed to discover agents across AI platforms, map their ownership, and track each agent's privileges and data reachability.

How to Act on Shadow AI Detection Findings

Detection evidence reduces risk once each finding lands in an owned inventory record and drives a proportionate response. The National Institute of Standards and Technology (NIST) AI Risk Management Framework, a voluntary framework, calls for mechanisms to inventory AI systems but does not explain how to find systems nobody registered.

Owned Inventory Records That Capture the Evidence

Each discovered use needs a record that a named person owns and that captures what the evidence shows. A workable record holds the fields later decisions depend on:

• Tool or Integration: The record names the service, feature, extension, or agent precisely.

• Owner and Purpose: It identifies the accountable person and the business task the tool supports.

• Discovery Source: It records the signal that surfaced the use, which indicates how much the evidence can prove.

• Permissions and Data Concerns: It captures granted scopes and any sensitive data the tool may touch.

• Policy Status: It marks the use as approved, under review, restricted, or scheduled for removal.

Keeping the discovery source next to permissions stops contact, attribution, and exposure from blurring in later reviews. A hypothetical OAuth grant gives an AI note-taking app read access to every file in a user's corporate drive, establishing only potential access.

Establishing actual exposure means querying consent events in the audit log, exporting every user who authorized the app, reviewing the scopes, and checking platform access logs for what the app retrieved. If the risk is unacceptable, an administrator can revoke the grant, remove the app, and explain the decision to affected users.

Response, Policy, and Sanctioned Alternatives

Each shadow AI finding gets a response matched to its risk, and high-risk findings, such as a grant over sensitive data or a coding tool holding credentials, belong in the normal incident process. Retiring a tool requires a safe shutdown that revokes its tokens and confirms how the vendor handles the remaining data. Lower-risk findings can move straight to an owner's decision about whether to approve, restrict, or replace the tool.

An AI acceptable-use policy keeps the same findings from recurring by stating when employees may use AI, which data stays out of prompts, and when to escalate. Role-specific training and a simple channel for disclosing tools people already rely on make that policy easier to follow and hidden tools easier to surface. Sanctioned alternatives matter most, because restricting access tends to push use onto personal devices and hidden tools that are harder to detect than the ones they replaced.

Regular review tracks the number of untracked AI applications and AI systems lacking oversight, inventory, or policy coverage. Those counts show whether discovered AI is moving into governed records with named owners, or whether findings still sit unreviewed.

Make AI Visibility a Repeatable Practice

Shadow AI detection produces defensible decisions when investigators read every signal for what it proves. A discovered tool, feature, or agent with no named owner, no evidence strong enough for a risk decision, and no defined follow-up is still shadow AI, regardless of what the inventory says.

AI Governance, generally available in Abnormal's AI Security suite, is designed to discover approved and shadow AI tools, assign ownership, and track compliance gaps. Explore the AI Security platform to see how Abnormal maps unsanctioned AI tools to named owners.

Frequently Asked Questions

Does detecting an AI service prove that its model trained on company data?

No, a destination match shows contact with the service, not what the device sent or how the provider handled it. Whether inputs can train a model depends on the provider's terms, the account type, and the settings in effect. Settling the question takes the contract and evidence of what data reached the provider.

Can investigators reconstruct AI activity without logs?

Only partially, because no one can recreate audit events and prompt records the organization never collected. Investigators can still assemble a partial picture from retained proxy and network logs, endpoint artifacts, browser data on managed devices, and interviews with involved people.

Does an AI governance standard automatically discover unapproved tools?

No, AI governance frameworks call for inventories, risk assessment, and ongoing review, but they describe what an organization should maintain, not how to find unregistered tools. Discovery still depends on the network, endpoint, identity, and platform signals the organization collects.