How to govern Claude Desktop across your company
A developer installs Claude Desktop, signs in with a personal account, and wires in a few MCP servers: one for the filesystem, one for an internal database, one for the issue tracker. Within an hour the app can read local files, query production data, and act on a user's behalf. Every prompt and every file it touches leaves the machine and goes to a model endpoint over an encrypted connection. None of it appears in a log your security team can read.
This is the gap most organizations have right now, and it is not small. UpGuard's 2025 shadow AI research found that 81% of employees and 88% of security leaders use unapproved AI tools at work. Claude Desktop is one of the tools they reach for, and to govern Claude Desktop you have to reach the place it actually runs: the endpoint.
Why Claude Desktop is hard to govern
Claude Desktop is a local application. It does not route through a corporate proxy by default, it does not expose an admin API for prompt inspection, and it connects directly to the model provider. That combination defeats most of the controls a security team already owns.
The specific problems:
- Prompts leave with no record. Whatever a user pastes into Claude Desktop, including customer data, source code, or contract terms, goes straight to the model with no audit trail.
- MCP servers inherit real access. A server configured inside Claude Desktop can read files, call internal APIs, and take actions, yet most teams have no inventory of which servers are wired in or on which machines.
- The connection is encrypted and direct. Traffic goes from the app to the model API over TLS, so a network appliance sees an opaque session, not the prompt inside it.
- Personal accounts sidestep the enterprise tenant. A user signed in with a personal plan is outside whatever data controls your organization negotiated.
Why network controls and policies miss it
The instinct is to handle this at the network layer or with a written policy. Both leave holes.
Network DLP and secure web gateways only inspect what crosses the network in a form they can read. Claude Desktop's traffic is encrypted and pointed at a legitimate model endpoint, so a proxy sees a normal TLS session and cannot examine the prompt without breaking the connection. Blocklists are all or nothing: block the domain and you break a tool people rely on, allow it and you are back to zero visibility. New apps and new MCP servers appear faster than a blocklist can track them.
Written policy fails for a simpler reason: it does not enforce anything. UpGuard's research found 45% of workers find a workaround when an application is blocked, which means restriction without enforcement mostly costs you the visibility you had. The AI runs on the endpoint, so the endpoint is where it has to be governed.
How Bifrost Edge governs Claude Desktop
Bifrost Edge is the endpoint layer of Bifrost, the open-source AI gateway from Maxim AI. It runs on each computer in the organization and routes AI traffic from the apps people use, including Claude Desktop, through your Bifrost gateway. The governance you already run at the gateway, meaning virtual keys, budgets, guardrails, and audit logs, then applies to Claude Desktop on the laptop instead of only to traffic that was configured to point at the gateway.
Setup is one step for the user. On first run, the person signs in through the browser with your existing SSO, which links the machine to the user and syncs the policies assigned to them. After that, Edge runs as a menu-bar agent on macOS or a system-tray agent on Windows and Linux. There are no base URLs to change inside Claude Desktop and no keys to paste.
A Claude Desktop request then flows like this:
- The user sends a prompt in Claude Desktop as usual.
- Edge routes that request through your Bifrost gateway instead of straight to the provider.
- Bifrost ties the request to the user's virtual key, runs the configured guardrails on the prompt, and writes the exchange to audit logs.
- The governed response returns to Claude Desktop, and the user sees a normal reply.
Nothing about the experience changes for the person using the app. What changes is that the prompt, the response, and the tools behind them are now visible and under policy. The mechanics below are where that control actually lives.
Decide whether Claude Desktop is allowed
The first decision is whether Claude Desktop belongs on a given machine at all. With app governance, admins set AI app policy centrally in Bifrost and Edge enforces it on each device. Approved apps run normally with their traffic governed in the background. Disallowed apps are blocked before any data leaves the machine.
When Edge sees an app it has not encountered, it raises a pending approval in the admin console, and you decide whether pending apps are allowed or blocked while they wait. Allow Claude Desktop once and the decision applies across the organization without anyone revisiting individual laptops. When an app is blocked, the user gets a clear signal that it is not permitted on a company machine, so there is no confusion about why it is unavailable.
See and control the MCP servers inside Claude Desktop
Allowing the app is not the same as trusting everything wired into it. The higher risk usually sits in the MCP servers a user has connected, because those servers can reach files and internal systems.
Edge reads the MCP configuration inside Claude Desktop and builds a live inventory across the fleet through MCP governance: which servers are configured, on which machines, and how many times. For the first time, you can answer "what MCP servers are running inside Claude Desktop on our machines?" with real data instead of a guess. Admins then allow or deny each server individually, and the decision is enforced on the device, even for a server that was configured before the policy existed. New servers move through the same pending, approved, denied workflow, and because the catalog is deduplicated, the same server on a hundred machines is approved or denied once.
Apply PII and secrets guardrails to Claude Desktop prompts
Visibility and allow lists do not catch what a user types. That is the job of guardrails, and the profiles you already configure in Bifrost apply to Claude Desktop traffic automatically, with no extra setup on the endpoint.
The timing is the point. A guardrail runs before the prompt reaches the model and again before the response returns, so sensitive content is caught or redacted before it leaves the machine. Built-in checks include Gitleaks-backed secrets detection for leaked API keys and credentials, a PII detection template built on custom regex, and content safety. For broader coverage, Bifrost composes external providers such as AWS Bedrock Guardrails, Azure Content Safety, and others into the same pipeline. Configure the policy once at the gateway and it covers Claude Desktop along with every other supported app.
Roll it out without touching laptops
None of this requires asking employees to install anything. Edge deploys silently through standard device management, including Jamf, Intune, and Kandji, using a managed configuration. You push it the same way you push other managed software, and it reaches every machine that should have it. Claude Desktop sits among the supported applications Edge governs today, alongside the ChatGPT app, Cursor, and coding agents in the terminal.
Where this lands
Governing Claude Desktop is not about blocking a useful tool. It is about letting people keep the app while your security team gets what it has been missing: an inventory of the MCP servers connected to it, enforcement of which apps and servers are allowed, guardrails that catch sensitive data before it leaves the laptop, and an audit record of what actually happened. The policy is the same one you already run at the gateway, so there is no second rule set to maintain for the endpoint.
If you are sizing up the problem, the Bifrost Edge overview lays out the full picture of how endpoint governance works, and Edge is currently in alpha for teams that want to bring AI on every machine under governance.
