Shadow AI is AI that people use for work without their organization knowing about it or agreeing to it: a chat app on a personal account, an AI feature nobody reviewed, an agent wired to tools nobody vetted. On engineering teams, much of it now lives inside coding agents, as MCP servers and skills an engineer can add in a minute without telling anyone.
What is shadow AI?
Ask a security team for its list of sanctioned AI and the answer is usually short: a ChatGPT or Claude workspace on a corporate contract, a coding assistant license, perhaps an internal LLM gateway. Shadow AI is all the AI use on company data outside that list, without security oversight. It covers unsanctioned apps, personal accounts on sanctioned ones, AI features nobody reviewed, and agents calling tools nobody vetted.
For a one-line shadow AI definition, IBM’s 2025 breach research uses the “unregulated, unauthorized use” of artificial intelligence. You’ll also see unsanctioned AI, unauthorized AI and unapproved AI tools, and Microsoft calls the employee side of it BYOAI (bring your own AI). Shadow AI security is the work of finding that usage and deciding what happens to each tool. Shadow AI management is that job on repeat.
The shadow AI meaning has stayed the same since the term caught on. What changed is who adds the tools. A chatbot still needs a person to open it. A coding agent can be pointed at a new MCP server by one line in a config file, and a skill can come along inside a repository someone cloned for an unrelated reason.
Shadow AI vs shadow IT
An engineer who copies a customer export into a personal Dropbox has created a shadow IT problem: a copy of customer data in a place you don’t control. If the same engineer pastes that export into a personal chatbot account, the tool also reads it, keeps it for as long as that account’s terms allow, and writes something back that ends up in a deliverable. Connect a coding agent to an MCP server with write tools and the unreviewed software can now change other systems, too.
So shadow AI is a kind of shadow IT, with two differences that matter when you choose controls. The tool processes the data instead of only storing it, and once agents are involved, it acts.
| Shadow IT | Shadow AI | |
|---|---|---|
| Typical example | A personal file-sharing account, an unapproved SaaS app, a team’s own cloud account | A chatbot on a personal account, an AI feature switched on in a sanctioned SaaS app, an MCP server or skill added to a coding agent |
| What leaves the organization | Files and records | Prompts, pasted documents, source code, tool results and whatever an agent holds in context |
| Who adds it | A person, usually through a sign-up | A person, or an agent acting on an engineer’s config; local models and stdio MCP servers need no account at all |
| What it can do | Store and share data | Read data, produce output people act on, and with tools, change other systems |
| Where it’s usually found | Expense reports, SSO and OAuth logs, CASB discovery | The same places, plus inspection of the traffic itself |
The hardest case sits between the two columns: a personal account on a sanctioned app. When your organization pays for Claude and an engineer signs in to the same app with a personal account, the hostname, the client and the traffic pattern all match the sanctioned use. Only the account differs, so tools that work from destinations alone can’t tell them apart.
Why shadow AI happens
In Microsoft and LinkedIn’s 2024 Work Trend Index, a survey of 31,000 people in 31 countries, 75% of knowledge workers said they already used AI at work. Of those AI users, 78% brought their own AI tools, and at small and medium-sized companies the figure was 80%.
Most of the reasons come down to productivity. A chatbot is a browser tab away and often free. For engineers, a new agent is one install command and a new MCP server is one entry in a JSON file, while getting a new tool through review tends to take weeks, so adoption runs ahead of approval. Sometimes the sanctioned option is simply worse: an older model, or an assistant that can’t reach the system the engineer needs to query.
We’d read the first inventory of shadow AI as a requirements list. Each unsanctioned tool on it is something people needed that the official set didn’t give them, and the fastest way to shrink the list is to move the good ones onto corporate accounts.
Shadow AI examples
The examples below run from the most visible kind of shadow AI to the least, which is roughly the order security teams find them in.
Chat assistants and personal accounts
A support lead pastes a customer escalation into a personal chatbot account to draft a reply. A finance analyst uploads next quarter’s forecast to a free tier because it makes better charts than the spreadsheet, and a recruiter asks an AI assistant to rank a stack of resumes. Often the security team already approved the assistant itself. The employee just used it through an account nobody has an agreement for.
AI features inside approved software
Here the software went through review and its AI feature didn’t, because it shipped in a later release. Meeting assistants join calls and send the recordings to their vendor for transcription, someone switches on a summarizer inside a SaaS tool that was cleared years ago for something else, and browser extensions offering writing help read every page the employee opens, internal ones included. Developers do it too. One tests a side project against a model API with a personal key and a sample of production data.
Coding agents, MCP servers and skills
This kind arrives as configuration, which is why surveys rarely surface it.
MCP servers are added by an entry in the agent’s MCP config: a command that starts a local server, or a URL for a remote one. That’s the whole install. Every tool call after that can carry files, tickets or credentials the agent read earlier in the session. A local server that talks over stdio runs as a subprocess of the agent and exchanges messages through stdin and stdout, so nothing on the network sees that conversation; a network control only sees what the server itself calls out to. OWASP’s MCP Top 10, a beta for now, gives the problem its own entry, MCP09:2025 Shadow MCP Servers: deployments “often spun up by developers, research teams, or data scientists for experimentation”, frequently left on default credentials or permissive configurations.
Skills reach the agent by other routes. In Claude Code, the skills docs say: “Create a SKILL.md file with instructions, and Claude adds it to its toolkit.” Claude can load skills automatically when they’re relevant, and a skill can bundle scripts. The same docs list the ways skills get distributed: committed to a repository under .claude/skills/, shipped in a plugin, or deployed across an organization through managed settings, while personal skills in ~/.claude/skills/ apply to every project on the machine. Cloning a repository can therefore add instructions to an engineer’s agent. Claude Code skills follow the Agent Skills open standard, so one skill folder can work in more than one AI tool. MCP vs skills compares the two supply chains.
Managed connectors are the case inventories miss most often. Claude connectors and ChatGPT apps reach MCP servers through Anthropic’s and OpenAI’s own infrastructure, as our Guardrails docs explain, so a laptop’s traffic shows the AI provider and never the MCP server behind it. Personal accounts use the same relays.
Models change too. An agent’s model setting can point at a provider your organization has no data agreement with, and local model runners need no account once the model is downloaded. Our page on AI coding agent security covers the other controls these agents need, from credentials to git pushes.
Shadow AI agents
Shadow AI agents, sometimes just called shadow agents, are agents running with access to company systems that nobody has inventoried. Nobody is named as the owner, the credentials they hold aren’t recorded, and what they did isn’t logged. Most start as an experiment that worked: a scheduled agent on a cloud platform set up with someone’s personal account and a repository token, or an automation that was given a CRM API key to send follow-ups and kept running.
For each one, three questions matter: who launched it, what identity it runs as, and what it can write. AI agent identity covers how to tie an agent’s access back to a person, and agentic AI security covers the controls a sanctioned agent needs.
What are the risks of shadow AI?
The risks of shadow AI come down to data you can’t account for and actions you can’t trace. Customer and internal data leaves in prompts and uploads under terms nobody reviewed, output from unvetted models ends up in code and decisions, and agents with unreviewed tools act on other systems with an engineer’s access. All three are hard to investigate afterwards, because nothing logged them.
Many shadow AI statistics in circulation are survey figures quoted second- or third-hand, so the numbers below come from the primary report, with its method. The IBM Cost of a Data Breach Report 2025, research by the Ponemon Institute on breaches at 600 organizations between March 2024 and February 2025, found:
- One in five organizations reported a breach due to shadow AI, and only 37% had policies to manage AI or detect shadow AI.
- Organizations with high levels of shadow AI paid $670,000 more per breach on average than those with low levels or none.
- Shadow AI incidents compromised personal data in 65% of cases and intellectual property in 40%, against 53% and 33% for breaches overall.
- 13% reported breaches of AI models or applications, and 97% of those had no AI access controls in place.
Data leakage is the risk people name first. Source code, contracts and customer records an employee pastes in go to a provider under consumer terms, where they may be kept or used for training depending on the account settings, and you can’t recall them. Redacting or blocking sensitive data in prompts and tool results is the job of AI data loss prevention.
Compliance follows from the same flow. Regulatory regimes such as GDPR and HIPAA assume you know which processors handle personal data, and a prompt to an unreviewed provider is a transfer to a processor nobody assessed. The EU AI Act adds duties for organizations deploying certain AI systems, which starts with knowing which ones you deploy, so compliance teams end up needing the same inventory security does.
Actions through tools are what agents add. The MCP specification says “Tools represent arbitrary code execution and must be treated with appropriate caution”, and that “Hosts must obtain explicit user consent before invoking any tool”. Coding agents offer modes that skip those prompts, and engineers turn them on to keep long tasks moving, as in Claude Code’s skip-permissions mode. An MCP server that never had a security review then receives tool calls nobody looks at, with the engineer’s access behind them.
Skills add unreviewed instructions. A skill copied from a public repository changes what the agent does and can run its own scripts, with no code review or package registry in between. That’s the agentic supply chain risk OWASP ranks fourth in its agentic Top 10.
Spend is the smaller, more visible risk: tokens billed to personal cards, duplicate subscriptions across teams, and models picked per request with no price agreed.
How to detect shadow AI
Detecting shadow AI means comparing the AI actually in use against the sanctioned list, and each source of evidence sees a different slice. Surveys and sign-in logs find tools people log into. Network monitoring finds destinations. Only software on the device can tell which process sent a request, and that’s what separates an agent’s tool call from the engineer’s own traffic to the same host.
| Method | What it finds | What it misses |
|---|---|---|
| Surveys and attestations | Tools people remember and are willing to name | Anything added since; most agent configuration |
| Expense and procurement review | Paid subscriptions and API bills | Free tiers, personal cards, local models |
| SSO and OAuth app logs | Sign-ins and OAuth grants made with corporate identities | Personal accounts; tools with no sign-in, such as local models and stdio MCP servers |
| DNS filtering, secure web gateway, CASB, firewall app identification | AI provider hostnames reached, by user or device | Which account or process sent the request; MCP servers behind Anthropic’s or OpenAI’s relays; request contents without TLS inspection |
| Browser extensions | Prompts and uploads in browser AI apps | Desktop apps, CLIs and coding agents |
| Endpoint proxy with process identity | LLM and MCP requests per process, including child processes an agent starts, with contents after TLS termination | Devices without the software; exchanges that never touch the network, such as a stdio MCP server |
No single row covers everything, so combine two or three. We’d start with SSO logs and DNS for a first map of the browser and SaaS side, since that data is usually collected already. For engineering machines, where most of the agent activity sits, detection has to move onto the device.
Two details decide whether that works. A hostname allowlist from egress filtering can show that api.anthropic.com was reached, not whether the request came from the corporate workspace or a personal one. Reading the MCP tool call or the prompt inside HTTPS takes TLS inspection, which means every client has to trust the inspecting CA, and Node.js and most Python clients ignore the operating system’s trust store unless you point them at a CA bundle.
Formal’s take on the last row, and the review queue it feeds, is on the shadow AI detection page.
How to govern shadow AI without banning it
Blocking every AI domain is the quickest policy to write and the first to fail: the work moves to a phone or a home laptop, and the little visibility you had goes with it. Nothing prevents shadow AI completely. Shadow AI prevention, in practice, means making the sanctioned route the easy one and catching what’s left.
These are the shadow AI management best practices in the order we’d put them in place:
- Publish the sanctioned path. List the AI tools and the accounts to use them through, the models, and the MCP servers and skills people may use, each with who it’s for. Route model traffic from apps through an AI gateway and reviewed MCP servers through an MCP gateway, so the sanctioned path is also the one you can log.
- Choose one default for unknown tools. Allow and monitor while you build the inventory, then block once the list covers what people really use. The default can differ by type: an unknown MCP server with write tools deserves a stricter one than a new chatbot.
- Write blocks for whoever reads them. When the client is an agent, the agent reads the block message, so it should name the approved alternative and say how to request the blocked tool. A bare error leaves the engineer with a failed task and no next step.
- Make exceptions quick and temporary. A named approver, an answer within a day, and access that expires after hours or days unless someone renews it.
- Log the sanctioned tools as well. If prompts and tool calls on the official path aren’t logged, it gives you no more visibility than the shadow one. Per-user spend limits belong here too.
- Explain the data rules with real examples. “No customer data in AI tools” means little next to “this support ticket export can go into the corporate workspace, not a personal account.”
What should a shadow AI policy include?
A shadow AI policy, usually part of an AI acceptable use policy, should say which AI tools and accounts are allowed, which data may go into them, what happens to an unknown tool by default, how to request an exception and who approves it, what gets logged and for how long, and when the list gets reviewed. For engineering teams it should also cover what agents may add on their own.
- Sanctioned apps, models and providers, with the account type for each
- Data classes allowed per tool (public, internal, confidential, regulated)
- The default for unknown apps, MCP servers and skills: allow and monitor, or block
- Whether engineers may add MCP servers or skills to agents without review, and whether auto-approve modes are allowed
- Personal accounts on sanctioned apps, stated explicitly
- How to request a new tool or an exception, who approves, and how long an exception lasts
- What’s logged (prompts, tool calls, spend), who can read the logs and how long they’re kept
- When the list is reviewed, and who owns it
How Formal handles shadow AI on engineering machines
We built shadow AI discovery into Formal Endpoint for engineering laptops. With Transparent Mode on, a network rule selects traffic from recognized agents, child processes included, and the Endpoint reads the MCP and LLM requests inside it on macOS and Linux. Two kinds of item reach the Shadow AI review queue: MCP servers the Endpoint saw that aren’t registered as Formal Resources, and skills that show up in Claude Code’s requests. Guardrails decide the default for unknown items, Allow and Monitor or Block. When a block hits an MCP tool call, the agent receives the servers it may use and how to ask for the missing one, and employees request access from the Catalog.
Discovery doesn’t run on Windows, where Transparent Mode isn’t available yet. Skills come from Claude Code traffic only, and each page reflects only the traffic Formal proxies. The AI governance docs cover the full flow.