The Five Vectors of Shadow AI Discovery

Here's a question every CISO should ask their team: how many AI tools are running across the organization right now? Not how many are approved — how many are actually in use, on laptops, in containers, inside browser extensions, embedded in libraries, and running as local models on developer workstations.

If the answer comes from a procurement spreadsheet or an employee survey, it's missing most of them. In most enterprises the gap between perceived and actual AI usage is usually far larger than anyone expects. And discovering shadow AI isn't one problem. It's five, each hiding in a different layer. Here's what comprehensive discovery actually takes.

Vector 1 — DNS: the network layer you're already ignoring

Every AI interaction starts the same way: a DNS query. Before any data reaches a provider, the calling process resolves a hostname. That query is the earliest possible signal an AI interaction is about to happen — and in most organizations nobody watches for it.

Traditional monitoring can tell you someone resolved api.openai.com. It can't tell you about the hundreds of less obvious domains — api.together.xyz, generativelanguage.googleapis.com, api.deepinfra.com, and white-label services that proxy requests through custom domains. Effective DNS discovery needs a constantly updated catalogue of AI-provider domains — thousands, not dozens — with fast lookups that add no latency, parent-domain fallback so a new subdomain of a known AI host is still recognized, and per-domain deduplication so an active coding session doesn't flood the security team.

DNS catches the broadest category: any tool or library that calls an AI API over the network. But it only reveals that a connection was attempted — not what was sent, or whether a person or a dependency made the call. That's where the other vectors come in.

Vector 2 — Processes: the applications running under your nose

AI has moved from the browser to the desktop. Coding assistants, desktop chat apps, and local model runtimes are standalone applications employees install without IT involvement. They don't appear in your SaaS management platform or generate a procurement ticket — they just appear in the process table.

Process-level discovery continuously scans the process list for known AI binaries — reading /proc directly rather than forking shell commands — and catches two categories DNS misses entirely. First, local models: when a developer runs a model locally there are no outbound calls to intercept. Second, installed-but-unused apps: a tool installed last week won't make a network call until its first use. Process scanning finds the binary before any data is at risk.

Vector 3 — Browser extensions: the AI inside the browser

The browser is the most common entry point for shadow AI, and extensions are the most overlooked vector. An AI extension can read the content of every tab a user opens — internal tools, dashboards, email — plus form data as it's typed and clipboard contents, and talk to external APIs through a background service worker that looks like ordinary browser traffic.

Effective discovery scans extension directories across installed browsers — Chrome under ~/.config/google-chrome/Default/Extensions/, Edge and Firefox in their own profiles — and matches against a catalogue of known AI extension IDs. It needs to catch not just explicitly AI-branded extensions but productivity extensions that have quietly added model features in recent updates.

Vector 4 — MCP configuration: the AI integration layer

The Model Context Protocol (MCP) is becoming the standard interface between AI assistants and external tools. From a security view, an MCP config file is a map of an AI tool's blast radius: a .cursor/mcp.json might show a coding assistant wired to a PostgreSQL database, a ticketing system, and a chat workspace; a desktop config might reveal a filesystem server with read/write access to a user's entire home directory.

MCP discovery scans the known configuration-file locations across the filesystem and, for each, extracts the configured servers, their transport types (stdio, HTTP), and the tools they expose. This vector reveals intent and integration depth, not just presence. Someone with a default install is a different risk profile than someone who has connected an assistant to five internal systems — and the config tells you exactly where to focus the governance conversation.

Vector 5 — Local models: the AI that never phones home

A fast-growing shadow-AI category is also among the hardest to detect with traditional tools: locally hosted models. It's now trivial to download and run a capable model on a laptop — no API key, no cloud connection, no network signal at all.

Local models bypass every network-based control — proxy inspection, DNS monitoring, DLP, CASB. The data never leaves the machine, which sounds safe until you consider: no audit trail, no content inspection, no policy enforcement, and no way to know what proprietary data was processed. Local-model discovery identifies runtime signatures — characteristic local API ports and process signatures — and looks for model storage directories to catch downloaded models even when they aren't running.

From discovery to governance

Discovery without governance is just a more detailed anxiety attack. The value is what it enables: risk-based decisions with automated enforcement.

Every discovered tool, provider, or model should be scored against a multi-dimensional risk model — not just “is it approved?” but: does the provider hold recognized certifications (SOC 2, ISO 27001, ISO 42001)? What's its retention policy? Does it train on customer data? Where is data processed, and does that create compliance exposure? A weighted score drives a graduated response: providers below a risk threshold can be auto-approved, those above it auto-blocked before any data reaches them, and everything in between flagged for review with full context — so review takes minutes, not weeks.

The workflow: a new tool appears in the discovery feed and is matched against a provider-intelligence catalogue of roughly 6,000 AI services. A catalogued provider carries its risk score immediately. One you haven't approved yet surfaces as a discovery for review, with whatever context the catalogue has on it. The team can approve, block, or investigate in one action, and that decision propagates to every endpoint and server in seconds.

Why single-vector discovery fails

Most tools monitor one or two of these vectors. A network-based tool catches API calls but misses local models and extensions. A process scanner misses the third-party library calling an AI API from a backend service. A browser tool catches extensions but has no view of server-side usage or MCP integrations.

The math is unforgiving. If each vector catches roughly 80% of shadow AI in its category and the categories are of similar size, a single-vector tool tops out near 16% overall coverage; two vectors, about a third. You need all five to approach comprehensive visibility — and the biggest gains are exactly where network-only tools are blind: local models, browser extensions, and MCP integration depth.

Running five scanners without slowing the machine

Five concurrent scanners can't tax the host. Each vector runs on a configurable interval, caches results locally, and publishes only net-new discoveries to the platform. Domain matching uses hashed sets for constant-time lookups with no per-query allocation. Extension scanning caches manifests and re-scans only when they change. On the network side, a forward proxy reads the plaintext CONNECT hostname, and a proxy auto-configuration (PAC) file covering roughly 6,000 AI-provider domains routes only AI-bound traffic through inspection — email, chat, internal tools, and general browsing are untouched — and updates as new providers are added, with no endpoint reconfiguration.

What comprehensive discovery changes

Organizations with full visibility make different decisions than those flying blind. They write AI acceptable-use policies from data, not assumptions. Picture knowing that dozens of engineers use one coding assistant, a handful run models locally, a few have wired a desktop assistant to internal databases via MCP, and a production service is calling an API nobody approved — the governance conversation becomes specific, actionable, and urgent in the right places.

They stop playing whack-a-mole with individual incidents and manage AI as a category: decide which providers meet the risk threshold, block those that don't, and monitor for new entrants continuously. And compliance turns from a retroactive audit into a real-time posture — when a regulator asks what AI is in use and how it's governed, the answer is a live picture, not a six-month-old spreadsheet.

Start with visibility

You can't govern what you can't see. You can't assess risk on tools you don't know about. You can't enforce policy on interactions you can't intercept. Discovery across all five vectors — for the employees using AI and the agents you run — is the foundation every other AI data-security capability depends on.