Chrome's silent 4 GB AI model: lockdown for regulated teams

A 4 GB AI model arrived without a consent prompt

A 4 GB Gemini Nano model started appearing on Windows machines running Google Chrome with no consent dialog and no opt-in. The component name in the user profile directory is OptGuideOnDeviceModel. The single largest file inside it is weights.bin, sitting in the 3.5 to 4.0 GB range. If a user deletes it, Chrome quietly re-downloads it on the next launch. There is no toggle in chrome://settings. The only durable way to stop it is an enterprise policy.

For most consumers this is a privacy and disk-space nuisance. For a regulated engineering team, it is an audit finding waiting to happen. The May 2026 release of the DISA STIG for Chrome on Windows lists GenAILocalFoundationalModelSettings as an explicit medium-severity finding, V-275782, when the policy is missing or set to allowed. SOC 2 and HIPAA programs that gate every other vendor sub-processor will need an answer for this one too.

Here is what is actually shipping to your endpoints, why it matters for compliance, and the exact policy levers to set this week.

What is actually on the disk

Chrome 138, generally available for extensions and behind a flag for web pages, exposes a family of "Built-in AI" Web APIs. The headline ones today are:

• The Prompt API (LanguageModel.create() plus session.prompt())
• The Summarizer API
• The Writer and Rewriter APIs
• The Translator and Language Detector APIs

All five are backed by the same on-device foundation model: Gemini Nano. The first time a page or extension calls one of these APIs, Chrome's component updater pulls the model files into the user profile directory under OptGuideOnDeviceModel. On current Chrome builds the download can also be triggered without an explicit API call, on browser update.

A minimal page-side call site is small:

// Chrome 138+, page or extension context
const availability = await LanguageModel.availability({
  expectedInputs: [{ type: 'text', languages: ['en'] }],
  expectedOutputs: [{ type: 'text', languages: ['en'] }],
});

if (availability !== 'available') {
  // 'downloadable' or 'downloading' triggers the multi-GB pull on first use
  return;
}

const session = await LanguageModel.create();
const summary = await session.prompt(
  'Summarize this incident report: ' + reportText,
);

The shape of that API is the core control problem. Any tab the user has open can route arbitrary text into a local model with no network request to a remote service, no API key, no per-token billing, and no audit trail visible to the corporate egress proxy.

Why this is a regulated-team problem

Consumer commentary has focused on bandwidth and disk cost. The compliance issues are different.

DLP and egress controls do not see it. A SOC 2 Type II program with mature data-loss-prevention is wired around network egress: an inline secure web gateway, a CASB on top of sanctioned SaaS, allowlists at the corporate proxy. Local inference happens entirely inside the browser process. A user who pastes patient notes, source code, customer PII, or board materials into a tab that calls the Prompt API generates zero outbound traffic for that step. The DLP record of the event is a void.

HIPAA business-associate analysis gets messy. If a covered entity's workforce uses a browser API that processes PHI locally and the model code itself was distributed by Google as part of Chrome, the BAA scope and the chain-of-custody picture both shift. The conservative read in most healthcare security programs is that on-device models with no scoped data agreement represent the same risk surface as an unsanctioned cloud LLM, and they are treated the same way: blocked until reviewed.

EU AI Act provider and deployer roles are ambiguous. A web page that routes user input to a built-in browser model is plausibly a "deployer" of a general-purpose AI system in the EU AI Act sense. That triggers logging, transparency, and human-oversight obligations the page author may not know they have inherited. Internal apps that quietly start using the Prompt API to "summarize this ticket" can land their employer on the wrong side of the August 2026 GPAI obligations without anyone signing off. (For the engineering checklist on those obligations, see our EU AI Act August 2026 guide.)

FedRAMP and DoD environments already require it disabled. STIG V-275782 flags any system where GenAILocalFoundationalModelSettings is missing or set to 0. That is not advisory. It is a medium-severity finding that fails the scan.

The same applies to Microsoft Edge. Microsoft ships an identically named policy, GenAILocalFoundationalModelSettings, supported on Edge 132+ on Windows and macOS, and 147+ on Android. iOS Edge does not include the local model today.

The lockdown

For Chrome on Windows, the fix is a single registry entry pushed via Group Policy or your MDM:

Path:  HKLM\SOFTWARE\Policies\Google\Chrome
Name:  GenAILocalFoundationalModelSettings
Type:  REG_DWORD
Value: 0x00000001    ; 0 = Allowed (default), 1 = Disabled

If you prefer the ADMX path: Computer Configuration > Administrative Templates > Google > Google Chrome > Generative AI > Settings for GenAI local foundational model > Do not download model. Pull the latest ADMX bundle from the Chrome Enterprise policy list so the template is current.

For Chrome on macOS via the managed-policy plist at /Library/Managed Preferences/com.google.Chrome.plist:

<key>GenAILocalFoundationalModelSettings</key>
<integer>1</integer>

For Chrome on Linux via /etc/opt/chrome/policies/managed/genai.json:

{
  "GenAILocalFoundationalModelSettings": 1
}

For Edge on Windows the path swaps Google\Chrome for Microsoft\Edge:

Path:  HKLM\SOFTWARE\Policies\Microsoft\Edge
Name:  GenAILocalFoundationalModelSettings
Type:  REG_DWORD
Value: 0x00000001

Two behaviors of the Edge implementation, which broadly hold for current Chrome builds as well:

1. The policy supports dynamic refresh. The change takes effect without a browser restart.
2. When you flip the policy to disabled on a machine that has already downloaded the model, the existing weights are deleted on the next refresh. You do not need to script the cleanup separately.

If you want a heavier instrument that also stops the next surprise local-AI shipment from any source, set ComponentUpdatesEnabled = false. That blocks the entire Chrome component-updater path, which is also how the model is delivered, at the cost of disabling other component updates such as the Widevine CDM and origin-trial revocation lists. Most regulated environments cannot afford that side effect, so the targeted policy is usually the right answer.

What to do this week

A short list any platform-engineering team can run through before Friday:

1. Inventory which managed browsers are deployed across the fleet: Chrome, Edge, Brave (which inherits Chromium and the same component infrastructure), Vivaldi, Opera.
2. Push GenAILocalFoundationalModelSettings = 1 for every applicable browser via your existing MDM (Intune, Jamf, Workspace ONE, GPO).
3. Verify the policy is taking effect by visiting chrome://policy and edge://policy on a sample of managed endpoints. The policy should appear with value 1 and source "Platform" or "Cloud".
4. Sweep the user profile directory for the OptGuideOnDeviceModel folder and confirm it is gone after the next browser restart. On Windows: %LOCALAPPDATA%\Google\Chrome\User Data\OptGuideOnDeviceModel.
5. Add a detection rule to your endpoint agent (Defender, CrowdStrike, SentinelOne, Wazuh) for any process writing to OptGuideOnDeviceModel. That is a useful canary if the policy is bypassed or if a user installs an unmanaged Chrome.
6. Update the SOC 2 or ISO 27001 control narrative for "AI vendor management" to explicitly cover browser-shipped on-device models. The auditor will ask in the next cycle if they have not already. (For the broader control mapping, see our SOC 2 compliance guide.)
7. Add an item to the AI governance committee agenda: sanction the Prompt API and its sibling browser APIs, or deny them globally, with a documented decision. Do not let the default ride.

The DISA STIG is a clean policy citation if you are explaining the change to a CISO who wants a reference outside your own writeup. If you publish an internal browser baseline, link to the Chrome Enterprise policy doc so the mapping stays current as Google adds new generative-AI policies.

The broader point

Built-in browser AI is the cleanest example yet of a pattern that is going to repeat. The next operating systems, the next office suites, and the next IDEs will ship local models that turn on without asking. Apple, Microsoft, and Google have all signaled this direction. Each of those models will create the same shape: a capable inference engine on every endpoint, a fresh way for sensitive data to flow into a system that the network controls cannot see.

For regulated engineering teams, the answer is not to ban AI. It is to be deliberate about which models run, where they run, and on what data. That means default-deny on endpoint AI, an explicit sanction process for each new local model that lands, and the same provenance, evals, and logging discipline you would apply to a hosted LLM. The browser is becoming an operating-system surface for AI. Treat it like one.

About the author

Kai Token leads applied security at Fraktional, where the team helps engineering organizations adopt AI in regulated environments without giving up audit posture. The view from this seat: AI security is mostly governance plumbing, and the boring controls (policies, evals, egress, logs) are the ones that actually keep teams out of trouble.