Shadow AI: How to Discover and Govern Unsanctioned AI

Shadow AI is any AI tool, agent, or integration running inside an organization without approval, visibility, or an accountable owner. It spans a developer's local AI coding assistant, an autonomous agent spun up in a cloud platform, an MCP server wired into production data, and the credentials each one quietly accumulates. Traditional security tooling misses most of it, because every one of those tools assumes an identity belongs to a person or an approved application.

What is shadow AI?#

Shadow AI is the use of AI tools, agents, models, or integrations that no one approved, inventoried, or assigned an owner. It is the AI equivalent of shadow IT, with one difference that changes the risk math: AI systems authenticate on their own and accumulate their own credentials across clouds and laptops. A shadow SaaS app sits there. A shadow AI agent goes to work.

Shadow AI vs. shadow IT: what actually changed#

Shadow IT and shadow AI share a root cause and diverge sharply on blast radius. Both start with people moving faster than procurement. The difference is that shadow IT produces an unapproved application a human logs into, while shadow AI produces a non-human identity that holds credentials, calls APIs, reads data, and takes action without a person in the loop.

Three properties make shadow AI harder to contain:

• It authenticates independently. An agent gets its own token, service account, or API key. There is no user session to watch and no login to attribute to a person.
• It multiplies. One AI coding assistant declares a handful of MCP servers, each with its own credentials. One developer generates a dozen identities in an afternoon.
• It runs where your controls do not look. A local MCP server exchanges messages with the AI tool on the machine itself. No proxy or CASB ever sees which tools the AI can reach or what it asked them to do.

Where shadow AI actually hides#

Shadow AI concentrates in two places, and most organizations only look at one. Cloud and SaaS environments hold the agents, service principals, and machine identities that platform teams create. Developer endpoints hold the AI coding tools, local model runners, MCP server configurations, and plaintext credential files that never leave the laptop. Coverage of one without the other leaves a real gap.

In the cloud and your identity providers#

Cloud and identity platforms are where shadow AI becomes durable. AI agents built in platforms like Salesforce Agentforce and AWS Bedrock AgentCore run alongside service principals, managed identities, app registrations, and service accounts across Entra, Okta, GCP, GitHub, Snowflake, Active Directory, and more. These are the same population that machine identity management was meant to cover, and most programs never extended to agents. Someone spun most of them up for a one-off task, granted broad permissions to make it work, and never revisited it. That person changed teams a year ago.

On developer endpoints#

Endpoints are the blind spot. Roughly two dozen AI development tools are now in common use, including Cursor, Claude Code, GitHub Copilot, Codex, Windsurf, and local model runners like Ollama. Each one declares MCP servers in its own configuration format, and MCP itself ships no governance layer. Each one writes credentials to disk. Those files sit in plaintext in a home directory, outside any vault, invisible to network-based controls.

Shadow AI governance: why detection alone falls short#

Most teams discover shadow AI eventually. Far fewer do anything durable about it, because a list of findings is not a control. Detection tells you an unapproved agent exists. Access governance decides who owns it, what it should reach, whether it still needs to exist, and who signs off on that decision every quarter.

The evidence that this gap costs money is direct. IBM's Cost of a Data Breach Report 2025 found that one in five breached organizations traced the breach to shadow AI, and that only 37% have policies to manage AI or detect shadow AI. Organizations with high levels of shadow AI absorbed roughly $670,000 in higher average breach costs than those with little or none. In a separate finding from the same report, 13% of organizations reported breaches of AI models or applications, and 97% of those lacked proper AI access controls.

Governance trails adoption badly. Deloitte's January 2026 survey of 3,235 IT and business leaders across 24 countries found only 21% report mature governance for agentic AI risks, while 74% expect to use AI agents at least moderately by 2027. For a fuller treatment of that risk surface, see identity governance for agentic AI and a CISO's guide to agentic AI.

Why your existing tools miss it#

Every tool in your stack assumes an identity is either a person or an approved application. An AI agent is neither. That single assumption is why shadow AI slips past controls that work fine for everything else, and why tuning those tools harder will not help.

Here is what each one misses:

• PAM protects human sessions. An agent with its own API key never opens a session.
• EDR looks for malicious behavior. An AI assistant reading a config file looks completely normal.
• DLP and CASB watch approved apps and network traffic. They see the traffic a local MCP server generates, but not which tools the AI can reach or what it asked them to do.
• IGA governs employees and their entitlements. Agents and service accounts never enter the joiner-mover-leaver process it runs on.
• CSPM checks infrastructure configuration. It confirms a service account exists. It cannot tell you whether an AI agent should be using it, or who is accountable for it.

Each tool does its job. None of them covers an identity that spun up yesterday, reaches real systems, and carries no one's name. This is the same structural failure that breaks IAM, IGA, and PAM in the agentic enterprise.

Top risks of shadow AI#

The risks of shadow AI concentrate around identity rather than the models themselves. Unapproved AI systems accumulate credentials nobody rotates, inherit permissions nobody mapped, and move data to providers nobody evaluated. Because no person owns them, the usual correction mechanisms never fire. Five risks account for most of the exposure security teams actually encounter.

Credential sprawl in plaintext#

AI development tools store API keys, OAuth tokens, and service credentials in configuration files on the local disk. These credentials are long-lived, rarely rotated, and frequently scoped far beyond what the task requires. A single compromised laptop exposes every downstream system those keys reach.

Untracked access paths#

An agent inherits the permissions of whatever identity it runs as. When that identity is a shared service account with accumulated entitlements, the agent gets all of them. Nobody mapped that path, so nobody reviews it.

Ungoverned data movement#

Sensitive data reaches AI providers no one evaluated. Source code, customer records, and internal documents flow into systems with no data processing agreement, no retention terms, and no audit trail.

Orphaned and unowned identities#

Agents and service accounts outlive the projects that created them, which turns them into orphaned accounts with live credentials. Without an owner, no one can answer whether the identity is still needed, and the default answer becomes leaving it in place.

Compliance and audit exposure#

Auditors increasingly ask which AI systems touch regulated data and who approved them. An incomplete inventory is a finding. An inventory that excludes endpoints and agents is incomplete by definition.

How to detect shadow AI: a practical approach#

Detecting shadow AI takes discovery across both the cloud and the endpoint, resolved into a single inventory where every finding has an owner. Network telemetry alone will miss local MCP servers and on-disk credentials. Endpoint scanning alone will miss cloud-native agents. Run both, then treat what you find as identities rather than alerts.

1. Enumerate cloud and identity provider identities#

Connect to your identity providers and cloud platforms and pull every service principal, managed identity, app registration, service account, and platform-native AI agent. Record what each one runs as, when it was last used, how old its credentials are, and who created it. This is the foundation of any non-human identity governance program.

2. Scan endpoints for AI tools, MCP servers, and credential files#

Inventory the AI development tools installed on each machine, the MCP servers each tool declares, and the credential files those tools leave behind. Configuration formats vary widely across tools, so normalize them into one consistent view. Record credentials by type and location only. A discovery process should never capture a secret's value.

3. Separate governed from ungoverned#

Compare discovered MCP servers and agents against your approved catalog. The gap between what is running and what your catalog covers is your actual shadow AI footprint.

4. Assign an owner to every finding#

An identity without an owner cannot be governed. Attribute each discovered agent, MCP server, and credential to a named person or team before anything else happens.

5. Route findings into access workflows#

Turn each finding into a real access item: request, approve, certify, revoke. Findings that live in a separate dashboard get triaged once and forgotten. Findings that enter the workflow your team already runs get handled on a cadence. Apply the same provisioning and deprovisioning discipline you use for employees.

6. Review on a recurring cycle#

Add agents and non-human identities to your user access review program, and treat them with the same rigor as employee reviews. Our user access review best practices guide covers the cadence and evidence model. Discovery is a point-in-time snapshot, and AI adoption moves weekly.

Shadow AI management best practices#

Managing shadow AI well means governing the identities AI systems hold rather than policing the tools themselves. Tool-level bans age out within a quarter and push adoption further underground. The practices below hold up as new AI tools ship, because they attach to credentials and permissions instead of product names.

Make the sanctioned path the fast path. Employees route around governance when governance is slower than the alternative. A catalog of approved AI tools with same-day access beats a policy that says no.

Govern the identity, not the tool. Tool-by-tool blocklists expire the moment a new tool ships. Governing the credentials and permissions an AI system holds applies to tools that do not exist yet.

Apply least privilege to agents. Scope agent credentials to the specific systems and actions the task requires. Broad permissions granted to make something work are the most common source of downstream exposure. The seven principles of least privilege implementation apply cleanly to non-human identities.

Eliminate standing access where you can. Just-in-time access removes the long-lived credential entirely for workloads that tolerate it, and zero standing privileges is the end state worth building toward.

Set a policy people can actually follow. Publish which AI tools are approved, what data classes may go where, and how to request something new. Most employees using shadow AI do not know the policy exists.

Treat discovery as continuous. Quarterly scans miss two months of adoption. Run discovery on the same cadence as your identity data.

What to evaluate in a shadow AI discovery solution#

Shadow AI discovery tools vary widely in what they actually see. Most cover cloud and OAuth-based integrations and stop there, which leaves the endpoint surface untouched. Use the criteria below to separate products that produce a list from products that produce governed identities, and press hard on the endpoint questions.

• Endpoint and cloud coverage. Most tools in this category cover cloud and OAuth-based integrations only. Ask specifically whether the product discovers AI tools and MCP servers on developer laptops.
• Local MCP server visibility. Confirm the product detects MCP servers declared over stdio, not only remote servers reachable over the network.
• First-party endpoint sensor. A sensor that collects directly sees configuration files and local declarations that a product reading existing endpoint telemetry was never built to catch.
• Credential handling. Discovery should record credential type and location and never read the secret value. Ask how the parsers enforce that.
• Endpoint architecture. Look for user-space operation without a kernel driver or system extension, read-only local scanning, and no network calls in the scan path.
• Ownership attribution. Every discovered identity should resolve to a named owner, not a machine name.
• Lifecycle governance. Detection is the entry point. Evaluate whether findings become access items you can request, approve, certify, and deprovision on the same fabric as employee access. Our guide to identity lifecycle management for non-human identities covers what that model requires.
• Audit trail. Every discovery, ownership change, and action should be logged for auditors.

How can C1 help with shadow AI discovery?#

• C1 discovers AI tools, MCP servers, and credential files on developer endpoints. A first-party endpoint agent finds the AI tools installed, the MCP servers each one declares including local servers, and the credential files they leave behind, recorded by type and location only and never by contents. It runs in user space with no kernel driver and no system extension, does read-only local scanning, and makes no network calls in the scan path. Available on macOS today, with Windows and Linux to follow.
• C1 enumerates AI agents and non-human identities across your cloud and identity providers. Connectors surface the agents running in platforms like Salesforce Agentforce and AWS Bedrock AgentCore, alongside service principals, managed identities, app registrations, and service accounts across your estate, each linked to an owner.
• C1 flags unowned identities and aging credentials before they harden into standing risk, including misclassified accounts and credentials that are expiring or unused.
• C1 turns findings into governed access items. A discovered cloud agent, service account, or credential becomes a real access item on the same fabric that runs your employee access reviews. Assign an owner, route it through request and approval, certify it in a review, and deprovision it when it goes stale. Endpoint findings are rolling into that same inventory for early-access customers now.
• C1 logs every discovery, ownership change, and action so governance produces audit evidence instead of a spreadsheet.

Shadow AI discovery is available to C1 customers now: the inventory across your cloud and identity providers, and the first-party endpoint agent on macOS, with Windows and Linux to follow. Read the launch announcement for a walkthrough of what it finds, or see how it fits into AI access management and AI agent security across the platform. To see how C1 finds and governs the AI already running in your environment, talk to our team.

Frequently asked questions#

What is an example of shadow AI?#

A developer installs an AI coding assistant, connects it to three MCP servers including one that reads the production database, and stores the credentials in a plaintext config file on their laptop. Nobody approved the tool, nobody knows the MCP connections exist, and the credentials never entered a vault. That is shadow AI in its most common form.

Is ChatGPT shadow AI?#

ChatGPT becomes shadow AI when employees use it through personal accounts or without organizational approval. The same tool is sanctioned AI when IT has approved it, provisioned it through your identity provider, and set data handling rules. Shadow AI describes the governance status, not the product.

What is the difference between shadow AI and shadow IT?#

Shadow IT is an unapproved application a person logs into. Shadow AI is an unapproved AI system that authenticates on its own, holds its own credentials, and takes action without a person in the loop. Shadow IT expands your application inventory. Shadow AI expands your identity inventory, which is the harder one to govern.

How do you discover shadow AI tools used by employees?#

Run discovery across two surfaces. In the cloud and your identity providers, enumerate service principals, managed identities, service accounts, and platform-native AI agents. On endpoints, scan for installed AI tools, the MCP servers they declare, and the credential files they write to disk. Resolve both into one inventory and assign an owner to every finding.

Can DLP, CASB, or EDR detect shadow AI?#

Only partially. DLP and CASB watch sanctioned applications and network traffic, so they miss local MCP servers that never touch the network. EDR watches processes for malicious behavior, and an AI tool reading a config file looks ordinary. Each control assumes an identity is a person or an approved application, and AI agents are neither.

What are MCP servers and why do they matter for shadow AI?#

An MCP server gives an AI tool access to external data and systems through the Model Context Protocol. They matter because a single AI assistant can declare several, each holding its own credentials to real production systems. A local MCP server exchanges its messages with the AI tool on the machine itself, so proxy and cloud-based discovery never see which tools the AI can reach or what it asked them to do.

How do you prevent shadow AI without blocking AI adoption?#

Make the approved path faster than the unapproved one. Publish a catalog of sanctioned AI tools, grant access on the same day through policy-based approval, and govern the credentials those tools hold rather than banning tools by name. Blocking drives adoption underground, where you lose visibility entirely.

Are AI agents non-human identities?#

Yes. An AI agent authenticates, holds credentials, and acts on systems, which makes it a non-human identity under any working definition. It is also the fastest-growing and least-governed category of NHI, because agents create their own credentials across clouds and endpoints faster than identity programs track them. See human vs. non-human identities for how the two differ in practice.