Shadow AI Detection: What Shadow AI Is and How to Detect It
TL;DR
- Shadow AI is any AI use inside an organization outside approved, governed channels: browser chat, desktop AI apps, coding agents, and the MCP servers wired into them.
- IBM's 2025 Cost of a Data Breach Report found one in five breached organizations reported a breach involving shadow AI, at $670,000 in additional average breach cost.
- Network and gateway telemetry cannot discover shadow AI: a gateway sees only traffic someone configured to send it, and the network sees hostnames rather than users, prompts, or approval status.
- Bifrost, the open-source AI gateway, is the control plane for virtual keys and budgets, with guardrails and audit logs in Bifrost Enterprise, and Bifrost Edge carries those policies to every macOS, Windows, and Linux machine.
- Bifrost Edge inventories the AI apps and MCP servers on each device, deduplicates them into fleet-wide catalogs, and enforces allow and deny decisions on the machine. Edge is in alpha.
Shadow AI detection is the process of discovering AI tools and traffic operating outside an organization's approved, governed channels. IBM's 2025 Cost of a Data Breach Report found that 20% of breached organizations reported a breach involving shadow AI, and only 37% have policies to manage or detect it. Bifrost, an open-source AI gateway built in Go by Maxim AI, treats this as a two-layer problem: the gateway governs AI traffic centrally, and Bifrost Edge extends that governance to the machines where ungoverned usage originates. This post covers what shadow AI is, why conventional detection misses it, and how endpoint discovery closes the gap.
What Is Shadow AI?
Shadow AI is the use of AI models, applications, or agents inside an organization without approval, visibility, or policy enforcement from security and platform teams. The defining characteristic is not that the tool is malicious. It is that its traffic never passes a control point.
A request from a personal ChatGPT account to api.openai.com looks identical on the wire to an approved one, but carries no virtual key, no budget attribution, no guardrail evaluation, and no audit record. Governance inside an AI gateway cannot reach traffic that never arrives. Four surfaces produce it:
- Browser AI: chat on chatgpt.com and claude.ai, plus AI inside web apps.
- Desktop AI applications: Claude Desktop, the ChatGPT desktop app, Cursor, and Codex.
- Coding agents: Claude Code, Codex CLI, OpenCode, and similar terminal agents.
- MCP servers: tool servers connected to those agents, able to read files, call internal APIs, and act on a user's behalf.
The fourth is newest and least visible. A fuller treatment is in the overview of shadow AI as an ungoverned risk inside every company.
Shadow AI vs Shadow IT: Why the Old Playbook Fails
Shadow IT was a procurement problem, discoverable through expense reports, OAuth grants, and CASB inventories. Shadow AI produces no such record: the tools are free, installed locally, and authenticated with personal credentials.
- No purchase trail. Free tiers and personal accounts leave nothing in finance systems.
- Local execution. Desktop apps and CLI agents call provider APIs directly, bypassing SaaS-oriented tooling.
- Shared destinations. Approved and unapproved usage hit the same hostnames, so domain-based inventory cannot separate them.
A team can hold a complete shadow IT inventory and still not know which models employees send source code to, which is why endpoint AI governance is now a distinct discipline.
The Risks of Shadow AI in the Enterprise
Shadow AI risks fall into four categories: data exposure, compliance failure, uncontrolled cost, and unbounded tool execution. Each follows from AI traffic that no policy layer inspects. IBM reports that shadow AI incidents compromised personally identifiable information in 65% of cases, against a 53% global average.
| Risk category | What goes wrong | What removes it |
|---|---|---|
| Data exposure | Source code, records, and credentials pasted into ungoverned models | Guardrails applied before the prompt leaves the machine |
| Compliance failure | No record of who sent what to which model | Verifiable audit logs plus gateway request logging |
| Uncontrolled cost | Personal API keys and spend outside any budget | Virtual keys with budgets at the key, team, and customer levels |
| Unbounded tool execution | MCP servers reading files and calling APIs with no allow list | Per-server decisions enforced on the device |
Frameworks such as the NIST AI Risk Management Framework expect an inventory of AI systems in use, and one that omits every self-installed tool does not satisfy it. Centralizing usage through governance controls is what makes that inventory real.
How to Detect Shadow AI: Signals and Tools
Shadow AI detection collects evidence at four layers: network traffic, identity and OAuth grants, endpoint configuration state, and gateway telemetry. Each sees a different slice of the same behavior, and the strongest signal comes from the endpoint, where the AI application is installed and its MCP servers are configured.
- DNS and egress to model provider domains. Identifies destinations, not users, prompts, or approval status.
- OAuth and SSO grant logs. Reveals AI SaaS granted corporate identity, misses personal accounts.
- Expense and procurement anomalies. Catches paid team plans, misses the free tiers behind most shadow AI.
- Endpoint application and MCP inventory. Enumerates the AI apps installed on each machine and the MCP servers configured inside them.
- Gateway request telemetry. Every request that reaches a control point carries an identity, virtual key, cost, and guardrail verdict.
The first three are heuristics. The last two produce an inventory precise enough to act on, as covered in the guide to identifying unapproved AI tools. Detection tools map onto the same positions, and position fixes what each can see.
| Detection position | Sees | Cannot see |
|---|---|---|
| Network / CASB | Domains contacted, request volume, TLS metadata | Prompt content, which user, whether it was approved |
| Identity provider | OAuth grants, SaaS sign-ins with corporate identity | Anything on a personal account or a raw API key |
| Gateway | Every request that reaches it, with identity and cost | Traffic that was never configured to route through it |
| Endpoint agent | Installed AI apps, configured MCP servers, per-device check-in state | Unmanaged or personal devices |
The gateway row is the one teams most often over-trust: it is a strong measurement point and a weak discovery point, observing only what someone already chose to send it. Blocking by domain does not fix that, since denying api.anthropic.com breaks the approved coding agent alongside the unapproved one. The same applies to tool servers, as covered in the analysis of shadow MCP servers and control at the gateway.
The AI Gateway as the Control Plane
An AI gateway is a unified control point that routes, authenticates, governs, and observes traffic to multiple model providers through a single API. In Bifrost, virtual keys are the primary governance entity, carrying access permissions and budgets and rate limits per consumer.
In Bifrost Enterprise, guardrails evaluate prompts and responses, and audit logs record administrative activity, with entries optionally HMAC-signed so they can be verified, retained, and exported. Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second on a t3.xlarge instance. The policy set is not the problem. Reach is: every control above applies only to traffic that was configured to arrive, which is exactly the traffic that was never shadow AI to begin with.
How Bifrost Edge Detects Shadow AI on Every Machine
Bifrost Edge is the endpoint layer of the same platform. The gateway remains the control plane and policy engine; Edge runs on each machine and routes AI traffic from desktop apps, browser AI, coding agents, and their MCP servers through Bifrost, so the virtual keys, budgets, guardrails, and audit logs already configured apply without per-application setup. Edge runs natively on macOS, Windows, and Linux and is currently in alpha.
Detection comes first. The Devices dashboard lists every machine running the agent, with a fleet summary showing device count, an OS breakdown, and app and MCP server counts by status. Each device reports:
- Hostname and owner, taken from the user signed in on the machine.
- Platform, version, and architecture, plus the Edge agent version.
- Installed AI apps, with versions visible per app.
- Configured MCP servers, with the tools each exposes in the device detail view.
- First seen and last active, separating dormant machines from newly enrolled ones.
The list filters by hostname or owner, platform, a specific installed app or MCP server, and approval status. Filtering by MCP server is the query most organizations cannot answer today: it returns every machine on which a given tool server is configured, which is the difference between suspecting a problem and scoping one.
Coverage today spans Claude Desktop, the ChatGPT desktop app, Cursor, and Codex; the Claude Code, Codex CLI, and OpenCode agents; and ChatGPT and Claude in the browser. MCP discovery covers Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor. The current list is in supported applications.
Turning Detection Into Enforcement With Edge Approvals
Discovered apps and MCP servers land in two catalogs on the Approvals dashboard, each entry carrying a status, the administrator who last changed it, and an optional note. MCP entries also record how the server connects, as a local command or remote URL, and which tools it exposes.
| Status | Meaning |
|---|---|
| Pending | Discovered, awaiting review. It keeps working in the meantime. |
| Approved | Explicitly allowed, running under gateway governance. |
| Denied | Blocked. Edge stops it on the device. |
Two properties make this workable at scale. The catalogs are deduplicated across the fleet, so an MCP server configured on two hundred machines appears once and one decision applies everywhere. And a newly discovered entry is pending by default and keeps working until denied, so switching Edge on produces an inventory rather than an outage. Decisions take effect at each device's next check-in, and bulk actions cover the long tail, including denying every pending MCP server at once.
Enforcement is not advisory. Under app governance, allowed applications run normally with traffic routed through Bifrost, while a disallowed app is blocked before data leaves the machine, with a clear signal to its user. Under MCP governance, a denied server cannot be used even by an app that had it configured before the policy existed. The case for that layer is set out in why MCP needs a governance layer.
Endpoint Guardrails, Configuration, and Fleet Rollout
Because Edge routes AI traffic through Bifrost, every guardrail profile already configured applies to endpoint AI traffic with nothing extra on the device. A prompt typed into ChatGPT in the browser is evaluated before it reaches a model, so secrets and PII are caught before they leave the machine. Coverage includes Gitleaks-backed secrets detection, a custom regex engine with a PII template, AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, Gray Swan Cygnal, Lakera Guard, and Patronus AI.
Two fleet-wide settings live in Configurations, governed by role-based access control. The organization certificate, required because Edge routes encrypted AI traffic through Bifrost, can be generated or imported, with the private key shown only once. The sync interval sets how often agents check in for policy, with a minimum of a few seconds.
Rollout runs through managed configuration in MDM across Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud. Edge installs silently, asks for one setup approval on first run, then the user signs in through the browser with existing single sign-on, linking the machine to their identity and syncing their policies. No secrets sit on the device: the managed configuration carries only connection settings. Edge then lives in the menu bar or system tray showing connection status and the active virtual key with its budget, as described in how Edge works.
Deploy with pending items allowed, review the catalogs once the inventory settles, then deny what the organization does not want. Step-by-step guidance is in rolling out AI governance with MDM, and the combined architecture in closing the last mile of AI governance. In regulated environments, Bifrost Enterprise runs in-VPC or on-premises, so detection never requires sending prompt data to a third party.
Frequently Asked Questions
Is ChatGPT shadow AI?
ChatGPT is shadow AI when used for work through a personal account or an ungoverned browser session. The same product stops being shadow AI once its traffic routes through a control point applying identity, budgets, guardrails, and audit logging. Bifrost Edge governs both ChatGPT on the web and the ChatGPT desktop app.
What are the risks of shadow AI?
The four principal risks are data exposure, compliance failure, uncontrolled cost, and unbounded tool execution. IBM's 2025 research found shadow AI involved in 20% of reported breaches, with $670,000 in additional average breach cost and higher rates of compromised PII and intellectual property than average.
How to detect shadow AI?
Combine DNS egress data, OAuth grant logs, and endpoint inventory, then route the discovered traffic through a gateway for continuous measurement. Endpoint inventory is the highest-value signal, because it enumerates the AI applications and MCP servers on each machine and the tools each exposes.
How to avoid shadow AI?
Remove the reason it forms. Shadow AI appears when the approved path is slower or narrower than the unapproved one, so provide broad model access through a governed gateway and extend that governance to the endpoint so no reconfiguration is required. Blocking without a sanctioned alternative just moves usage to unmanaged devices.
Does Bifrost Edge block AI apps by default?
No. A newly discovered app or MCP server is pending by default and keeps working until an administrator denies it, so deployment produces an inventory rather than an outage. Administrators can configure whether pending items are allowed or blocked, then decide each entry from the fleet-wide catalogs.
What is shadow MCP?
Shadow MCP is the subset of shadow AI covering Model Context Protocol servers users connect to their AI tools without review. These servers can read local files, call internal APIs, and act autonomously, so an unreviewed server is an unreviewed automation path. Fleet-wide inventory and per-server decisions through an MCP gateway address it directly.
Getting Started with Shadow AI Detection
Shadow AI detection begins with an inventory and ends with enforcement, and both work best when one policy governs approved and ungoverned traffic alike. Bifrost is the control plane where virtual keys and budgets are defined, with guardrails and audit logs in Bifrost Enterprise. Bifrost Edge carries those controls to every machine, discovers the AI apps and MCP servers already there, and enforces the resulting decisions on the device.
To see how the AI gateway and Bifrost Edge work together across your fleet, book a demo with the Bifrost team.
