Shadow AI Detection: How to Find the AI Nobody Approved

Shadow AI is any AI tool, feature, or agent being used against company data without going through security review. It is the AI-era continuation of shadow IT, with one important difference: a large share of it arrives inside software you already bought and approved.

It shows up in three distinct forms, and conflating them is the single most common reason detection programs fail.

Unsanctioned AI applications. An employee signs up for a consumer AI tool with a work email and pastes in a customer list, a contract, or source code. This is the category most people picture, and the only one most detection tooling was built for.

Embedded AI features. Your existing SaaS vendors ship AI capabilities in a release you never reviewed. A note-taker starts summarizing meetings. A CRM adds an AI assistant that reads every record. A support tool begins generating replies from ticket history. There is no new vendor, no new invoice, and no new domain to block. The AI simply appeared inside a tool that was already approved.

Employee-built AI agents. Someone in operations builds an agent in Copilot Studio, n8n, or a similar platform to automate a workflow. That agent runs with a real credential, usually its creator's, and takes actions on a schedule with no human watching each one.

Concrete examples of shadow AI in practice:

• A developer connects an MCP server to a production database so a coding assistant can answer schema questions.
• A sales manager builds a Copilot agent that reads the full CRM and posts daily summaries into a shared channel.
• A vendor enables an AI meeting assistant by default, and it joins calls and stores transcripts outside your retention policy.
• A contractor uses a personal AI account to process a file of customer records.

Only the last of those looks like the textbook definition, and it is usually the least damaging of the four.

The risks divide along the same lines as the categories, and they escalate sharply from left to right.

Data exposure. Information pasted into an unsanctioned tool leaves your control, may be retained indefinitely, and sits outside every DLP, retention, and legal hold policy you operate. This is the well-understood risk.

Compliance and regulatory gaps. Processing regulated data through an unreviewed AI vendor breaks the promises made in your own attestations. Auditors increasingly ask which AI systems touch regulated data, and "we are not sure" is not an acceptable answer under emerging AI regulation.

Inherited access. This is the risk unique to agents and the one traditional tooling does not see. An employee-built agent holds its creator's permissions. Anyone who can prompt that agent effectively borrows those permissions. A person with no access to a system can ask an agent that does have access, and the data comes back. No control was bypassed, so nothing alerts.

Orphaned credentials. Offboarding removes the human account and leaves the agent running. The agent keeps executing on schedule with a credential belonging to somebody who left, and no offboarding checklist covers it.

Compounding reach. An agent connected to several tools can chain them. Read from one system, write to another. Neither connection was risky in isolation; the combination moves data out through two entirely legitimate calls.

Most organizations try one or two of these and assume they have coverage. Here is what each actually sees.

1. Network and DNS monitoring. Watches for traffic to known AI domains and blocks or logs it.

Catches: employees visiting consumer AI sites from a managed network. Misses: every embedded AI feature, because the traffic goes to a vendor you already allow. Also misses anything on an unmanaged device or off the corporate network, which is most of it.

2. CASB and SaaS discovery. Enumerates sanctioned and unsanctioned SaaS from logs, OAuth grants, and expense data.

Catches: new AI vendors that acquired an OAuth grant or a subscription. Misses: AI features inside apps already in the inventory. A CASB that already lists your CRM as approved says nothing about the AI assistant that shipped inside it last quarter.

3. Expense and procurement review. Looks for AI spend in card statements and vendor records.

Catches: paid tools bought on a card. Misses: free tiers, which are the majority, and everything embedded in existing contracts. Also runs quarterly at best, so it is stale by the time it lands.

4. Endpoint and browser telemetry. Observes what people actually do in the browser, including on unmanaged sites and free accounts.

Catches: real usage of AI applications regardless of network, subscription, or approval status, including file uploads and pasted content. Misses: agents running server-side. An agent executing on a schedule inside a SaaS platform never touches a browser.

5. AI platform inventory. Enumerates the agents, assistants, and connections built inside the AI platforms you operate.

Catches: employee-built agents, their owners, their connections, and the MCP servers they reach. Misses: consumer tool usage on personal devices, which is what browser telemetry is for.

The pattern is clear. Methods one through three were designed for the shadow IT problem and detect the vendor. Shadow AI is frequently not a vendor problem. Complete coverage needs the last two together: browser-level visibility for what people use, and platform-level inventory for what people build.

Even teams running a mature shadow AI program usually stop at applications. The harder layer sits underneath.

A shadow AI agent differs from a shadow AI app in four ways that change the risk entirely. An app is used by a person, in a session, with whatever that person pastes into it. An agent runs on its own schedule, holds a persistent credential, takes actions rather than producing text, and can be triggered by anyone who can reach it. The exposure of an app is bounded by what one person shared. The exposure of an agent is bounded by what its credential reaches.

Beneath the agents sit MCP servers, the connections that give an agent its actual capability. A developer adds a few lines to a local config file and a new integration starts running with real credentials on a laptop. Local MCP servers have no port, no hostname, and no network footprint, so they appear in no scan and no asset inventory. They are added in seconds and removed before any audit runs.

This is where configuration review stops working. A config file records what somebody intended to set up. The credential records what the connection can actually reach, and those two answers drift apart continuously. Auditing the configuration tells you the intent. Only runtime behavior tells you the reach.

A program that holds up has five parts, in this order.

Define what counts. Decide up front that shadow AI includes embedded features and employee-built agents, not only unsanctioned apps. A program scoped to apps alone will report success while the largest category goes unmeasured.

Cover both discovery surfaces. Browser-level visibility for what employees use, platform-level inventory for what employees build. Neither substitutes for the other, and most organizations have only one.

Make discovery continuous. Agents and MCP servers are created in seconds by individuals. A quarterly review is stale within days of running, so anything periodic produces a number that was true once.

Resolve effective access, not declared configuration. For every agent and connection found, establish what its credential actually reaches inside connected systems and whether that exceeds what the workflow requires. Chasing configuration signals without runtime evidence is how teams end up investigating findings that were never real.

Score combinations, not individual findings. Rank by what one agent can reach across everything available to it in a single session, and flag the pairings that create a path from sensitive data to an external destination.

Obsidian builds this picture from runtime activity rather than configuration. Browser-based detection surfaces the AI tools employees actually use, including free accounts on unmanaged sites. Platform inventory covers the agents built across connected AI platforms along with their owners, their connections, and the MCP servers they reach. Each finding is resolved to the effective access it holds inside your SaaS applications, then scored on the combinations that widen blast radius. Runtime enforcement is available today for Claude and Microsoft Copilot; other platforms are covered for discovery and governance.