Google’s Chrome Enterprise MCP server is an open-source connector that lets an MCP-compatible AI client, such as Gemini CLI, read and change Chrome Enterprise Premium settings through Google’s management APIs. Google announced it on 28 May 2026 for investigating browser configurations, reviewing security events and drafting data-loss prevention (DLP) rules. It is published as the npm package @google/chrome-enterprise-premium-mcp, and the current release is 1.10.0, dated 24 July 2026 in the project’s changelog.

The short answer to “what can it change?” is: more than the launch post suggests. The agent can create live warning and audit rules, switch on connectors and force-install Google’s own extensions. Live rules that block content are the exception: the server will only create those switched off, and an administrator has to turn them on in the Admin Console.

Last checked 9 November 2026 against the project’s README, changelog and source code on GitHub and the npm listing.

What the agent can and cannot do on its own

The project README describes the server as “an administrator-level interface to Chrome Enterprise Premium” and lists its tools by group. The guardrails below come from the tool definitions and the safety constants in the project’s source, as published on 9 November 2026.

Task What the server does Built-in limit
Health check (/cep:health) Reads org units, licences, connectors, browser versions and Security Insights status Read-only
Read activity logs and DLP rules Matches recent Chrome events to the rule that fired Read-only
Create a DLP rule that warns or only logs (audit) Creates it, active by default, on the org unit you name Rule name gets a 🤖 prefix
Create a DLP rule that blocks Creates it only in the inactive state An admin must enable it in the Admin Console
Delete a DLP rule Deletes rules the agent itself created Refuses rules without the 🤖 prefix
Turn on Chrome Enterprise connectors Changes the connector policy for an org unit None beyond your admin role
Install the Secure Enterprise Browser or Endpoint Verification extension Force-installs it on an org unit’s managed browsers None beyond your admin role
Context-Aware Access levels, Secure Gateway (added in 1.10.0) Lists and creates access levels; updates Secure Gateway settings None beyond your admin role

So the launch post’s advice that administrators “must manually review and enable rules in the Admin Console” is a practice Google asks for, and the code enforces it only for active blocking rules. A warning rule applied to a whole organisation can go live straight from a chat prompt. Google’s own launch example has the agent turning on the reporting connector for the whole org in response to a one-line request.

A safer first set-up

The server reads a set of EXPERIMENT_ environment variables at start-up. One of them, EXPERIMENT_READ_ONLY, marks every tool that changes settings as disabled and returns an error if the agent tries to call it, according to the tool registry in the project’s source. For a first trial, the client configuration from the README becomes:

{
  "mcpServers": {
    "cep": {
      "command": "npx",
      "args": ["-y", "@google/chrome-enterprise-premium-mcp@latest"],
      "env": { "GCP_STDIO": "true", "EXPERIMENT_READ_ONLY": "true" }
    }
  }
}

With that flag set, a team can run the health check and investigate a noisy warning without any risk of the agent changing policy. Removing the flag later is a deliberate step, which is the point.

The README adds three warnings worth reading before that step. Hidden instructions planted in a document, email or web page that the agent reads can hijack it into calling these tools without the user’s consent (indirect prompt injection). Tools named create_*, update_* and enable_* have tenant-wide effect. And experiments should use a dedicated, least-privilege admin account.

What you need to run it

Requirement Detail (as of 9 November 2026)
Licence Chrome Enterprise Premium; most tools return permission errors without it. The project FAQ mentions a 60-day trial
Admin role Super Admin for DLP features and full diagnostics; a delegated role with Chrome Management rights for the other tools
Node.js 20.0.0 or higher, per the README (the May launch post said 18+)
Client Gemini CLI (one-command extension install), or any MCP client such as Claude Desktop, Cursor, Windsurf or VS Code
Sign-in auth login with a bundled Google-managed OAuth client; a Super Admin may need to trust it first if third-party app access is restricted
Hosted use HTTP mode with per-request bearer tokens, or a service account with domain-wide delegation

Chrome Enterprise Core, the free management tier, covers browser policies but not DLP, threat protection or Context-Aware Access, so most of what the server does needs the paid Premium licence, according to the project FAQ.

For hosted deployments the FAQ prefers per-user OAuth to domain-wide delegation, because delegation lets the server impersonate every user in the domain. It also warns that HTTP mode has no network-level authentication by default unless CEP_BEARER_AUDIENCE is set.

A reference implementation has support boundaries

Google describes the project as a reference implementation that is “not an officially supported Google product”, released under the Apache 2.0 licence. That shapes adoption. A team that runs it is operating code it has to review and update itself, with an account that can change security policy for the whole organisation.

The release pace is also worth noting. Versions 1.6.0 to 1.9.0 shipped between 18 May and 8 June, and 1.10.0 followed in late July, adding Secure Gateway and Context-Aware Access tools. The client configuration in the README uses @latest, so every restart can pick up new tools. Pinning a version number in place of @latest keeps the tool set fixed until someone has read the changelog.

The useful first trial is still a narrow investigation with a known answer, such as finding out why one group receives a repeated warning, run in read-only mode. The administrator can compare the agent’s reasoning with the logs and the rule before giving it any role that changes policy.

This follows the pattern in our report on Razorpay’s payment CLI and in Microsoft’s Zero Trust guidance for AI agents: easier tool access cuts repetitive work, and makes the line between inspecting and changing live settings more important.

Questions

What is the Chrome Enterprise MCP server?

An open-source Model Context Protocol server from Google that exposes Chrome Enterprise Premium management, including DLP rules, content detectors, connectors, browser telemetry and licence checks, as tools an AI client can call. Google announced it on 28 May 2026.

Is it an officially supported Google product?

No. Google calls it a reference implementation that is not an officially supported product, licensed under Apache 2.0.

Can the agent turn on DLP rules without review?

Partly. It can create active rules that warn or only log events. It cannot create an active rule that blocks: those are created inactive and must be enabled in the Admin Console. Google still asks administrators to review every rule the agent proposes.

Can it be run in read-only mode?

Yes. Starting the server with EXPERIMENT_READ_ONLY=true disables every tool that changes settings, according to the project’s source code.

Which licence and admin role are needed?

Chrome Enterprise Premium for DLP and most other tools, and a Super Admin account for DLP features and full diagnostics. Other tools work with a delegated Chrome Management role.

What is the latest version?

Version 1.10.0, dated 24 July 2026 in the changelog and published on npm on 28 July 2026. No newer release was listed when we checked on 9 November 2026.

Sources