Shadow AI: How CISOs Get End-to-End AI Governance
TL;DR
- IBM's Cost of a Data Breach Report 2025 found shadow AI was a factor in 20% of breaches and added roughly $670,000 to the average breach cost.
- Shadow AI persists because a gateway governs only the traffic configured to point at it, and desktop chat apps, browser AI, and coding agents are almost never configured that way.
- Bifrost is the control plane for AI governance: virtual keys, budgets, rate limits, guardrails, and signed audit logs, deployed in your own VPC or on-prem.
- Bifrost Edge, currently in alpha, enforces those same gateway policies on every macOS, Windows, and Linux machine with no per-app configuration.
Shadow AI was a factor in 20% of breaches studied in IBM's Cost of a Data Breach Report 2025, adding around $670,000 to the average cost, and 97% of organizations that reported an AI-related breach said they had no proper AI access controls. Security leaders are not short of policy documents; they are short of enforcement points. Bifrost, the open-source AI gateway built in Go by Maxim AI, gives CISOs one place to define AI policy and two places to enforce it: the gateway for application traffic, and the endpoint for everything else. This post covers what end-to-end AI governance requires, where the usual architectures leave a gap, and how the gateway and endpoint model closes it.
What Is Shadow AI?
Shadow AI is the use of AI tools and models inside an organization without security review, access controls, or audit coverage. It covers personal ChatGPT accounts in a browser tab, unapproved desktop assistants, coding agents pointed at consumer API keys, and MCP servers wired into those tools by individual engineers.
The category grew out of ordinary employee behavior rather than malice. Microsoft and LinkedIn's 2024 Work Trend Index reported that 75% of knowledge workers use generative AI at work and 78% of those users bring their own AI tools. When procurement moves slower than a free download, people route around it. A fuller treatment of the exposure categories is in this breakdown of shadow AI risks in enterprises, and a plain-language definition is in what shadow AI is and why it exists inside every company.
Why Shadow AI Survives Most AI Governance Programs
Most AI governance programs fail on shadow AI for a structural reason: they are enforced at the application layer, and the usage happens outside it. A gateway governs the traffic that was configured to reach it. Traffic from a laptop that was never configured never arrives, so it is never governed.
That gap explains the IBM finding that 63% of organizations have no AI governance policy capable of preventing shadow AI use. Three enforcement approaches are commonly tried, and each leaves a measurable share of AI traffic uncovered:
- Written policy and training. Establishes intent and creates an audit artifact, but produces no telemetry and blocks nothing.
- Network blocking of consumer AI domains. Stops the well-known destinations, pushes usage to personal devices, and offers no visibility into what was attempted.
- SDK-level integration of an approved gateway. Governs first-party applications well, and covers none of the AI a person opens by clicking an icon.
The residual risk sits in the third case. Engineering traffic gets governed because engineers change base URLs. Everything else stays invisible. The seven exposure categories this creates, and the control that addresses each, are covered in shadow AI risks and the control for each.
What CISOs Require From an AI Governance Platform
An AI governance platform is judged by a security organization on whether it produces the same artifacts every other control produces: an inventory, an enforcement point, an identity binding, and an evidence trail. The table below states each requirement first and the mechanism second.
| CISO requirement | What it means in practice | Where Bifrost enforces it |
|---|---|---|
| Inventory | A live list of which AI apps and MCP servers exist across the fleet | Endpoint, via the devices and approvals dashboards |
| Identity binding | Every AI request tied to a named user through existing SSO | Gateway, via OIDC provisioning and virtual keys |
| Preventive control | Sensitive content stopped before it reaches a model provider | Gateway guardrails, applied to both application and endpoint traffic |
| Cost containment | Hard budget and rate limits per user, team, and customer | Gateway, via the virtual key hierarchy |
| Least privilege | Scoped administrative access to policy and logs | Gateway, via role-based access control |
| Evidence | Signed, retained records of who changed policy and when | Gateway audit logs with configurable retention |
| Data residency | No AI traffic or logs leaving controlled infrastructure | Self-hosted deployment in VPC, on-prem, or air-gapped environments |
These map cleanly onto the govern, map, measure, and manage functions of the NIST AI Risk Management Framework, which is why the framework has become the common vocabulary between security teams and AI platform teams. A more detailed control-mapping exercise is in this AI governance framework for CISOs, and the broader picture of risks, governance, and security for enterprise shadow AI sets the context these controls operate in.
The AI Gateway as the Control Plane
An AI gateway is a single entry point that routes, authenticates, budgets, and inspects traffic to every model provider an organization uses. The Bifrost AI gateway unifies 25+ providers and 10,000+ models behind one OpenAI-compatible API, and adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks. Policy lives here, and every other enforcement surface inherits it.
Four mechanisms carry most of the governance weight:
- Virtual keys are the primary governance entity. Each one carries model and provider allow-lists, an independent budget, token and request rate limits, and an optional expiry.
- Budgets and rate limits are hierarchical. A customer budget contains team budgets, which contain virtual key budgets, which contain per-provider budgets, and every level is checked on the same request.
- Role-based access control ships with Admin, Developer, and Viewer system roles and supports custom roles, so the people who read logs are not automatically the people who can change routing.
- Data access control scopes which users and teams can see which logs and resources, which matters once request content is retained for review.
Because Bifrost is self-hosted, none of this depends on a third party holding your prompts. That is what makes the gateway usable as a system of record rather than another SaaS dependency, and why one deployment can serve regulated workloads and general employee usage.
Bifrost Edge: Extending Governance to Every Machine
Bifrost Edge is the endpoint layer of the same Bifrost platform. It runs on each computer in the organization and routes AI traffic from desktop apps, browser AI, coding agents, and their MCP servers through your Bifrost, so the policies already configured at the gateway apply to the tools people open by hand. Edge is currently in alpha.
The design goal is that nothing about the policy model changes. The virtual keys, budgets, guardrails, and audit configuration that govern application traffic are exactly what Bifrost Edge enforces on the laptop. What changes is reach.
| Governance concern | Gateway alone | Gateway plus Bifrost Edge |
|---|---|---|
| First-party application traffic | Governed | Governed |
| Desktop chat apps and browser AI | Not visible | Routed and governed |
| Coding agents in terminal and IDE | Governed only if configured | Governed by default |
| MCP servers configured by users | Not visible | Inventoried and allow-listed |
| Per-app setup burden | Base URL change per app | None |
Setup is a single browser sign-in through existing SSO, which links the machine to the user and syncs that user's policies. How Edge works in daily use amounts to a menu bar or system tray agent showing connection status, the active virtual key, and remaining budget. No API keys are copied onto the device.
Administrators then decide which AI applications are permitted, and app governance enforces that decision on each machine, blocking disallowed apps before data leaves it. Newly detected apps raise an approval request automatically, and pending-state behavior is configurable. Moving enforcement to where people work is examined in endpoint AI governance.
How AI Guardrails Apply to Endpoint Traffic
AI guardrails are content checks applied to a prompt before it reaches a model and to the response before it returns. Because Edge routes endpoint traffic through Bifrost, guardrail profiles configured once at the gateway cover ChatGPT in a browser, Claude Desktop, and a coding agent in a terminal without any endpoint-specific setup.
Guardrails are built from reusable profiles and rules. Three providers run natively inside Bifrost: Prompt Guardrails, Custom Regex, and Secrets Detection. Ten external providers can be attached as profiles, including AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, Presidio, and Patronus AI.
Two native checks do most of the work against accidental disclosure. Secrets detection is Gitleaks-backed and catches API keys, tokens, private keys, and credentials pasted into a prompt. Custom regex runs in-process and ships with a PII detection template that organizations extend with their own patterns. Both can redact rather than block, which keeps a legitimate request useful after the sensitive fragment is removed.
Governing MCP Servers Across the Fleet
MCP servers are the least governed part of most AI estates. They read files, call internal APIs, and take actions on a user's behalf, and they are typically added by individual engineers inside a client application where no security team sees them. That is shadow AI with write access, examined further in shadow MCP and the ungoverned tools risking your data.
MCP governance in Edge starts with discovery. Edge reads the MCP configuration of supported AI apps on each machine and builds a fleet-wide inventory of which servers are configured, where, and on how many devices. Discovery covers Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor today.
Decisions are then made per server and enforced on the device rather than advised. A denied server cannot be used even by an app that had it configured beforehand. Teams that also need centralized tool routing for agent workloads can use the MCP gateway capabilities in Bifrost for the server-side half of the problem.
Rolling Out AI Governance Without a Helpdesk Queue
Endpoint controls fail when they depend on users installing something. Deploying Edge with MDM avoids that: the agent is pushed silently through Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, or JumpCloud with a managed configuration that points each machine at your Bifrost.
The managed configuration carries only non-sensitive connection settings, so no secrets sit on the device and identity comes from the user's sign-in. First launch is one setup approval and one SSO sign-in, after which policy and configuration stay in sync automatically. From there the devices dashboard gives the fleet view security reviews ask for: every machine running the agent, its owner, platform and agent version, installed AI apps, and configured MCP servers, filterable by approval status. A step-by-step rollout sequence is described in rolling out AI governance with MDM.
Audit Evidence and AI Compliance Reviews
AI compliance work is mostly evidence production, and two distinct record types are needed. Bifrost keeps them separate, which matters when an auditor asks a precise question.
Audit logs record administrative activity: who changed which resource, when, and with what outcome. Entries can be signed with an HMAC key, retained for a configurable period, filtered by action and date, exported as JSON, JSON Lines, or Syslog, and archived to S3 or GCS. Request-level telemetry is separate, handled by observability with native Prometheus metrics and OpenTelemetry export.
For regulated environments, the deployment model carries as much weight as the logs. Bifrost Enterprise supports in-VPC deployment with no public network egress, alongside on-prem and air-gapped installations, so prompts, responses, and audit records stay inside infrastructure the organization already controls.
Frequently Asked Questions
Is ChatGPT shadow AI?
ChatGPT is shadow AI when an employee uses a personal account for company work without security review or logging. The same product is sanctioned AI when access runs through corporate identity and a governed path. The distinction is not the tool but whether the organization has visibility, access control, and an audit trail over its use.
What are the risks of shadow AI?
The primary risks are data exposure to third-party model providers, loss of audit coverage, uncontrolled spend on personal or team cards, and unvetted MCP tools taking actions on internal systems. IBM's 2025 breach research found shadow AI incidents disproportionately exposed customer PII and intellectual property, which is what pushes the cost per incident higher.
Can you give me an example of shadow AI?
An engineer installs a coding agent, points it at a personal API key, and connects an MCP server that reads the production repository. No procurement ticket exists, no budget applies, and no log records what left the machine. A marketing analyst pasting a customer list into a browser assistant is the same pattern with different data.
How is shadow AI different from shadow IT?
Shadow IT describes unapproved software and services generally; shadow AI is the subset where the unapproved tool sends company data to a model provider and may act on it. The difference that matters operationally is egress: it moves content, not just files, and the content often includes the material a security program exists to protect.
What are the four pillars of AI governance?
Most frameworks converge on transparency, accountability, fairness, and security, with the NIST AI Risk Management Framework organizing them as govern, map, measure, and manage. Translating those pillars into running controls means an inventory of AI usage, identity-bound access, preventive checks on content, and retained evidence of both policy and activity.
Does blocking AI tools stop shadow AI?
Blocking reduces the most obvious usage and moves the rest to personal devices and unmanaged networks, where there is no telemetry at all. Providing a governed path works better: allow the tools people need, route that traffic through a control plane applying budgets and guardrails, and deny only what fails review. That sequence is traced in closing the last mile of AI governance.
Getting Started With End-to-End AI Governance
Shadow AI is an enforcement gap rather than a policy gap, and it closes when the same control plane governs both application traffic and the AI running on employee machines. Bifrost provides that control plane as self-hosted open-source software, and Bifrost Edge extends it to the endpoint while the policy model stays unchanged. The AI governance capabilities are a useful starting point for scoping an internal review.
To see how end-to-end AI governance would work against your fleet and your compliance obligations, book a demo with the Bifrost team.
