Shadow AI: getting visibility and control
A developer pastes a failing function, including a live API key in the stack trace, into ChatGPT to debug it. A sales manager drops next quarter's forecast into a browser summarizer. A support agent feeds a customer record into a desktop AI app to draft a reply. None of these actions is malicious, and none of them shows up anywhere the security team can see.
This is shadow AI: employees using AI tools the organization has not approved, governed, or even inventoried. It is not fringe behavior. More than 80% of workers report using unapproved AI tools at work, and fewer than 20% say they use only company-approved ones, according to UpGuard research reported by Cybersecurity Dive. The usage is already in place. The open question is whether anyone can see it or control it.
What shadow AI actually is
Shadow AI is the use of AI tools, models, and services by employees without the knowledge, approval, or governance of their IT or security teams. It is the AI-era version of shadow IT, with a sharper edge: instead of storing data in an unapproved app, people actively send sensitive data out to third-party models.
In practice, ungoverned LLM usage shows up as:
- Desktop AI apps such as Claude Desktop and the ChatGPT app, often signed in with personal accounts.
- AI in the browser, where a prompt box sits one tab away from any document on screen.
- Coding agents in the terminal and IDE that read source, run commands, and call external tools.
- MCP servers wired into those apps, which can read files and take actions on a user's behalf.
The common thread is that the data leaves on the prompt. Once it reaches an ungoverned tool, the organization has no record of what was shared, with which provider, or whether it was retained to train a model.
Why shadow AI is a real risk, not just a policy gap
The risk is concrete. IBM's 2025 Cost of a Data Breach Report found that one in five organizations had already experienced a breach tied to unsanctioned AI, and that only 37% of organizations had an AI governance policy at all. A control that does not exist cannot be enforced.
The failure modes are specific:
- Data you cannot account for: prompts carrying source code, credentials, customer records, or financial data, with no log of where they went.
- Compliance assumptions that no longer hold: SOC 2, GDPR, and HIPAA controls all assume sensitive data flows are known and bounded.
- Agents inheriting access: a coding agent or an MCP server runs with the user's permissions and can reach far more than a chat box.
- No attribution: when something does leak, there is no way to trace which tool, user, or session caused it.
Banning the tools does not solve it. Roughly half of employees admit to adopting AI tools without approval, with senior leaders among the heaviest users, and Software AG found that 46% would keep using the tools even if their organization banned them outright. A policy that relies on voluntary compliance tends to fail quietly.
Why network filtering and blocklists miss shadow AI
Most existing controls were built for a network they can watch, and they fall short for AI in three ways.
Network proxies and data loss prevention tools only see what crosses the network in a form they can inspect. AI traffic is TLS-encrypted to major providers the business already allows, so a prompt full of secrets looks like ordinary HTTPS to a trusted domain.
Blocklists are always a step behind. New AI apps, browser features, and coding agents appear faster than any denylist can track, and blocking a domain outright tends to break legitimate work and push usage further underground.
Written policies do not enforce themselves. They set expectations but cannot see a prompt or stop a paste. The deeper point ties these together: the AI runs on the endpoint, often over an encrypted connection the network already permits, so the endpoint is the only place the traffic can be reliably seen and governed. Endpoint AI governance is the missing layer.
How the Bifrost AI gateway and Edge govern shadow AI
Governing shadow AI takes two parts working together: a control plane that holds the policy, and a way to bring endpoint AI under it. Bifrost is the open-source AI gateway by Maxim AI, and it is where the governance lives: virtual keys, budgets, rate limits, guardrails, and audit logs. On its own, a gateway governs the traffic that is configured to point at it, which leaves the ungoverned AI on employee machines untouched.
Bifrost Edge closes that gap. It is the endpoint layer of the same platform, running on each computer in an organization and routing AI traffic from the apps people already use back through the Bifrost gateway. The result is one narrative rather than two products: the gateway governs what is pointed at it, Edge governs what runs on the laptop, and the same policies apply to both. There is nothing new to learn on the policy side, because Edge enforces the exact controls already configured at the gateway. Edge runs natively on macOS, Windows, and Linux, and is currently in alpha.
How a request flows through Edge
The day-to-day experience runs quietly in the background after setup:
- On first run, the user signs in through the browser with the organization's existing single sign-on. That links the machine to the user and syncs their assigned policies. No API keys are copied or pasted.
- Edge then runs as a menu-bar agent on macOS or a system-tray agent on Windows and Linux, showing connection status and the active virtual key.
- The person uses any AI app as usual: a desktop client, ChatGPT in the browser, or a coding agent in the terminal.
- Edge routes that request through Bifrost, which ties it to a virtual key and budget, runs the configured guardrails, and writes the exchange to audit logs.
- The governed response returns to the app. If a guardrail trips, the sensitive content is redacted or blocked before the prompt leaves the machine.
Governance follows the user instead of waiting for each person to opt in or reconfigure a tool.
Visibility: see every AI app and MCP server
Edge gives security teams an inventory of what is actually running. From a single admin dashboard, you can see the devices in the fleet, the AI apps in use, and their governance status.
It also reaches the layer most teams cannot see at all. Edge reads the MCP configuration inside supported apps and builds a live inventory of every MCP server configured across the fleet: which servers exist, in which apps, and on how many devices. Discovery covers major AI apps that support MCP, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor. For most organizations, this is the first real answer to the question of which MCP servers are running on their machines.
Control: allow, deny, and check content at the source
Visibility becomes control through policy enforced on the device. Admins decide which AI apps are allowed on company machines: allowed apps run normally with their traffic governed in the background, and disallowed apps are blocked before any data leaves the machine. MCP servers are governed the same way, allowed or denied one server at a time, and the decision holds even for an app that had the server configured before the policy existed. When Edge detects a new app or server, it requests approval in the admin console.
Content is checked at the source. The guardrail profiles configured in Bifrost apply to Edge traffic without extra setup on the endpoint. A guardrail runs before a prompt reaches a model and before the response returns, so secrets and PII are caught or redacted before they leave the machine. Built-in detection covers leaked credentials and a PII template, alongside integrations with AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, GraySwan Cygnal, and Patronus AI.
Rollout: deploy silently through device management
Because shadow AI is a problem across the whole fleet, the rollout cannot depend on employees installing anything. Edge deploys through standard device management, including Jamf, Intune, and Kandji, using a managed configuration, so it reaches every machine silently. Policy changes then take effect across the fleet at once, without touching individual devices.
Where this leaves security and platform teams
Shadow AI is not going away, and banning it has a track record of failing. The realistic goal is not to stop people from using AI, but to make the AI they already use visible and governed: to know which apps and MCP servers are in play, to keep sensitive data from leaving on a prompt, and to have an audit trail when a question comes up later.
That work has to happen in two places that act as one: the AI gateway, where the policies and audit trail live, and the endpoint, where that ungoverned AI actually runs. The Bifrost gateway provides the control plane, and Bifrost Edge extends it to every machine. For teams sizing up the problem, the Edge overview lays out the full picture, and Edge is in alpha now for organizations that want to bring ungoverned AI usage under that same governance early.
