What is shadow AI?

By Sagar Batchu, Co-founder & CEO

·Published May 5, 2026·Updated September 1, 2026

The use of AI is happening faster than companies can keep track of and control. If you look at an engineering team of a hundred people today, you’ll see AI tools used by different teams without any central approval. For example, a third of the laptops will have Cursor set up with a personal Anthropic account, there will be several MCP servers installed using instructions from GitHub, Claude Code will be running custom skills nobody has read the source of, and many people will be using ChatGPT for tasks that previously needed a formal request. They are accessing internal systems without audit logs, policy enforcement, or security oversight. Security cannot review what it cannot see. IT cannot enforce rules on systems that are not connected.

Leadership teams have laid down AI mandates before governance teams have had a chance to put a foundation in place. Now they are racing to catch up. Shadow AI is the practical result of that gap between the mandate and the foundation, and companies are increasingly agreeing that the solution is the AI Control Plane, which acts as the management layer connecting all the AI agents in the company to the systems they can access. The rest of this article works backward from that frame: the forms shadow AI takes today, why it cuts deeper than shadow IT ever did, and how to detect and govern it without slowing the rollout the board asked for.

Common types of shadow AI

Shadow IT used to mean an unauthorized Dropbox account or a personal AWS instance humming away somewhere. Shadow AI is messier. There are more places for it to hide, and each hiding place is smaller: a few lines of JSON in a dotfile, usually, with no installer, no running process, and no billing record for a traditional asset-discovery tool to latch onto.

Models accessed through personal accounts. A customer support transcript gets pasted into ChatGPT for a summary. A code review runs through someone’s personal Claude account. The data walks out of the perimeter through a browser tab, and the only record of it sits in the LLM provider’s logs, filed against the wrong identity.

MCP servers installed from anywhere. The Model Context Protocol won the standards battle for how AI agents connect to tools. It won fast, too, fast enough that most organizations still have no registry, no review process, and no kill switch. Employees install MCP servers from npm, from GitHub, from Discord links. This shadow MCP population can read files, call APIs, query databases, and exfiltrate anything it touches.

Skills loaded out of band. Skills (SKILL.md files and equivalents) are instruction bundles that extend an AI assistant with workflows, conventions, and tool usage patterns. A skill is as powerful as a system prompt and as easy to share as a gist. Installed without review, one can override safety guidelines, redirect tool calls, or quietly inject instructions that exfiltrate code on every run.

Internal agents nobody registered. A team builds a deployment-summary agent. It runs under a service account someone created for it, hits production APIs, and posts to a channel. It’s helpful. It’s also outside identity, outside policy, and outside any incident response runbook.

Vibe-coded apps outside software review. An employee can publish an application from an AI builder without a repository, deployment review, or owner record. Vibe coding security covers the application slice, including embedded credentials and connections to company data or MCP servers.

The pattern is the same across all of them. The AI surface lives at the edge, in user-space, where the central tools securing the rest of the company can’t see it. The threat models this opens up are mapped in AI security.

Shadow AI vs shadow IT

Three things separate this category, structurally, from the shadow IT of a decade ago.

AI amplifies access. One MCP server can hand a coding agent broad reach into databases, internal APIs, and file systems. Give the agent a task and it will use every tool in scope to finish it, retrying around failures, chaining calls, improvising routes a human user wouldn’t try. The agent doesn’t ask twice. A misconfigured server is a misconfigured server with hands.

Actions are automated. Old shadow IT mostly leaked data through reads. Shadow AI acts: it opens pull requests, sends messages, modifies tickets, executes shell commands. The blast radius of a bad tool call is bigger.

Detection is hard by construction. MCP configs and skill files sit in dotfiles under home directories. They aren’t installed software, so they never show up in MDM inventories the way an unauthorized application would. The threat model for the average EDR product was written before any of this existed.

Put those together and shadow AI stops being a footnote on shadow IT and becomes its own category. Same problem, turned up a few orders of magnitude.

Detecting shadow AI, reference architecture

The diagram shows where each piece sits. Two mechanisms make it work, and each deserves a closer look on its own: hooks at the AI agent, and MDM as the delivery vehicle. The next two sections take them in order. First hooks, the primitive that makes detection and policy possible at the AI agent itself. Then MDM, the mechanism for getting those hooks onto every laptop in the fleet before an employee ever opens one.

How to detect shadow AI with hooks

Proxying the model call is a solved problem. LLM gateways like OpenRouter, Portkey, and LiteLLM do exactly that, and they earn their keep for routing, cost tracking, and model-level inspection. But the model call is one slice of an AI interaction. Tool calls, MCP traffic, and local commands all run on the laptop, and intercepting each of them at the network would require an EDR-class agent on every employee’s machine. So the interesting work of the last twelve months has been getting observability at the client itself, where the full context is already sitting.

The answer the major AI agents have converged on is agent hooks.

An agent hook is a user-defined handler that fires at a specific point in the AI agent’s lifecycle. It can be a script, an HTTP endpoint, an MCP tool, or a small LLM prompt. Claude Code fires hooks at every layer where data crosses a boundary: UserPromptSubmit when a prompt is typed, PreToolUse before a tool runs, PostToolUse on the result, SessionStart and SessionEnd for transcripts, and Stop when the agent finishes. Cursor exposes an analogous set, with a near-identical event surface for tool calls and the agent loop. The client hands the hook structured JSON about what’s about to happen (the prompt text, the tool name, the arguments), and the hook can observe, log, modify, or block before execution proceeds.

For shadow AI detection, the implications are significant.

Every prompt and tool call becomes inspectable. A PreToolUse hook on a Bash invocation sees the command string before it runs. The equivalent hook on Cursor sees the MCP tool, the server, and the arguments. The data the security team has been chasing through network logs and SaaS audit feeds turns out to be sitting right there at the source.

The hook itself can route to the right backend. Hooks can fire HTTP requests. That means the structured event flows directly into a SIEM, an OpenTelemetry collector, or a control plane. No new agent on the laptop. No new daemon. The AI agent is already running.

The surface isn’t only MCP. Hooks fire on every tool call the agent makes, local commands included. A PreToolUse hook on Bash sees rm -rf before it runs, exactly the way it sees an MCP tool call.

Policy gets enforced at the agent first, with the observability layer as a backstop. The primary enforcement point is the hook itself, embedded in the provisioned AI agent and running inside its lifecycle. The rules that block in real time have to ship with the hook config and run inside the agent, because putting every tool call behind a synchronous API to a remote policy service would add 50 to 200ms to every action and break the experience the moment the network blips. A PreToolUse hook returns a deny decision and the tool call never happens. A UserPromptSubmit hook strips secrets from a prompt before it reaches the model. Structured cases (API keys, tokens, private keys) match cleanly against regex with a keyword pre-filter, at sub-millisecond cost. Whatever those in-agent rules miss flows on as a structured event to the observability layer, where a slower set of checks runs over the unified feed: semantic classifiers, cross-session patterns, and rules that would have been too expensive to evaluate inline. The first pass is proactive and blocks. The second pass is reactive and surfaces.

One design property is non-negotiable: hooks fail open. If the central backend is unreachable, if credentials aren’t configured, if the evaluation script errors, the action proceeds. Visibility that costs uptime is visibility that gets ripped out within a week. The hook is in the hot path; the security guarantee is that it never becomes the hot path.

Hooks also let you capture every session in full. Once the transcript lands in a central store, the question changes. It stops being “block this in real time” and becomes “find every session last quarter where a customer record left the perimeter.” Real-time blocking and retroactive analysis are the same data, used differently.

The catch is the catch every shadow IT problem has always had: hooks are useful only if they’re configured. A hook that nobody installed doesn’t fire. A control that lives in ~/.claude/settings.json on one developer’s laptop and not the other forty-nine isn’t a control.

Which is why the second half of the answer is provisioning.

Provisioning hooks the way you provision laptops

The right end state is simple to describe. Every AI agent on every employee laptop has the right hooks configured before the employee opens it for the first time. Getting there works the same way it works for every other security control on a fleet: your MDM.

Modern MDM providers, including Jamf, Kandji, Intune, Fleet, JumpCloud, and the rest, already push managed configuration to laptops at enrollment. AI agent configuration has no reason to be the exception. With the right profile, a laptop arrives pre-provisioned with:

• A ~/.claude/settings.json and equivalent files for each AI agent the company supports, configured with hooks that route every prompt and tool call to the central observability plane.
• An approved registry of MCP servers, scoped to the team and the role.
• Identity wired through SSO so the AI agent is talking to the model under the employee’s company identity rather than a personal account.
• A baseline of skills the company has reviewed, installed in the right place.

With this in place, the org’s AI surface stops being an audit problem and becomes a normal piece of fleet management. New AI tools come online with controls already attached. Departing employees lose their AI access the same way they lose their email. When something goes wrong, security has a single place to look.

A note on Speakeasy

Speakeasy is building the AI Control Plane, the governing layer between every AI agent in your organization and every system they’re allowed to reach. Shadow AI detection and enforcement are a core part of the platform.

In practice, that looks like this:

We have pre-configured Hooks into the popular clients. Speakeasy ships hook configurations as Claude Code and Cursor plugins, distributed through native plugin systems rather than a custom installer. Day-0 rules are gitleaks-compatible and cover AWS, GitHub, GitLab, Slack, Stripe, GCP, Heroku, Twilio, SendGrid, npm, PyPI, OpenAI, and Anthropic credentials, plus generic API-key and database-connection-string patterns. Custom rules per organization are configured from the same control plane. The hooks ship structured events to the Speakeasy control plane, where they become a unified feed: every prompt, every MCP tool call, and every response, across every employee, every client, and every model.

MDM-native provisioning. The same hooks can be deployed through your MDM provider, so AI agents are governed from the moment a laptop is enrolled. At no point is a developer using Cursor without observability, because no version of Cursor on the fleet was provisioned without the hooks attached.

Plugin-based fleet distribution. The plugin mechanism that delivers hooks also distributes managed sets of MCP servers and skills to specific teams. A GTM team’s Claude is provisioned with the Salesforce, Notion, and internal admin servers it should have; an engineering team gets a different set. Identity, scope, and revocation flow through the plugin manifest rather than through individual developer setup.

Discovery alongside enforcement. Hooks tell you about the activity going through the clients you’ve governed. The control plane also discovers MCP servers and skills installed outside that path, which puts the long tail of shadow AI in the same dashboard as the managed traffic. You see what’s governed. You see what isn’t. You see what to do about the gap.

None of this exists to slow employees down. Quite the opposite. The fastest way to expand AI usage is to make it observable, because observability is what lets a security team say yes to the next tool instead of saying no out of caution. Shadow AI is what happens when the observability isn’t there. Hooks, MDM, and the control plane are how it gets there.

If you’re trying to figure out what’s actually happening across the AI tools your company is using, the most useful thing you can do this quarter isn’t another policy doc. It’s getting hooks into your AI agents and standing up a place for the data to land. The term to have in your head while you do that work is shadow AI. It names the thing you’re actually trying to see.