Shadow AI: A Guide to Discovery, and What to Do About It

Earlier this year, at a large software company that sells into a heavily regulated industry, an engineer built a Claude agent to handle part of the customer success team’s workload. It worked, and the team adopted it. By the time anyone outside the team heard about it, the engineer was figuring out how to store it in GitHub, because it had quietly stopped being a personal experiment and become a tool his colleagues depended on.

Since nothing was purchased, no procurement event fired and no security review ever ran. Nobody wrote down what data the agent reads or what systems it writes to, and nothing evaluates whether its output is correct. If the engineer leaves, a customer-facing team loses a tool that nobody else can maintain, and if an auditor ever asks what has been touching customer data, the honest answer is that nobody knows.

Also notice what the engineer did wrong: nothing. He found a real workflow, automated it, and his team adopted it because it made their week better. He was even reaching for governance on his own initiative, because storing the agent in a repo is an attempt at durability and versioning by someone with no sanctioned place to put his work.

Some version of this is happening at your company. This guide covers how to find it, with discovery surfaces you already own, and what to do with the inventory once you have it.

The numbers, and the number nobody has

The prevalence data comes from sources with very different methods and incentives, and they converge.

Microsoft and LinkedIn’s 2024 Work Trend Index, a survey of 31,000 knowledge workers across 31 countries, found that 78 percent of people using AI at work bring their own tools. The largest academic-led study in the field, run by KPMG and the University of Melbourne across 48,340 respondents in 47 countries, found that 57 percent of employees hide their AI use from their employer, 48 percent admit to having uploaded sensitive company information to public AI tools, and only 40 percent of workplaces have any generative AI policy at all. On the measurement side rather than the survey side, Netskope’s network telemetry attributes more than half of enterprise AI adoption to shadow use, and logged AI data-policy violations more than doubling in 2025, to 223 incidents per month at the average organization.

Those figures describe usage, mostly chat. The builder population is harder to pin down, and you should know that no credible study measures it directly yet. The closest hard datapoint is also from Netskope’s telemetry: 5.5 percent of organizations already have users running self-built agents from AI agent frameworks on premises, and 34 percent have local LLM interfaces like Ollama running, none of which touches a network control. Gartner has predicted that by 2027, three quarters of employees will acquire, modify, or create technology outside IT’s visibility, up from 41 percent in 2022.

Two problems that need different instruments

Shadow AI is usually discussed as one problem. For discovery purposes it is two, and they leave different evidence.

The first is unsanctioned usage: employees pasting things into chatbots, AI notetakers sitting in meetings, browser extensions summarizing documents. This activity exists as traffic and as access grants. It shows up in network logs, CASB dashboards, and OAuth consent lists. It is the problem most shadow-AI products are built to find, and the risk is mostly data leaving through the prompt box. The incidents that make headlines are this shape: in 2025 a former contractor at the NSW Reconstruction Authority in Australia uploaded a spreadsheet containing personal and health data of up to 3,000 flood victims into ChatGPT, one of the first government breaches attributed to an unauthorized upload to a public AI tool.

The second is the builder problem, and it is the one that compounds. An employee with Claude Code or Cursor can produce a working agent in an afternoon: a repo, a prompt file, an MCP config, a scheduled job, an API key. The moment a second person starts depending on that agent, your organization has acquired an unowned production system. Unlike chat usage, an agent is a durable artifact, with an author, source code, declared tool access, and sometimes a crontab entry, and almost none of that is visible in network telemetry. A proxy log can tell you a laptop called api.anthropic.com 3,200 times last month. It cannot tell you that those calls come from a scheduled script in a repo called ops-tooling, that a specific person wrote it, that it reads the CRM and writes to a spreadsheet the renewals team now depends on, or that its API key is committed in plaintext.

Traffic-side sources find usage. Artifact-side sources find agents. You need both, plus the access-grant view and the human view, because no single tool covers the estate.

Who runs this, and the legal line to draw first

Discovery work splits along an org-chart line, and this problem gets owned by different people in different companies. Sometimes it lands on a CISO or CIO who is accountable for an estate they cannot see, and sometimes on a business-unit leader who suspects their own teams are quietly running on tools nobody approved. The guide below works for both, but the entry points differ.

The network and CASB sources require the security organization, because that is where the logs live. If you are a department head, you cannot pull proxy logs without escalating, and you should not try. What you can do without anyone’s permission is the artifact side: a read-only scan of repositories your own teams already own, plus the two interview questions at the end of this guide. If you are in the security org, you can run everything here, and the artifact sources will still be the ones that surprise you, because they are the ones your existing tooling does not cover.

Before touching any source that can produce per-user data, settle the privacy posture. The practical rule that keeps you clear of most of this: run discovery in aggregate. Defender for Cloud Apps anonymizes usernames in discovery reports by default, with de-anonymization allowed only for a specific justified investigation and itself audited. Copy that pattern. Who built each agent is a question for a conversation later, and that conversation goes much better when the builder is being recruited rather than reported.

The traffic layer: what your network already knows

Defender for Cloud Apps, the tool you probably forgot you own

If your company holds Microsoft 365 E3 or E5, EMS E3, or Entra ID P1, you already own cloud app discovery, and most license holders have never pointed it at AI. It works in two modes. With Defender for Endpoint deployed, device telemetry feeds Cloud Discovery continuously with no log handling. Without it, snapshot reports let you manually upload log exports from your existing firewall or proxy, and Microsoft ships parsers for more than 30 appliance formats (Palo Alto, Zscaler, Fortinet, Cisco ASA, Squid, Check Point, and others), so this path works even in a network stack with no Microsoft in it. Either way, traffic is matched against a catalog of more than 31,000 cloud apps scored on more than 90 risk factors. In the Cloud Discovery view, filter discovered apps to the generative AI category and export. That export is your first usage inventory of which AI services are in use and by how many people.

Microsoft has kept building here, which tells you something about where the market is going. Entra Global Secure Access added a dedicated shadow AI discovery surface in mid-2026 that catalogs AI chatbots, model provider APIs, and SaaS MCP servers, and can identify MCP by the protocol itself rather than by catalog lookup. Defender for Endpoint has a preview feature that enumerates locally installed AI agents by name across an onboarded fleet: Claude Code, Codex CLI, Gemini CLI, Cursor, Claude Desktop, ChatGPT Desktop, and local and remote MCP server configurations. If you are a GSA or full-MDE shop, check what your tenant already surfaces before building anything by hand. Then read Microsoft’s own stated limitation, because it marks the boundary of the entire traffic layer: MCP logging captures only traffic to remote MCP servers, and local MCP servers running on a device are not visible to it.

CASB and SASE platforms

Netskope, Zscaler, and Palo Alto customers already own strong AI-usage visibility, including a distinction that most owners have not noticed is sitting in their console: consumer web apps and developer APIs are different hostnames, and your platform logs them separately. Netskope’s published research draws exactly this line, reporting traffic to api.openai.com in 70 percent of organizations and to Anthropic’s API endpoints in 30 percent. In Netskope, filter cloud app usage by the generative AI category (the catalog covers more than 1,500 AI apps), then split by destination host to separate web traffic from API traffic. In Zscaler, the ZIA shadow IT reporting supports the same category filtering, with AI-specific dashboards in recent releases. Palo Alto sells AI Access Security as a dedicated SKU with a catalog it states covers more than 4,000 generative AI apps; if you own Prisma Access without that SKU, ordinary URL filtering logs still contain the hostnames below.

Traffic to an API host is evidence of programmatic use, which covers a developer testing in a notebook, a sanctioned integration, a SaaS product that happens to call an LLM, and the ungoverned bot, all producing identical rows. Treat the API-versus-web split as a way to size programmatic use in aggregate and to shortlist which teams to talk to.

DNS and proxy logs, and the hostname fingerprints vendors publish about themselves

With no CASB at all, hostname logs get you surprisingly far, because the most useful detection asset in this whole space is free: AI vendors publish enterprise network allowlists that fingerprint their own products.

The consumer web apps are chatgpt.com, claude.ai, gemini.google.com, chat.mistral.ai, and perplexity.ai. The developer API hosts are api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, api.mistral.ai, openrouter.ai, and api.together.xyz. Then there is a third group, and it is the one worth building alerts on. Anthropic publishes the full hostname set Claude Code requires, and it includes hosts like mcp-proxy.anthropic.com and bridge.claudeusercontent.com that have no human-chat analogue, so their presence indicates the coding agent specifically. Cursor’s network documentation separates agent traffic (agent.api5.cursor.sh, documented as serving Cursor’s agent requests) from the tab-completion hosts. GitHub documents Copilot’s hostnames by plan tier, which yields a self-contained finding: traffic to the individual-plan subdomains from inside your corporate network means an employee is running a personal Copilot subscription against company code, outside your enterprise agreement and its data-handling terms.

Four caveats your team will hit, so hit them first:

• Match hostnames, never IPs. api.anthropic.com and claude.ai resolve to the same IP address, and most other providers sit on shared Cloudflare ranges. An IP-based rule set cannot tell providers apart, let alone products. You need SNI extraction, DNS query logs, or HTTP CONNECT logs; if all you have is NetFlow, this layer is closed to you.
• The API-host heuristic leaks in both directions. OpenAI’s Codex CLI, an autonomous coding agent, routes through chatgpt.com rather than the API host. Claude Desktop, a chat application, legitimately calls api.anthropic.com. Do not ship a rule that says API host equals agent; it is wrong both ways.
• Hostname visibility has a shelf life, but it is alive today. TLS 1.3 already hides server certificates from passive observation, and Encrypted Client Hello (RFC 9849, standardized March 2026) would hide the hostname too. ECH only works when the server publishes a DNS record enabling it, and as of probes run in July 2026, none of the major AI provider hostnames had. Build on hostnames now, and watch ECH adoption on these domains.
• Know the structural blind spots. Cloud-hosted inference is largely indistinguishable from ordinary cloud API traffic: Bedrock lives at bedrock-runtime.<region>.amazonaws.com, Vertex at <region>-aiplatform.googleapis.com, and Azure OpenAI behind unguessable per-tenant subdomains of openai.azure.com. Local models generate no egress at all after the initial download, and Netskope found local LLM interfaces in about a third of organizations. Application-level DNS over HTTPS bypasses your resolvers on unmanaged devices. Each of these gaps is covered by a source later in this guide, which is the argument for running more than one.

One more signal deserves a mention: timing. A cron-driven agent produces machine-regular request intervals no human generates, which is exactly the signature you’re checking for. Resist its tempting cousin, off-hours activity. Distributed teams and on-call engineers generate plenty of 3 a.m. traffic, and presenting “off-hours equals agent” to a security team earns an immediate and deserved dismissal.

The access layer: OAuth grants

This source is one admin export, requires no new software, and answers a question none of the traffic sources can: which AI applications hold standing, durable access to your company’s data right now?

Every time an employee clicks through a consent screen for an AI notetaker, a writing assistant, or a chat tool’s Drive connector, an OAuth grant is created that persists until someone revokes it. In Entra ID, review the enterprise applications list in the admin center sorted by creation date, and audit the Microsoft Graph scopes each app holds; Mail.Read, Files.Read.All, and Calendars.Read are the ones that matter. In Google Workspace, the app access control area under Security in the admin console lists third-party apps with OAuth access to Workspace data, along with their scopes. Expect to find transcription tools with meeting and calendar access, writing tools with mail scopes, and connectors with broad Drive access, each approved by one employee who never read the scope list. Rank by scope breadth, revoke the abandoned ones, and consider requiring admin consent for future grants.

The limit of this source defines its place in the sequence: it only sees what authenticates through your identity provider. An agent built on a raw API key never appears in an OAuth grant list, which is most of them.

The artifact layer: where the agents actually live

Everything above finds activity. This section finds the agents themselves, because an agent built with modern tooling exists as files, and the files are sitting in repositories and home directories your organization already controls. This is also the layer where the incumbent discovery products are weakest, and the one an engineering leader can run this week with read access they already have.

Scanning source control

A repo scan answers the questions a governance conversation eventually turns on. The surrounding code shows what an agent is for. Commit authorship shows who built it. Contributor counts and referencing repos show whether anyone else depends on it. MCP configuration declares exactly which tools and data sources it can reach. A cron entry or CI schedule proves it runs unattended, as a fact rather than an inference.

Run this against a directory of clones of your organization’s repositories, using ripgrep:

# Agent harness files. Each of these exists for exactly one purpose:
# an AI agent is configured to operate on this repository.
rg --files --hidden \
  -g 'CLAUDE.md' -g 'AGENTS.md' -g '.cursorrules' \
  -g 'copilot-instructions.md' -g '.mcp.json'

# Provider SDK and framework usage in source
rg -l -e 'from anthropic import' -e 'from openai import' \
  -e '@anthropic-ai/sdk' -e 'langchain' -e 'crewai'

# Unattended invocation: CI workflows and cron entries that
# run an AI CLI non-interactively
rg -n -e '\bclaude\b' -e '\bcodex\b' -e '\baider\b' -- .github/workflows/

# Committed provider credentials
rg -n 'sk-ant-(api03|admin)'   # Anthropic key prefixes, documented
rg -n 'T3BlbkFJ'               # infix carried by OpenAI-issued keys

For credential scanning at any real scale, delegate to gitleaks or trufflehog rather than extending the regexes. Both scan full git history, where keys deleted from the working tree years ago still live, and both maintain the provider patterns for you. A committed provider key is the single best finding in this entire guide, urgent on its face and verifiable by anyone in your organization in under a minute.

A few disciplines keep a repo scan credible, and credibility is the whole game, because the first overstated finding gets the entire report dismissed by people who know the estate better than the scan does. Report what a file is, never what it does: “this repository contains a CI schedule invoking the Anthropic API” is a fact with a path and a line number, while “this agent processes customer refunds” is a guess that will be corrected in front of your leadership. Exclude the noise by default (vendored dependencies, test fixtures, example directories, archived repos), and tune to under-report. Eight confirmed findings beat fourteen findings of which six are wrong.

Developer endpoint configuration

The same artifact logic extends to workstations. Local MCP server configurations (in .mcp.json files, Claude settings under ~/.claude, and Cursor’s MCP config) describe agent wiring that no network product can observe, since Microsoft’s own docs concede local MCP servers are invisible to its traffic inspection. User crontabs that invoke AI CLIs are unattended agents by definition. If you run Jamf or Intune, your MDM’s installed-application inventory will also surface the local model runtimes (Ollama, LM Studio) that generate no network signal at all.

One configuration-level finding deserves to be pulled out on its own, because it is probably the most attention-getting true sentence a discovery pass can produce. Anthropic’s data usage documentation states that consumer Claude accounts (Free, Pro, and Max) may have training on user content enabled, explicitly including Claude Code usage on those plans, while commercial and API accounts are excluded by default. An employee running Claude Code under a personal Pro subscription against your codebase may therefore be contributing your source code to model training. Account type is visible in local configuration, so an endpoint pass can check for it directly. Deliver that finding with the citation attached and no dramatization; it needs none.

One boundary must be respected in the same pass: Claude Code retains local session transcripts under ~/.claude/projects/ (30 days by default). Their existence on a machine is a legitimate usage signal, but their contents are an employee’s working conversation and should never be read in a discovery exercise. That line separates governance from surveillance, and everything in the final section of this guide depends on staying on the right side of it.

The spend layer

If you run Ramp, Brex, or a SaaS management platform like Zluri or Torii, the purchasing side gives you a view the network cannot: who is personally paying for AI tools. Search card transactions and detected subscriptions for the obvious merchants: OpenAI, Anthropic, Cursor, Perplexity, Midjourney, ElevenLabs, and the notetaker category. SaaS management platforms tag AI as a category; card platforms need a merchant search. A scheduled agent on a cheap API tier costs a few dollars a month and will never surface here, so expense data does not find agents. It finds committed early adopters, which makes it an interview list, and expense records are organizationally sensitive in a way DNS logs are not, so keep the output tight.

The human layer: two questions

The cheapest discovery instrument in this guide requires no tooling and no access requests. Add two questions to whatever manager one-on-ones or team retrospectives already happen. First: what AI tools do you personally use for work? Second, and this is the question that finds the engineer from the top of this piece: is there anything a colleague built that your team now depends on? That second question surfaces dependencies rather than usage, and every answer names a builder worth talking to next.

One condition decides whether this works. Get an explicit commitment from leadership, in writing, that nothing disclosed in discovery becomes a disciplinary matter. Remember the baseline you are working against: 57 percent of employees already hide their AI use. If disclosure looks even slightly dangerous, your interviews will produce a fiction, and you will have spent your one chance to ask.

What to do with the inventory

Run several of these sources over a week or two and you will end up with a usage map from the traffic layer, a standing-access list from the OAuth pass, an artifact inventory from the repo and endpoint scans, and a handful of named builders from the interviews. The reflex at this point is to treat the list as an enforcement queue, and the track record of that reflex is bad enough to spell out.

Samsung banned generative AI in May 2023 after employees pasted semiconductor source code into ChatGPT, with termination as the stated ceiling for violations. By June 2026 it had reportedly deployed ChatGPT Enterprise company-wide in one of OpenAI’s largest enterprise rollouts. JPMorgan went from ban to an internal LLM portal serving well over a hundred thousand employees. While bans are in force, the usage does not stop; it goes dark. Gartner has found 69 percent of security leaders suspect or have evidence of prohibited AI use in their organizations, and IBM’s 2025 Cost of a Data Breach report puts a price on the darkness: 20 percent of studied organizations had breaches linked to shadow AI, running an average of $670,000 more expensive than breaches without it.

Provisioning sanctioned seats is genuinely worth doing, and it is half a solution. The best longitudinal number in the field, from Netskope, shows personal-account AI use falling from 78 percent of users to 47 percent after organizations provisioned approved tools. Half the shadow usage converts. The other half keeps routing around the sanctioned option, and more to the point, the enterprise seat governs access to a tool. The agent an employee built is exactly as ungoverned on a licensed seat as it was on a personal one.

So govern by dependency rather than by tool. The useful property of the tiering below is that every trigger is an observable fact a reviewer can check, never a judgment call:

• Leave it alone while it has one user, runs only attended, reads only what its builder could already read, and writes nothing shared. This is personal experimentation, and it is the R&D function that just produced your best automation candidates for free. Taxing it kills the discovery engine.
• It needs an owner the moment any one of these becomes true: a second person uses it or its output on a recurring basis; it runs unattended (a crontab entry is observable); it writes to any shared system of record; it touches data beyond the builder’s own entitlements or any regulated class. Crossing the line means a named owner, a registry entry, an evaluation signed by someone who depends on the output, and an audit trail. Nobody did anything wrong; the organization now depends on the thing, and dependencies get owners.
• It needs approval gates when output is external-facing or actions are irreversible, or when it touches PII, financial, or legal data: human sign-off on individual actions, with evaluation thresholds as deployment gates.

Readers in financial services will recognize the lineage. This is the logic of the Federal Reserve’s SR 11-7 model-risk guidance, which pulled end-user-computing spreadsheets into formal governance after disasters like the London Whale, where roughly $6 billion in losses traced partly to a risk model living in manually copy-pasted Excel with an unreviewed formula error. An agent a customer-facing team depends on is an end-user-computing model by any reasonable reading of that tradition.

The last and most consequential choice is framing. “Six people in your organization are running ungoverned code” and “six people in your organization have built working AI automations that their teams adopted” describe the same discovery output. The second class of builders did, for free, exactly the discovery work that AI consultancies charge six figures for. The pilot already ran; nobody captured the results. History is specific about what happens when capture never comes: enterprises are still paying migration consultants for Lotus Notes applications and Access databases whose builders left twenty years ago, and one regulated manufacturer’s first Power Platform governance audit reportedly turned up 427 apps and 1,183 automation flows across 47 environments that nobody had inventoried. Artifacts that are cheap to create and individually owned do not get captured retroactively. The intake mechanism has to exist before the builder leaves.

Where this goes

A discovery sprint gives you a point-in-time inventory, and the shadow layer regenerates, because agents get created at the speed of an afternoon while procurement runs on quarters. No approval process will ever sit upstream of creation. Governance has to attach downstream, at the point where an agent touches company data and systems, which is the one place every agent must eventually pass through regardless of which tool built it.

That seam is where we build. Neutron Enterprise governs AI at the boundary between agents and the company’s data and systems: employees keep whichever tools they already use, and those tools talk to governed endpoints where retrieval is trimmed to each caller’s actual entitlements, writes pass through typed actions with approval tiers, and every call lands on one audit trail whichever client produced it. The record of what an agent read and did exists only if you build the place where that record gets made.

If you run even two or three of the sources above and find more than you expected, that is the normal result, and it is better news than it feels like: your organization has already proven demand and validated workflows on its own initiative, at zero cost. If you want a second set of eyes on what you found, or you want to talk through what a governed home for it looks like, talk to us.