What Is Shadow AI? Shadow Agents and MCP Servers

Shadow AI is everything running beside it, on the same laptops, with the same credentials and none of the controls.

Adoption without a gateway. Agents install like developer tooling, from a package manager or a config file, so nothing crosses a control that watches network egress.

Authority without review. Each unsanctioned agent arrives with a credential, and the credential is usually the employee's own.

Invisibility is the risk. You cannot govern, log or revoke what you cannot see, which makes discovery the first control rather than a reporting task.

A moving target. Servers get added, versions change and credentials get reused, so a snapshot from last quarter describes a fleet that no longer exists.

Why is shadow AI so important today?

Agents became ordinary developer tooling faster than any previous category of software. In the 2026 Stack Overflow survey, 73% of respondents used coding assistants and agents daily, coding assistants and agents were the top AI use case at 66%, and 31% of daily users spent four or more hours a day with them (Stack Overflow Developer Survey 2026). Adoption at that speed does not run through a review board.

The tools those agents connect to arrive the same way. A survey of 5,200 open-source MCP servers found 88% require credentials, 53% rely on long-lived static secrets and only 8.5% use OAuth, with 79% passing API keys through environment variables (State of MCP Server Security 2025, Astrix). That is a configuration an employee adopts in an afternoon, and it puts a durable secret on a laptop in a file no security tool reads.

Being unmanaged is not the same as being unused. In a 2025 study, 7.2% of 1,899 open-source MCP servers carried general vulnerabilities and 5.5% showed MCP-specific tool poisoning (MCP at First Glance, arXiv:2506.13538). Across 20 agents and 45 live servers, tool poisoning reached a 72.8% success rate and no model refused more than 3% of the attacks (MCPTox, arXiv:2508.14925). Your sanctioned path can be clean while the path beside it is not.

The business case is about control rather than novelty. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027 for reasons that include inadequate risk controls (Gartner, June 2025). The projects that survive are the ones that can answer what their agents are doing.

How is shadow AI different from shadow IT?

Shadow IT was an unsanctioned application. It held documents, and the worst case was usually a data-sharing problem with a vendor you could name. Shadow AI is an unsanctioned actor. It holds credentials, calls internal APIs and takes actions that look like a legitimate employee did them.

That changes the response. Shadow IT was handled with procurement, a blocklist and a clean-up campaign. Shadow AI needs a real inventory, a credential strategy and an enforcement point on the machine, because the thing you are governing is behaviour rather than a subscription.

Dimension	Shadow IT	Shadow AI
What is unsanctioned	A SaaS application or tool	An agent, a CLI, an MCP server or a local model
Where it runs	In a browser tab, in the vendor cloud	On the endpoint, in the user's session, with their token
What it holds	Documents and credentials the user pasted	A working credential, a tool set and the ability to act
Visibility source	Network logs, SSO logs, expense reports	Only endpoint inspection sees local tools and local servers
Failure mode	Data disclosed to a third party	Records changed, money spent, data exfiltrated
Effective response	Procure, block, migrate	Discover, sanction by capability, broker credentials, enforce at runtime

The last row is the practical difference. With shadow IT, blocking a domain closed the gap. With shadow AI, blocking a domain closes one path and leaves the local MCP server, the internal gateway and the personal token untouched.

What are the main risks of shadow AI?

The risks are consistent enough to name, and each one needs a different control.

Unmanaged credentials

Every unsanctioned agent arrives with some form of access, from a pasted API key to a personal token with repository write. Nobody knows the secret exists, so nobody rotates it, and it outlives the employee's project and often their employment.

Credential sprawl is the first problem to fix because it is the one that turns a curiosity into an incident. A shadow agent with no credential is a toy. With a token, it is an unmonitored insider.

Unvetted MCP servers

A config file gains a server because a colleague recommended it. The server wraps an internal API, ships a bundled credential, and exposes a tool description nobody read. Tool descriptions are instructions the model follows, which makes an unreviewed description an execution path.

Shadow MCP servers are the developer-tooling equivalent of an unapproved SaaS integration, except that they inherit the ability to act inside your network.

No audit trail

A sanctioned agent produces records in the policy decision log and the audit chain. A shadow agent produces whatever its own client writes to a local transcript, which the user can edit or delete. When an incident happens, the record does not exist.

That gap also breaks downstream obligations. SOC 2 sampling, EU AI Act logging for high-risk systems and internal investigations all assume the record was written by something other than the subject.

Data movement outside the approved path

An unsanctioned agent summarising a strategy deck or a customer list sends that content to a model endpoint you have not reviewed. The data leaves under a personal account, outside the data processing agreement, and often outside the region.

Classify first. You cannot decide which tools may see customer data until someone has written down what counts as customer data.

The orphaned pilot

An agent built for a pilot keeps running after the pilot ends, holding permissions no current project needs. Nobody decommissions it because nobody remembers owning it.

Who is responsible for shadow AI?

The organisation that issues the laptops and the credentials, and within it, three named roles.

The platform or endpoint team owns discovery. They provide the inventory that makes shadow AI visible and they keep it current.

The security team owns the decision framework: what may run, what must be blocked, and how an exception is requested and recorded.

The business owner of each agent owns the authority decision, which is a statement of what the agent may reach and why. A security team cannot grant that on someone else's behalf.

The employee's responsibility is narrower than it sounds: use the sanctioned path, and declare what you built. That second part only works if declaring is easy and does not end in a reprimand. A discovery process that punishes disclosure gets false negatives.

How to get shadow AI under management

Discovery first, decisions second, enforcement last. The order matters more than the tooling.

1. Discover from the endpoint, in read-only mode. Cloud API logs show what reached a provider. They do not show a local model, a local MCP server, or which credential a config file points at. Endpoint discovery does, and read-only discovery has no performance cost to argue about.

2. Name an owner for the inventory. One person or team who decides sanction, tolerate or block within a published policy. Without an owner, discovery produces a list nobody acts on.

3. Sanction by capability and by role, not by tool name. Record what each agent may reach: which repositories, hosts and APIs, and whose identity. Then set the allowance by function, because a finance analyst and a platform engineer do not need the same tools. Two agents with the same name can need very different access.

4. Assess how each tool stores and processes what it receives, then replace shared and standing secrets. Retention, training use and residency decide whether a given tool may see a given data class. Short-lived leases with a record of who requested what remove the worst outcome of an unmanaged agent, which is a working credential in a file.

5. Make the sanctioned path the easier path. If the approved gateway is slower, harder to log into or missing the model people need, they route around it. Adoption is a security control, and a sanctions process that takes three weeks produces shadow AI by design.

6. Run policy in monitor mode, then enforce. Log what enforcement would have blocked, review the false positives with the teams doing the work, then turn on blocking for the rules you have proven.

7. Publish the exception route. A written way to ask for something unusual, with a decision inside a week, keeps unusual requests inside the process instead of beside it.

8. Review the inventory on a cadence. Monthly for fast-moving engineering fleets, quarterly elsewhere, plus an owner check on anything new.

What are the common myths about shadow AI?

Five beliefs keep programmes stuck, and each one has a cheap test.

"Blocking the well-known AI sites solves it." It closes the browser path. It does not touch the CLI in the terminal, the MCP server in a config file or the internal gateway on the office network. The test is your inventory: if it lists only what your proxy logs, you have measured the smallest part of the problem.

"If it is not in SSO, nobody is using it." Agents authenticate with personal accounts, pasted keys and local sessions. None of that appears in an identity provider. The test is a read-only scan of ten laptops, which usually finds more than the SSO export.

"Only engineering does this." Business functions build agents from low-code tools with connectors to the CRM and the finance system. The test is a discovery pass scoped to finance and operations rather than to engineering.

"Our enterprise agreement covers it." The agreement covers one vendor's product at one tier. It does not cover the eleven other tools on the same laptop, or the MCP server that authenticates with a personal token. The test is a list of the tools actually observed, checked against the contracts.

"Shadow AI is a training problem." People use what works and is available. If sanctioning takes three weeks and the sanctioned path is slower, the shadow path wins regardless of how good the awareness module is. The test is the median time from request to approval.

Where does shadow AI appear in the agent lifecycle?

Shadow AI enters at the edges of every stage, which is why a single gate at deployment does not catch it.

Design

Most shadow agents are never designed in the open. Someone prototypes on a laptop to prove an idea, and the prototype becomes the production tool when it works.

Development

This is where config files gain servers and where a personal token gets used because the service account request takes a week. Dependency choices here decide what the agent can do later.

Pre-deployment testing

An unsanctioned agent has no testing stage, which is the point. It also means nobody has tried to break it, and nobody has checked what happens when it is wrong.

Deployment

Shadow agents "deploy" by being run on a laptop or committed to a branch. There is no change record, no approval and no monitoring handover.

Runtime

Runtime is where the gap shows. A sanctioned agent passes a policy decision on every call. A shadow agent calls tools directly, with whatever credential the machine has, and produces no decision record.

Continuous monitoring

New agents appear without a ticket. Without continuous discovery, the estate you reviewed in March is not the estate you have in June.

Decommissioning

Shadow agents rarely get decommissioned. They get abandoned, still holding credentials, still running on a schedule someone set up for a demo.

Example: finding shadow AI in a fintech engineering fleet

A hypothetical worked example. The company, the events and the numbers below are illustrative, not a customer result or a measured outcome.

A payments company with 900 laptops asked a simple question: which agents are running, and which are approved? The security team believed the answer was nine. Discovery, run read-only from the endpoint, found 143 agents and CLIs and 61 MCP servers.

Forty of the agents were installations of a single coding CLI, authenticated with personal accounts. Nineteen MCP servers had no identifiable owner, and six of those wrapped internal APIs. Fourteen laptops had an API key for a model provider pasted into an environment file, and three had a token with repository write in a shell profile.

The team triaged rather than blocked. The coding CLI was sanctioned within two weeks, with a lease-based credential and a supported configuration pushed to every laptop. The nineteen orphaned servers were blocked by policy and the owners were asked to claim them. Nine claimed their server and got a reviewed, pinned version. The pasted keys were revoked and replaced with leases, which broke two personal scripts and fixed the exposure.

Six weeks in, the estate had 132 agents, 55 of them explicitly sanctioned, 22 MCP servers of which 18 had a named owner, and no standing model keys on a laptop. It had not shrunk dramatically. It had become visible, which is what made the next six weeks useful.

How standards and regulations influence shadow AI

Shadow AI is hard to map to a framework only because the frameworks assume you know what you are running. Discovery is the common prerequisite underneath all of them.

Framework	Primary focus	Relevance to shadow AI
NIST AI RMF	Risk identification and lifecycle management	MAP requires an inventory of AI systems in context, which shadow AI by definition defeats
ISO/IEC 42001	AI management system	Requires a register of AI systems with owners, scope and risk treatment
ISO/IEC 42005	AI system impact assessment	An unsanctioned agent has had no impact assessment, so the assessment becomes a triage step
ISO/IEC 23894	AI risk management alignment	Places unidentified agent risk into the enterprise risk register as an unknown
EU AI Act	Binding obligations for high-risk systems	Classification obligations start from an inventory, and an unregistered system cannot be classified
OWASP LLM Top 10	Application security risks for LLM systems	LLM06 Excessive Agency describes what an unmanaged agent grants itself
OWASP Agentic Top 10	Agent-specific risks	ASI03 identity and privilege abuse and ASI04 supply chain vulnerabilities are the shadow patterns
OWASP MCP Top 10 (beta)	MCP-specific risks	MCP09 Shadow MCP Servers and MCP01 Token Mismanagement name the two failure modes directly
SOC 2	Controls over security and availability	CC6 access and CC7 monitoring both assume a complete system inventory

How Alyria handles it

Alyria (alyria.ai) treats discovery as the first control rather than a report you buy. A signed, user-space Beacon on every endpoint inventories the AI layer continuously: agents and CLIs, MCP clients and servers, the tools each server exposes, and the credential sources in reach. Shadow AI stops being invisible the moment it runs on a managed machine.

Lyra then evaluates policy against every MCP call and model request on that endpoint, so an unsanctioned server can be blocked, held for approval, or allowed to run while it is recorded. Umbra brokers credentials so an agent never needs a standing secret in a config file. Spectra emits signed OpenTelemetry to Observatory, which puts the unsanctioned agent in the same audit chain as the sanctioned one.

The Agent Exposure Report is the free read-only starting point. For the operating model behind sanctioning, read how a request is governed and the Beacon agent documentation.