Bifrost Edge brings AI gateway governance to every company laptop

Bifrost Edge, Maxim AI’s endpoint agent for the open-source Bifrost AI gateway, gained a set of server-side controls in Bifrost Enterprise v2.3.0, released October 13, 2026. Edge runs on each company computer and sends the AI traffic it finds there, from desktop chat apps, browser chat, terminal coding agents and the Model Context Protocol (MCP) servers those tools launch, through the organization’s own gateway. The new release lets administrators switch capture off for a single app, fleet-wide or for one user or team, shows which Edge version each device runs, and adds a stateless MCP inspection endpoint for clustered gateways. A follow-up, v2.3.1 on October 19, added Antigravity CLI and Antigravity Desktop to the apps Edge can control. Edge is listed as early access.

TL;DR

• Bifrost Edge is an endpoint agent for macOS, Windows and Linux that routes AI traffic from desktop apps, browser AI, coding agents and MCP servers through an organization’s gateway, where existing keys, budgets, guardrails and logs apply.
• Enterprise v2.3.0 (October 13) added per-app capture control through PUT /edge/interception, the Edge version on the Devices view, and /mcp/inspect/v2 for MCP inspection without session affinity. v2.3.1 (October 19) added Antigravity.
• Edge inventories AI apps and MCP servers on each machine, queues new ones for approval, and enforces deny decisions on the device at the next check-in.
• Rollout runs through MDM tools such as Jamf, Intune and Kandji: a managed config.json holding only the gateway URL, a trusted organization certificate, and one SSO sign-in per user.
• Edge is offered at no cost to existing enterprise customers during early access; per-device pricing has not been published.

Bifrost Edge at a glance

What changed in v2.3.0 and v2.3.1

The Edge entry in the v2.3.0 enterprise changelog is titled “Edge Server Support” and has four parts.

Per-app capture control. “Admins can turn off Edge capture for one app, fleet-wide or per user or team,” the changelog says, through PUT /edge/interception with an app_key. Capture means interception: Edge pulling an app’s requests into the gateway. Edge Settings already held a global interception state that user or team decisions can override; the app_key adds a per-app dimension. An operator can now stop capturing one coding agent for one team while every other app stays under capture. The troubleshooting guide sets precedence: “User-scoped decisions override team and global decisions.”

Version reporting. “Edge Devices shows the installed Edge version.” The Devices dashboard already listed hostname, owner, platform, installed AI apps, configured MCP servers, and first-seen and last-active times. The version column shows which machines lag a release.

Stateless MCP inspection. “New /mcp/inspect/v2 lets MCP post-inspection run on any node, with no session affinity.” When v2.2.0 introduced endpoint MCP inspection on September 16, its changelog noted that inspection sessions were node-local, so “clustered deployments require session affinity.” Session affinity, or sticky sessions, pins a client to one server behind a load balancer. The v2 endpoint lifts that requirement for the post-execution half of the exchange, which matters for anyone running the gateway as a scaled-out cluster.

Cursor model settings. Cursor configuration now “accepts per-operation models,” including linter_model, embedding_model, speech_model, image_model, video_model and transcription_model, so each kind of Cursor request can be pinned to an approved model.

Six days later, v2.3.1 added “Antigravity in Edge App Controls”: both Antigravity apps “can be configured in Edge app interception settings, with their own domains and inspection rules.” The release also logs their requests as distinct apps “including when they arrive through Edge,” and stores an approved native tool call and its result in one log row. The v2.3.2 changelog, dated October 20, lists no Edge entries.

The September groundwork

The October changes build on v2.2.0, which added the two-phase MCP inspection described below, approval gates on MCP connections, native tool call reporting for shell commands and file reads from coding apps, Gemini CLI as a governed app, and three fleet provider login toggles. Three days later, v2.2.1 began recording an MCP call that cannot be tied to a known installation “as an observation with status=unknown” rather than denying it, while true policy denials stay strict.

Why the gateway alone misses endpoint AI

An AI gateway is a proxy between applications and model providers. It holds provider keys, enforces budgets and rate limits, applies content guardrails, and logs requests. It governs the traffic configured to reach it. Software a platform team owns can be pointed at the gateway with a base URL change. Software employees install themselves usually is not.

That is where shadow AI, the use of AI tools the organization has not approved or cannot see, lives. Microsoft and LinkedIn’s 2024 Work Trend Index found that “78% of AI users are bringing their own AI tools to work.” IBM’s 2025 Cost of a Data Breach release said “one in five organizations reported a breach due to shadow AI,” and that high levels of shadow AI added an average of $670,000 to breach costs.

The Frontier Wire’s shadow AI explainer covers that data and the risk categories. Its shadow AI monitoring guide covers detection signals and inventory.

What has changed is where the usage happens. Shadow AI is often pictured as a browser tab, which network tools can see. Much of it now runs as installed software: Claude Desktop, the ChatGPT and Codex desktop apps, Cursor, and terminal agents such as Claude Code, Codex CLI, Gemini CLI and OpenCode. Each can reach a model provider directly, with its own credentials.

MCP servers on the laptop

MCP widens the gap. The current specification defines its stdio transport as “newline-delimited messages over the standard streams of a client-launched subprocess.” The AI app starts the MCP server as a local program and talks to it through its input and output. That exchange never touches the network, so nothing upstream sees it.

The MCP project’s guide to local servers states the consequence: “The server runs with your user account permissions, so it can perform any file operations you can perform manually.” The configuration sits in a per-user file, such as claude_desktop_config.json. Knowing which MCP servers employees run means reading those files on every machine. The Claude Code security guide covers vendor-side controls for one client.

The Edge product page describes the gap this way:

The gateway governs the AI you send it. Edge brings in the rest, the tools running on laptops, so all of it lives under one platform with one set of rules.

How Edge routes traffic

Edge installs as a privileged background service plus a menu-bar (macOS) or system-tray (Windows, Linux) agent. Per How Edge works, the user signs in once through the browser with the organization’s single sign-on, which links the machine to the user and syncs their policies. “No API keys are copied or pasted, and nothing sensitive lives in the app itself,” the page says.

Capture depends on a trusted certificate. The Configurations page says Edge “routes encrypted AI traffic through your Bifrost, which requires a trusted organization certificate on each machine.” Administrators generate a certificate authority (CA) in the dashboard or upload one. A CA is a root certificate a computer trusts to vouch for others; once it is trusted, Edge can terminate the TLS connection to an AI domain, apply policy and forward the request. Until then, “Edge passes traffic through without inspecting it.”

Scope is narrow by design. The verification guide says: “Only configured and supported AI domains are intercepted. Unrelated device traffic is not routed through Edge.”

On the gateway side, each Edge user is tied to a governed virtual key, a gateway-issued credential carrying allowed providers, models, budgets and rate limits. Prepare identity and access describes the usual path: an access profile attached to the user’s role, from which the gateway “creates a per-user copy of the profile and issues the user a governed virtual key.” Every request from that laptop is attributed to that person.

Guardrails without endpoint configuration

Because requests land at the gateway, its content rules apply to Edge traffic. The security page says existing guardrail profiles “cover Edge traffic with no additional configuration.” Listed options include Gitleaks-backed secrets detection, custom regex with a PII template, AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor and CrowdStrike AIDR, among others. The docs show the rules applied to a ChatGPT web prompt and to Claude Cowork.

App and MCP governance on the device

Routing gives visibility and content control. The second half of Edge is inventory and enforcement. Edge collects the AI apps and MCP servers configured on each machine into two fleet-wide catalogs, and the Approvals dashboard gives each entry one of three statuses:

Catalogs are deduplicated, so an MCP server configured on hundreds of laptops appears once and one decision covers all of them. The MCP catalog shows whether each server is a “local command or remote URL” and the tools it exposes. Decisions reach devices at the next check-in; the agent poll interval defaults to 60 seconds with a 5-second minimum, per the first-rollout settings.

The MCP governance page says a deny is enforced on the machine “so the disallowed tool cannot be used, even by an app that had it configured before the policy existed.” Per the v2.2.0 changelog, starting a local MCP process or opening a remote connection “now requires explicit Edge approval,” and “pending, denied or unknown targets stop startup before OAuth or tool discovery.” A server under review cannot open an OAuth window or advertise tools before anyone has looked at it, unless the fleet setting admits pending items.

Two-phase MCP inspection

For approved servers, tool calls pass through the gateway in “a two-phase HTTP exchange that mirrors LLM inspection.” Before a tool runs, Edge submits its arguments and receives approved parameters and an opaque session ID. Afterwards it submits the result or error for post-processing “before releasing it to the client.” Both phases verify identity and installation ownership, and “policy or transport failures fail closed”: a failure blocks the call. /mcp/inspect/v2 is the stateless version of the second phase.

The same release extended guardrails to “inspect and redact tool call names and arguments across every provider,” so that “a model can no longer smuggle secrets or destructive commands past a policy inside a tool invocation.”

Supported applications

The supported applications page and the changelogs list this coverage:

The provider list comes from the gateway, which serves 25+ providers and 10,000+ models through one OpenAI-compatible API.

The v2.2.0 login toggles change how coding apps authenticate without changing where traffic goes. “Require Anthropic login” and “Require ChatGPT login” let Claude Code and Codex users sign in with their own accounts “while gateway routing and the governed model picker stay in place.” “Enable login-free Claude Desktop” provisions Claude Desktop through OS-level managed policy “so it runs through Edge without an Anthropic account.” The comparison of AI gateways for Claude Code, Codex and Cursor covers the per-client setup that Edge replaces on managed machines.

Rollout through MDM

The Deploy with MDM overview names Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE and JumpCloud. The MDM installation guide lists three payloads:

1. The package per platform: .pkg for macOS, .msi or .intunewin for Windows, .deb or .rpm for Linux.
2. A managed config.json with one key, base_url, the gateway’s HTTPS address, at /Library/Application Support/Bifrost Edge/config.json (macOS), %ProgramData%\BifrostEdge\config.json (Windows) or /etc/bifrost-edge/config.json (Linux). The agent watches the file, so a corrected URL needs no reinstall.
3. On macOS, the organization’s Edge CA as a device-scoped trusted root.

The configuration “carries only non-sensitive connection settings,” the overview says; identity and keys arrive with sign-in.

How certificate trust is delivered

On macOS, Edge needs a payload of type com.apple.security.root. Apple’s CertificateRoot reference calls it “the payload that configures a root certificate” and documents device and user channels. Edge’s guide requires the device channel and warns that a user-scoped profile or a generic PKCS#1 or PEM payload does “not establish the machine-wide root trust the agent checks.” Kandji handles this through its Certificate Library Item, which it says lets administrators “upload certificates and certificate identities and deploy them to your Apple devices.”

On Windows and Linux, the elevated Edge service installs the CA into the system trust store itself, so no certificate profile is needed. In the usual Intune pattern, administrators deploy a trusted certificate profile for that step. The .intunewin package is the format Intune’s Win32 app tooling uses.

Two operational details stand out. Every computer must restart after it first trusts the CA, and again whenever the CA is replaced; the docs say the restart is “required for the CA certificate change to take effect.” And an optional managed preference, DisableLocalUninstall in the ai.getbifrost.edge domain, removes the local uninstall command if set before installation.

A device counts as ready only when Diagnostics reports Healthy across seven checks (service, account, configuration, certificate, traffic capture, gateway and MCP) and a test request appears in gateway logs “attributed to the signed-in user and their governed virtual key.”

How other approaches cover the same ground

Several product categories already address shadow AI, each from a different vantage point.

Network and SSE controls. Security service edge (SSE) platforms route employee traffic through a cloud proxy, and their cloud access security broker (CASB) features classify the SaaS apps users reach. Microsoft’s shadow AI discovery in Entra Global Secure Access is “a network-based feature” that identifies traffic to services such as ChatGPT, Claude and “SaaS MCP servers,” then scores each app against the Defender for Cloud Apps catalog. Cloudflare’s AI security report uses its Gateway’s HTTP and DNS inspection to show top AI apps, data uploaded to them, and logins to MCP servers behind Cloudflare Access. These tools see remote endpoints. A local stdio MCP server produces no network traffic for them to see.

Endpoint DLP. Data loss prevention agents watch files, clipboards and uploads on the device and block sensitive content by pattern. They work locally but sit apart from the provider keys, model allow-lists and per-user budgets a gateway manages.

Vendor-native policy. Some clients ship their own admin controls. Claude Code supports managed MCP settings with allowedMcpServers and deniedMcpServers lists an MDM can push. These are precise for one client and must be repeated per client.

The Edge FAQ frames the product as additive: it “runs alongside” tools such as CrowdStrike, Zscaler and Tailscale and “focuses only on AI traffic going to AI tools.” In practice Edge pairs with an SSE or DLP stack.

Access, pricing and status

The product page labels Edge “Early Access” and says it is “available to enterprise customers of the Bifrost gateway.” Enterprise tier. The setup prerequisites call for a Bifrost Enterprise deployment with an Edge entitlement and a free device seat, plus an identity provider: Okta, Microsoft Entra ID, Keycloak, Zitadel, Google Workspace, Auth0 or generic OIDC. The v2.3.0 changelog notes that CLI sessions “do not use Edge device seats.”

On price, the page says “Pricing is based on the number of devices Edge runs on,” that Edge is offered “at no cost to our existing enterprise customers” during early access, and that “Full pricing will be released soon.” Packages come from an organization-specific download location shared during onboarding, per the direct installation guide. The gateway itself is open source under Apache 2.0 on GitHub.

Open questions

Final pricing. For fleets of thousands of machines, the per-device number will shape whether Edge goes on every laptop or only on engineering machines.

Coverage pace. The supported list grew by Gemini CLI in September and Antigravity in October. Since interception is defined per app and per domain, the pace of additions sets how much of a fleet’s AI use is captured.

Employee privacy. Capture is limited to configured AI domains, and the product page says other traffic “is never inspected.” Prompt-level logging still raises works-council and data protection questions in some jurisdictions, as the monitoring guide discusses. The new per-app, per-team capture switch gives administrators a way to match those agreements.

Certificate rotation. Replacing the CA means a restart on every machine and, on macOS, a new MDM profile. A rotation plan belongs in the first rollout.

What the release means

An AI gateway governs what is pointed at it, and Edge is how the gateway reaches the rest. The October releases move the product from basic interception toward the fine-grained controls operators need once an agent is on real fleets: per-app and per-team capture switches, version reporting and a stateless inspection path. None is a headline feature. Each is the kind of detail a security team checks before installing an agent on every laptop. The larger shift is architectural. Shadow AI used to mean a list of websites. With desktop agents launching local MCP servers that hold a user’s full file permissions, it has become a question of what runs on the machine and under whose policy. Edge keeps that policy in one place, the gateway, and has the device report to it. Whether the model holds will depend on coverage keeping pace with the agents employees install next, and on the per-seat price once early access ends.