Shadow AI is the unapproved use of AI tools at work. Here is what it actually is, why it creates security and compliance exposure, and how Bifrost Edge brings it under control at the endpoint.

Somewhere in your company right now, someone is pasting a customer list into a personal ChatGPT account to clean up an email. A developer has a coding agent pointed at a repo that still has live credentials in it. Someone in marketing wired up an MCP server they found over the weekend so their assistant can pull from a CRM. None of it shows up anywhere the security team can see.

That is shadow AI: people using AI tools for work faster than anyone can govern them. It is rarely reckless. The tools are genuinely useful, they are one click away, and most people have no real sense of what happens to the text they paste into them.

The scale is what tends to surprise teams. A 2025 UpGuard report found that more than 80% of workers use unapproved AI tools, security professionals included, and that half use them regularly. This is not a fringe behavior at the edges of the org. It is most people, most days.

What counts as shadow AI

Shadow AI is any AI tool used for work without security review or central oversight. It is the AI version of shadow IT, except it moved faster and the data leaving the building is often more sensitive.

It usually shows up in four shapes:

• Consumer chat apps used with work data: ChatGPT, Claude, and the rest, on personal accounts.
• AI inside the browser, where a prompt box is one tab away at all times.
• Coding agents in the terminal and IDE, which can read source, run commands, and touch infrastructure.
• MCP servers, the external tools an AI app connects to so it can read files, call APIs, and take actions.

The first two leak data outward. The last two are more interesting, because they let an AI tool do things, often with whatever access the employee already has.

Why it is an actual security problem, not just a policy headache

The risk is not that AI is dangerous in the abstract. It is that sensitive data is moving into systems nobody is watching, and the record of it moving does not exist.

A few concrete failure modes:

• Data you cannot account for. Once a prompt with PII, source code, or a contract lands in an unapproved tool, you have no log of what left or where it went. That is a problem on its own and a much bigger one during an audit.
• Compliance frameworks assume you know. GDPR and HIPAA both rest on being able to say where regulated data is processed. Unlogged AI usage quietly breaks that assumption.
• Agents inherit access. A coding agent or an MCP server runs with the user's permissions. If its configuration is compromised, so is everything that user could reach.
• No attribution. Without a central record, there is no per-person view of which model was called, with what data, at what cost.

This is already showing up in incident data. An Okta survey reported by CIO Dive found that 58% of executives said their organization had an AI-related security incident or a close call in the past year. The gap between "we have a policy" and "we know what is happening" is where those incidents live.

Why the controls you already have miss it

Most security controls were built for traffic that crosses the network. A lot of AI usage does not.

A network proxy or DLP system can only inspect what passes through it. A developer running a coding agent in a terminal, or someone using a desktop AI app on a managed laptop, may never route through that choke point at all. The traffic goes straight from the machine to a model provider.

Blocklists have the same blind spot. You can block the tools you know about, but new AI apps appear constantly, and a blocked app tells you nothing about the dozen still running quietly next to it.

And acceptable-use policies do the least of all. A policy document does not enforce anything, and survey after survey shows that people keep using the tools regardless of what the policy says. One ManageEngine study found 93% of employees admit to entering information into AI tools without approval.

The common thread is location. The AI people actually use runs on their own machines. So that is where it has to be governed.

How Bifrost Edge governs shadow AI at the endpoint

If the traffic does not reliably cross the network, the only place left to see and control it is the device itself. That means something running on each machine that can route AI traffic through whatever governance you already have, without asking every employee to reconfigure their tools.

This is the problem Bifrost Edge solves. It runs on each computer in an organization and routes AI traffic from desktop apps, browser AI, and coding agents through Bifrost in the background. The virtual keys, budgets, audit logs, and guardrails you would normally apply at the gateway now apply to the AI people use on their laptops.

The mechanics are deliberately boring. After a one-time browser sign-in through your existing SSO, Edge runs as a small menu-bar or system-tray agent and routes traffic automatically, with no base URL to change and no SDK to swap. From there, a request takes a simple path:

1. Someone uses whatever AI app they already have.
2. Edge routes the request through your Bifrost instead of letting it go straight to the provider.
3. Bifrost ties it to a virtual key, runs your guardrails against it, and writes the exchange to your audit logs.
4. The governed response comes back to the app, and the person keeps working.

That path is what turns a few previously impossible things into routine ones:

• Sensitive data gets caught before it leaves the machine. The same PII, secrets, and content-safety rules you set once now run against prompts from any supported app, and they run before the prompt reaches a model. A pasted API key or customer record is redacted or blocked at the source, not flagged after the fact.
• You can finally see the MCP servers. Edge reads the MCP configuration inside supported apps and builds a live inventory of what is connected across the fleet, then lets you allow or deny each server, enforced on the device. For most teams this is the first real answer to "what MCP servers are running on company machines?"
• You decide which apps run at all. App policy is set centrally; approved apps run normally, and unapproved ones are blocked before data leaves the machine.

None of this requires touching individual machines. It rolls out through Jamf, Intune, or Kandji like any other managed app.

The honest version of where this lands

Shadow AI is not going to be policied away. People have decided AI is part of how they work, and they are right. The real question stopped being whether to allow it and became whether you can see it and put sane limits around it.

The tools that depend on network traffic or on people behaving will keep missing most of it, because most of it runs on the endpoint. Governing AI where it actually runs is the approach that matches how people use these tools today. That is what Bifrost Edge is built to do.

Bifrost Edge is currently in alpha. If endpoint AI governance is a problem you are sizing up, the Edge overview is the place to start, and there is an alpha sign-up at the top of that page.