TL;DR
- A 2025 IBM Security report found that one in five organizations experienced a security breach directly linked to shadow AI usage.
- Traditional perimeter firewalls and SaaS security brokers miss developer coding agents, local Model Context Protocol (MCP) servers, and personal desktop AI applications.
- Effective shadow AI discovery requires systematic auditing across network egress, OAuth identity grants, local developer configuration files, and endpoint agents.
- Bifrost, an open-source AI gateway by Maxim AI, provides the centralized governance plane, while Bifrost Edge extends discovery and policy enforcement directly to employee endpoints.
According to a 2025 study by IBM Security on the cost of data breaches, organizations with extensive shadow AI adoption incurred average breach costs that were $670,000 higher than organizations with formal AI access controls. Most engineering and product teams do not adopt unauthorized tools with malicious intent; they adopt them because consumer generative models solve immediate technical bottlenecks faster than corporate procurement processes can approve enterprise licenses. The resulting challenge is that sensitive proprietary source code, internal system schemas, and confidential customer records are continuously submitted to external model providers without corporate oversight. Securing an enterprise therefore requires comprehensive shadow AI discovery that bridges the gap between centralized network gateways and the individual devices where work actually happens.
What is Shadow AI Discovery?
Shadow AI discovery is the continuous identification, cataloging, and risk assessment of all artificial intelligence models, applications, developer extensions, and agentic integrations operating inside an enterprise without formal security or IT approval. It establishes full visibility into which teams transmit corporate data to external LLMs and which tools possess system permissions.
While legacy shadow IT centered on unauthorized cloud storage or third-party project management applications, shadow AI introduces distinct technical threats. Software as a service (SaaS) tools primarily store static data at rest. In contrast, generative AI tools ingest prompts, dynamically generate executable code, retain context within ephemeral chat histories, and, in many cases, use customer inputs to train public foundation models.
Furthermore, the rapid rise of agentic architectures means modern AI tooling no longer acts as a passive text processor. Through local protocols and remote application programming interfaces (APIs), AI clients can read internal directory structures, query production databases, and execute terminal commands on employee workstations. Shadow AI discovery must therefore locate not only web-based chat interfaces, but also headless background daemons, IDE extensions, command-line interfaces (CLIs), and local communication bridges.
| Dimension | Legacy Shadow IT | Shadow AI |
|---|---|---|
| Primary Interaction | File storage, document editing, SaaS portals | Prompt submission, code generation, autonomous execution |
| Data Ingestion | Stored files at rest | Dynamic training ingestion, context window retention |
| System Capabilities | Passive storage and display | Local shell execution, file system access, API tool calling |
| Discovery Blind Spots | Centralized SaaS logins | Terminal agents, local MCP servers, ephemeral browser sessions |
| Regulatory Exposure | GDPR, SOC 2 data storage clauses | EU AI Act, NIST AI 100-1, OWASP LLM02, HIPAA, ISO 42001 |
Where Shadow AI Hides Across Enterprise Infrastructure
Shadow AI operates across four distinct infrastructure surfaces: browser-based chat applications, standalone desktop clients, terminal coding assistants, and local integration middleware.
First, browser sessions represent the highest volume of informal usage. Employees routinely copy and paste excerpts of customer support tickets, legal agreements, and proprietary source code into public web interfaces to draft responses or debug syntax. Because these sessions often run under personal consumer accounts rather than enterprise single sign-on (SSO), data protection agreements and zero-data-retention guarantees do not apply.
Second, dedicated desktop applications, such as standalone distributions of ChatGPT, Claude Desktop, and native IDE distributions like Cursor, run locally on macOS, Windows, and Linux machines. These clients operate outside standard browser security policies and frequently persist prompt histories across unencrypted local caches.
Third, command-line coding agents, including Claude Code, Codex CLI, and Gemini CLI, run directly inside developer terminals. These utilities read local source code files, index project trees, and automatically send system metadata alongside code diffs to cloud endpoints to generate automated pull requests.
Fourth, Model Context Protocol (MCP) servers create local communication bridges on employee laptops. By connecting local coding tools directly to file systems, GitHub repositories, PostgreSQL databases, and Slack instances, MCP integrations expose internal enterprise data without generating obvious HTTP outbound requests toward typical web application domains.
The Primary Vectors of Shadow AI Risk
Unmonitored AI usage exposes organizations to severe security vulnerabilities, regulatory penalties, and unmanaged infrastructure expenses. Security teams must evaluate these threats through four specific operational vectors:
1. Sensitive Data Exposure (OWASP LLM02)
The OWASP Top 10 for Large Language Models ranks Sensitive Information Disclosure as a critical risk (LLM02:2025). When employees query ungoverned models, proprietary business logic, client personally identifiable information (PII), and intellectual property leave the enterprise perimeter. A study by Cyberhaven Labs found that 11% of information pasted into public AI tools consists of sensitive corporate data, including confidential customer records and internal system passwords. Once ingested by public model APIs that lack enterprise data-handling agreements, this data cannot be retracted.
2. Credential Invalidation and Non-Human Identity Exposure
Many developer-focused AI tools require API keys, personal access tokens, or unvetted OAuth consent grants to interface with enterprise systems. Developers frequently generate long-lived API tokens for personal accounts to bypass internal request processes. These tokens sit unencrypted in local environment files (.env), terminal shell profiles (.zshrc, .bashrc), or desktop configuration objects, bypassing corporate identity governance and multi-factor authentication policies.
3. Unauthorized Local Tool Execution and Poisoning
Agentic tools operating via protocols like MCP can execute local shell commands and call APIs autonomously. When an unsanctioned tool executes system operations without centralized logging or human-in-the-loop review, malicious or malformed model responses can trigger unauthorized file deletions, schema alterations, or data exfiltration. Tool poisoning attacks, where an external prompt or compromised model directs a local agent to run shell scripts, present a major threat to workstation integrity.
4. Regulatory Non-Compliance and Audit Penalties
International regulatory frameworks now demand strict auditability for generative AI systems. The European Union AI Act mandates rigorous documentation, transparency, and logging for AI systems handling personal data. Concurrently, the NIST AI Risk Management Framework (NIST AI 100-1) requires organizations to maintain an accurate inventory of all operational AI systems. Shadow AI eliminates the paper trail, creating automatic compliance audit failures under SOC 2 Type II, ISO 27001, and HIPAA.
Five Technical Methods to Detect Shadow AI
Discovering shadow AI requires a layered detection strategy that combines network traffic inspection, credential audits, and direct endpoint scanning. Relying on a single mechanism leaves massive operational blind spots.
1. Network Egress and DNS Telemetry Analysis
Organizations can monitor perimeter DNS query logs and egress web proxies to detect connections toward known LLM provider endpoints. Security operations center (SOC) analysts can filter firewall and proxy telemetry for requests directed at model API hosts, such as:
api.openai.com
api.anthropic.com
generativelanguage.googleapis.com
bedrock-runtime.*.amazonaws.com
api.deepseek.com
*.mistral.ai
api.groq.com
While network inspection flags bulk volume, it fails when developers run local open-source models using runtimes like Ollama or llama.cpp, or when remote workers access web models over personal home networks without active VPN connections.
2. SaaS Identity and OAuth Consent Audits
Unsanctioned AI applications often authenticate by requesting access to corporate Google Workspace or Microsoft Entra ID (Azure AD) tenants. Identity administrators must run scheduled audit scripts against their identity provider to enumerate all third-party enterprise applications that hold permissions such as offline_access, Mail.Read, User.Read, or Files.ReadWrite.
For Microsoft Entra ID environments, security engineers can query OAuth grants using Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Application.Read.All","DelegatedPermissionGrant.Read.All"
Get-MgServicePrincipal -All | Where-Object {
$_.DisplayName -match "AI|Copilot|GPT|Claude|Assistant|LLM"
} | Select-Object DisplayName, AppId, Homepage
Reviewing granted OAuth scopes highlights tools that have gained persistent access to employee email accounts, cloud drives, and internal team chat histories.
3. Procurement and Expense Auditing
A significant portion of shadow AI operates on individual employee corporate credit cards or personal reimbursement requests. Finance and security teams should collaborate to run automated quarterly keyword scans across expense platforms like Expensify, Brex, and SAP Concur. Flagging recurring charges containing strings such as "OpenAI", "Anthropic", "Cursor", "Perplexity", "Midjourney", or "Replicate" catches software subscriptions that have bypassed formal procurement approval cycles.
4. Local Developer Workstation File Auditing
Developers frequently store configuration files for coding assistants, local model hosts, and custom tools directly in their user home directory. IT teams can deploy scripts via their mobile device management (MDM) platforms to scan workstations for known AI configuration artifacts:
#!/usr/bin/env bash
# Audit common AI assistant configuration paths
CONFIG_PATHS=(
"$HOME/.config/claude-code"
"$HOME/.cursor"
"$HOME/.config/ollama"
"$HOME/Library/Application Support/Claude/claude_desktop_config.json"
"$HOME/.codex/config.json"
)
echo "Scanning for local AI configurations..."
for path in "${CONFIG_PATHS[@]}"; do
if [ -e "$path" ]; then
echo "[FOUND] AI configuration present at: $path"
fi
done
5. Automated Endpoint Discovery and Routing
The most robust approach to discovering shadow AI is through native endpoint agents deployed fleet-wide. Dedicated endpoint software inspects active system processes, detects installed desktop clients, identifies local MCP tool bindings, and monitors local terminal commands across developer environments. This grants visibility into both remote API calls and local model execution before prompts leave the workstation.
| Discovery Method | Target Surfaces | Key Strengths | Blind Spots |
|---|---|---|---|
| DNS / Web Proxy Logs | Central network egress | Broad coverage of office and corporate VPN traffic | Misses off-VPN laptops, mobile devices, and local LLMs |
| OAuth Consent Audits | Corporate SSO and SaaS identities | Surfaces apps with persistent cloud data access | Misses personal consumer accounts and local tools |
| Expense Auditing | Credit card statements | Surfaces paid individual productivity tiers | Misses free tiers, open-source models, and developer APIs |
| File System Audits | User home directories | Identifies installed CLI tools and local configuration files | Periodic; does not inspect runtime data transmission |
| Endpoint AI Agents | Machine processes, MCP servers, IDEs | Continuous runtime visibility; detects local and cloud AI | Requires MDM deployment to company-managed devices |
Uncovering Shadow MCP Servers: The Blind Spot in AI Tooling
A major technical blind spot in enterprise security is the rapid proliferation of Model Context Protocol (MCP) servers. Anthropic introduced the open standard to allow AI clients to connect dynamically with external databases, APIs, and file systems. However, when developers install community-built MCP servers on their local workstations, they create ungoverned pathways into protected internal systems.
In a typical developer environment, a tool like Claude Desktop or Cursor references a local JSON configuration file that defines which MCP servers to launch as background subprocesses. A developer attempting to analyze customer database records might configure an MCP server like this:
{
"mcpServers": {
"internal-analytics-db": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://read_user:ProdSecretPassword123@db.internal.company.com:5432/production"
]
},
"local-filesystem-bridge": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/developer/Documents/ConfidentialProjects"
]
}
}
}
This configuration introduces three critical vulnerabilities:
- Unencrypted Credentials: Production database credentials and connection strings sit in plain text on the local hard drive.
- Arbitrary Local Execution: The AI model can formulate structured queries that the local MCP server executes directly against the production database, returning unmasked customer data into the model context.
- No Centralized Audit Trail: Because the database query executes over a local loopback interface before the summarized text is sent to the LLM, centralized database audit firewalls only see legitimate connections coming from the developer workstation, completely obscuring the role of the AI agent.
Discovering shadow MCP servers requires auditing developer configuration files across every machine and cataloging which executables and arguments are actively registered.
How Bifrost and Bifrost Edge Unify Shadow AI Discovery and Governance
Discovering shadow AI is only valuable if an enterprise has an architectural mechanism to govern that traffic without destroying developer productivity. Attempting to outright block all AI endpoints with a web firewall causes developers to find workarounds, routing traffic through personal mobile hotspots or personal laptops. The correct technical solution is to combine a high-performance centralized control plane with transparent endpoint visibility.
This is the design philosophy behind Bifrost, an open-source, Go-based AI gateway built by Maxim AI. Bifrost acts as the centralized policy engine and control plane for enterprise AI traffic, adding just 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks. Through Bifrost, platform teams manage multi-provider routing across 1,000+ models, apply virtual keys with granular budget limits, and inspect all enterprise AI usage from a unified interface.
Beyond server-side routing, Bifrost applies comprehensive governance and security controls (virtual keys, budgets, guardrails, audit logs) centrally, and Bifrost Edge extends that same governance and security directly to AI traffic on employee machines, with endpoint enforcement on each device.
Currently in early-access alpha, Bifrost Edge operates as an endpoint agent on macOS, Windows, and Linux. It solves the shadow AI problem by routing workstation AI traffic directly through the centralized Bifrost gateway, eliminating the need for developers to manually alter base URLs or rewrite SDK configurations in their local scripts.
Bifrost Edge addresses the shadow AI challenge across three core operational capabilities:
1. Fleet-Wide App Discovery and Inventory
Instead of wondering which tools employees run, security administrators use the Bifrost Edge admin devices dashboard to maintain a live, automated inventory of all active AI software across the fleet. Bifrost Edge automatically catalogs supported applications, including desktop tools (Claude Desktop, ChatGPT, Cursor), web interfaces, and terminal coding assistants (Claude Code, Codex CLI, OpenCode). Admins gain instant visibility into tool versions, hostnames, active users, and connection statuses.
2. Discovered MCP Server Auditing and Enforcement
To address the danger of unvetted local bridges, Bifrost Edge inventories all MCP servers configured inside AI applications across every workstation. Through the MCP governance engine, security teams view a deduplicated catalog of all registered servers across the fleet. Administrators can make per-server allow or deny decisions on the admin approvals dashboard. When an administrator denies an unvetted or vulnerable MCP server, that decision is enforced locally on the device, terminating the bridge even if the developer configured it manually.
3. Centralized Guardrails and Audit Logging
Because Bifrost Edge transparently routes endpoint traffic through the central gateway, organizations can apply enterprise guardrails to prompt traffic originating from employee workstations. Prompts and completions are scanned using secrets detection (backed by Gitleaks) to redact API keys and passwords, alongside custom regex filters for corporate PII, AWS Bedrock Guardrails, and Azure Content Safety. Every interaction generates an immutable audit trail captured in Bifrost's centralized audit logs, satisfying compliance mandates under SOC 2, HIPAA, and GDPR.
A Step-by-Step Playbook: Moving from Discovery to Governed AI
Discovering shadow AI is an ongoing operational process. Organizations should follow this five-stage implementation playbook to move from total obscurity to structured governance:
+-----------------------------------------------------------------------+
| 1. Passive Endpoint Audit |
| Deploy Bifrost Edge via MDM to inventory apps and local MCP tools |
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+
| 2. Triage and Risk Scoring |
| Classify discovered apps into Approved, Pending, or Denied catalogs|
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+
| 3. Centralized Gateway Routing |
| Route allowed endpoint tools through Bifrost with Virtual Keys |
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+
| 4. Automated Policy Enforcement |
| Enforce secrets detection, PII masking, and team budget ceilings |
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+
| 5. Continuous Audit and Education |
| Review immutable audit logs and provide sanctioned access paths |
+-----------------------------------------------------------------------+
Stage 1: Deploy Non-Intrusive Endpoint Visibility
Begin by deploying Bifrost Edge silently across your workstation fleet using an existing mobile device management solution through standard MDM deployment protocols. Tools like Jamf Pro, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud can push the lightweight binary alongside a managed configuration profile.
During this initial phase, operate the agent in discovery mode. Do not immediately block tools or interrupt user workflows. Allow the agent to check in and build a baseline catalog of installed desktop apps, terminal agents, and active MCP servers across all engineering and business units.
Stage 2: Triage and Risk-Score Discovered Applications
Examine the discovered catalog within the Bifrost Edge admin console. Categorize all detected tools into three distinct operational buckets:
- Sanctioned (Approved): Enterprise-grade tools that comply with company data policies (for example, corporate-licensed IDEs or internal gateway endpoints).
- Provisional (Pending Review): Productive tools that lack formal contracts but provide clear business utility. These tools will be permitted only under enforced gateway routing with strict data masking.
- Prohibited (Denied): Tools known to train on customer data, unverified third-party browser extensions, or community MCP servers that require raw local shell access. Deny these tools directly through the policy console to block execution on the device.
Stage 3: Channel Traffic Through Virtual Keys
Provide a sanctioned, low-friction path for developers to use approved models. In the central Bifrost gateway, generate virtual keys mapped to specific engineering teams, departments, or project scopes. Assign hard monthly budgets and rate limits to each key to prevent runaway operational spend. Because Bifrost Edge integrates with the workstation's menu bar or system tray, employees can authenticate once via corporate SSO and select their team's assigned virtual key without managing raw upstream API credentials.
Stage 4: Enforce Automated Guardrails on Outbound Traffic
Configure centralized guardrails within the Bifrost gateway to inspect all outbound traffic channeled from the endpoints. Enable native secrets detection to intercept GitHub personal access tokens, AWS secret keys, and database passwords before requests leave the local environment. Implement regex patterns to automatically scrub customer email addresses, social security numbers, and proprietary intellectual property tags.
Stage 5: Maintain Continuous Visibility and Developer Buy-In
Shadow AI will return if corporate governance introduces excessive friction. Security teams must maintain an open dialogue with engineering leads. Regularly review the Bifrost audit logs to assess model usage trends, token volumes, and frequent prompt rejection reasons. If many engineers attempt to access a newly released open-source reasoning model, platform teams can configure Bifrost to route traffic to that model through an enterprise provider like AWS Bedrock or Google Cloud Vertex AI within minutes, maintaining safety while providing engineers with modern tooling.
Frequently Asked Questions
What is shadow AI discovery?
Shadow AI discovery is the technical process of identifying, cataloging, and analyzing all unsanctioned generative AI applications, large language models, coding assistants, and Model Context Protocol servers operating within an organization. It provides visibility into unauthorized prompt transmissions, credential usage, and sensitive data exposure.
How do you detect shadow AI across an enterprise?
Detecting shadow AI requires a layered inspection model: analyzing firewall and DNS proxy logs for connections to public LLM API hosts, scanning identity providers for unauthorized third-party OAuth consent grants, auditing corporate expense reports for AI subscriptions, and deploying endpoint discovery agents to inspect local system processes, IDE extensions, and configuration files.
What is the technical difference between shadow IT and shadow AI?
Shadow IT involves unapproved static software or cloud storage that stores data at rest. Shadow AI involves dynamic tools that ingest confidential context into ephemeral prompts, use customer data to train external foundation models, execute code locally, and interact autonomously with local file systems and databases via protocols like MCP.
How do developer coding agents contribute to shadow AI?
Developer agents like Claude Code, Cursor, and Codex CLI index local directories, parse source code repositories, and generate automated terminal commands. If left ungoverned, they transmit proprietary intellectual property to external LLM providers and expose local system shells to unverified model-generated instructions without generating traditional browser traffic.
Can traditional web firewalls block shadow AI effectively?
No. Web firewalls and CASBs only inspect traffic passing through corporate networks or VPNs. They fail to detect local open-source models running on the device, cannot identify MCP subprocess bridges executing on localhost, and are easily bypassed when employees use personal mobile hotspots or work outside the corporate network.
What is a shadow MCP server?
A shadow MCP server is an unvetted Model Context Protocol integration installed on an employee device without security team review. Because MCP gives models programmatic access to query local databases, inspect files, and execute shell scripts, unsanctioned MCP servers create major pathways for privilege escalation, tool poisoning, and data exfiltration.
Bringing Shadow AI into the Light
Treating shadow AI solely as a disciplinary issue is a losing battle. When organizations attempt to solve AI adoption by blanket-blocking external domains, they blind themselves to the tools their employees inevitably use to remain competitive. Sustainable enterprise security requires proactive shadow AI discovery paired with frictionless, governed alternatives.
By deploying an infrastructure architecture that combines the centralized policy engine of the Bifrost gateway with the endpoint visibility of Bifrost Edge, security teams can identify unsanctioned AI applications, eliminate shadow MCP bridges, and enforce strict data guardrails without disrupting technical workflows. Organizations evaluating approaches to discovering and governing AI traffic across their infrastructure can request a Bifrost demo or review the open-source repository.


Top comments (0)