Google Gemini ships directly inside Chrome and as standalone Android apps, so blocking a single URL is rarely enough — access can persist through wildcard subdomains, browser side-panel features, or unmanaged app installs. This tutorial builds a layered governance approach in Microsoft Intune: you start by confirming Chrome Enterprise is Intune-managed, then apply core Chrome policies through the Settings Catalog, extend coverage with Custom OMA-URI entries for AI settings not exposed in the catalog, and add a network-layer backstop with Microsoft Defender for Endpoint Web Content Filtering. For mobile, you use Managed Google Play to restrict Gemini and the AICore system component on Android Enterprise devices. Finally, for organizations that need conditional rather than blanket controls, you configure Chrome Enterprise Premium integration so Gemini access is granted only from Intune-compliant devices. Each step includes verification — checking chrome://policy, reviewing Defender reports, and validating the Android work profile — so you can confirm the policies are actually applied before rolling them out fleet-wide.
Before you start
What you will learn
- You will learn how to enforce granular controls over Google Gemini AI access across Chrome and Android devices by combining Microsoft Intune configuration policies, Settings Catalog, Custom OMA-URI settings, Managed Google Play, and Microsoft Defender for Endpoint web content filtering. You will also learn how to enable device-posture-based Gemini access using Chrome Enterprise Premium integration with Intune compliance signals.
- Uncontrolled access to generative AI tools like Gemini can lead to data leakage, compliance violations, and shadow IT. Centralizing these controls in Intune lets you govern AI usage across your device fleet while preserving legitimate productivity.
Requirements
- You need administrative access to the Microsoft Intune admin center and the Microsoft Defender portal, plus access to the Google Admin console and Azure AD (Microsoft Entra ID) for the Chrome Enterprise Premium integration. A test or pilot device group enrolled in Intune is required to validate policies before broad rollout.
- Intune Administrator (or Endpoint Security Manager) in Microsoft Entra ID
- Application Administrator (or Cloud Application Administrator) to create the Azure AD app registration and grant Graph admin consent
- Microsoft Defender for Endpoint Security Administrator to create Web Content Filtering policies
- Google Workspace / Chrome Enterprise Super Admin to configure the Intune connection and Access Context Manager
Good to know
- Plan for a phased rollout: core Chrome policies can be deployed in under an hour, while the Chrome Enterprise Premium integration involves cross-console setup that may take longer.
- Steps reference the Microsoft Intune admin center, the Microsoft Defender portal, and the Google Admin console. Exact Chrome ADMX policy availability depends on the ADMX version ingested into your tenant; test on a pilot group first.
Quick answer
Yes — Intune can enforce Gemini controls across Chrome and Android. Deploy Chrome Enterprise as a managed Win32 app, then create a Windows Settings Catalog configuration profile that adds Google Chrome policies (URLBlocklist with wildcards, ExtensionInstallBlocklist, AI feature settings). Use Custom OMA-URI for settings the catalog doesn't expose, add Defender Web Content Filtering as a network backstop, and use Managed Google Play for Android. Verify everything at chrome://policy and in Defender reports.
Devices > Configuration > Create > New policyStep-by-step tutorial
7 stepsDeploy Chrome Enterprise via Intune Win32 App
Ensure Chrome Enterprise is managed by Intune before applying any Gemini policies.
Apps > Windows > AddChrome policies only apply reliably when the browser is deployed and managed through Intune, so start here.
- Download the Chrome Enterprise Windows MSI (64-bit, Stable channel) from the Chrome Enterprise download page. You can do this with PowerShell:
After downloading, verify the file before packaging it. 2. In the Intune admin center, go to Apps > Windows > Add. 3. Select the app type. The source material references adding it as a Line-of-business app and uploading the MSI directly; for Win32 packaging you would wrap the MSI as an .intunewin file instead. 4. Configure the install command: msiexec /i "GoogleChromeStandaloneEnterprise64.msi" /qn ALLUSERS=1 5. Configure the uninstall command: msiexec /x {8A69D345-D564-463C-AFF1-A69D9E530F96} /qn 6. Assign the app to your target device groups and wait for deployment to complete.
# Download Chrome Enterprise MSI
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/GoogleChromeStandaloneEnterprise64.msi" -OutFile "ChromeEnterprise.msi"
# Verify download
Get-FileHash ChromeEnterprise.msi -Algorithm SHA256The uninstall product code {8A69D345-D564-463C-AFF1-A69D9E530F96} is the standard Google Chrome MSI GUID, but confirm it against your downloaded MSI before relying on it. Use supersedence relationships to roll out newer Chrome versions automatically by creating a new Win32 app per release.
Create a Chrome Configuration Profile Using Settings Catalog
Apply core Chrome policies that control Gemini access and AI features across Windows devices.
Devices > Configuration > Create > New policySettings Catalog gives the broadest, easiest-to-manage coverage of Chrome enterprise policies.
1. In the Intune admin center, go to Devices > Configuration > Create > New policy. 2. Set Platform to Windows 10 and later and Profile type to Settings catalog. 3. Click Add settings and search for Google Chrome (or ADMX - Google Chrome, depending on which the ADMX ingestion your tenant exposes). 4. Add and configure the following policy categories: - URLBlocklist — add https://gemini.google.com/*, https://*.gemini.google.com/*, and https://bard.google.com/*. - ExtensionInstallBlocklist — block *gemini* and *bard* extension patterns. - DefaultSearchProviderEnabled / DefaultSearchProviderSearchURL — keep standard Google search available. 5. If your ingested ADMX version exposes them, disable AI-specific settings (AI features, experimental features, AI side-panel integrations). 6. Assign the profile to your target device groups.
{
"URLBlocklist": [
"https://gemini.google.com/*",
"https://*.gemini.google.com/*",
"https://bard.google.com/*"
],
"DefaultSearchProviderEnabled": true,
"DefaultSearchProviderSearchURL": "https://www.google.com/search?q={searchTerms}",
"ExtensionInstallBlocklist": [
"*gemini*",
"*bard*"
]
}The JSON above illustrates the policy values, not a Settings Catalog import format — configure each policy through the catalog UI. Always use wildcards. Blocking only a specific path such as https://gemini.google.com/app will not block the full Gemini surface. The exact AI feature settings available depend on your ingested Chrome ADMX version and may not appear in every tenant.
Configure Advanced AI Governance with Custom OMA-URI
Enforce Chrome AI settings that are not exposed in the Settings Catalog.
Devices > Configuration > Create > New policy > Templates > CustomUse Custom OMA-URI policies when you need Chrome AI controls that the Settings Catalog does not surface.
1. Go to Devices > Configuration > Create > New policy, set Platform to Windows 10 and later and Profile type to Templates > Custom. 2. Add OMA-URI settings such as: - Name: ChromeGeminiAIPolicy — OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~ContentSettings/DefaultGenAISettings — Data type: String — Value: <enabled/><data id="DefaultGenAISettingsValue" value="2"/> - Name: ChromeAIFeaturesBlock — OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/GenAILocalFoundationModelSettings — Data type: String — Value: <disabled/> - Name: ChromeURLBlocklist — OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/URLBlocklist — Data type: String — Value: <enabled/><data id="URLBlocklistDesc" value="1https://gemini.google.com/*2https://*.gemini.google.com/*"/> 3. Assign the profile to a small pilot group first. 4. After it applies, verify the resulting registry keys with PowerShell.
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "URLBlocklist" -ErrorAction SilentlyContinueThese OMA-URI paths and policy names are ADMX-backed; the exact policy names (for example GenAI-related policies) change between Chrome versions, so confirm them against the Chrome ADMX you have ingested before deploying broadly. Incorrect OMA-URI syntax can silently block the whole policy from applying — always pilot on a small group first.
Implement Network-Level AI Controls with Defender Integration
Block Gemini at the network layer as a backstop to browser policies.
Microsoft Defender portal > Settings > Endpoints > Web content filteringWeb Content Filtering in Microsoft Defender for Endpoint blocks Gemini even if a browser policy is bypassed or another browser is used.
- In the Microsoft Defender portal, go to Settings > Endpoints > Web content filtering.
- Click Create policy and name it, for example, Block AI Services - Gemini.
- Add the AI categories and URLs you want to block — such as
gemini.google.com,*.gemini.google.com,bard.google.com,*.bard.google.com,ai.google.dev, andmakersuite.google.com— and keep an allowlist for essential Google domains like*.google.com/search. - Assign the policy to your device groups.
{
"blockedCategories": ["Artificial Intelligence", "Generative AI"],
"blockedUrls": [
"gemini.google.com",
"*.gemini.google.com",
"bard.google.com",
"*.bard.google.com",
"ai.google.dev",
"makersuite.google.com"
],
"allowedUrls": [
"*.google.com/search"
]
}The JSON is a representation of the block/allow lists, not a literal Defender import file — enter the URLs and categories through the portal. Web content filtering requires Defender for Endpoint onboarding. Category names and availability can vary; if a dedicated AI category is not present in your tenant, rely on explicit URL entries. Network-level blocking can affect legitimate Google services, so test carefully and maintain an allowlist.
Control Android Gemini Apps via Managed Google Play
Restrict Gemini and the AICore system component on Android Enterprise devices.
Apps > Android > Create > Managed Google Play appOn Android Enterprise, control Gemini through Managed Google Play and app configuration/restriction policies.
- Confirm Managed Google Play is connected: go to Devices > Android > Enrollment > Managed Google Play and complete the connection if needed.
- Add Gemini as a managed app: Apps > Android > Create > Managed Google Play app, search for Google Gemini (or Bard), select it, and click Sync. Wait for the sync to finish under Apps > Android > Android apps.
- Create an app configuration policy to disable AI features and data sharing using the managed configuration below.
- Add the Android AICore system component: Apps > Android > Create > Other > Android Enterprise system app, name it AICore, package name
com.google.android.aicore, and apply the appropriate restriction. - Create a device restriction configuration to further limit AI-related capabilities, then assign all policies to your Android device groups.
{
"kind": "androidenterprise#managedConfiguration",
"productId": "com.google.android.apps.bard",
"managedProperty": [
{ "key": "ai_features_enabled", "valueBool": false },
{ "key": "data_sharing_consent", "valueBool": false }
]
}Managed configuration keys such as ai_features_enabled are only honored if the app publisher actually exposes them — verify the available keys for the specific app version. Removing or restricting com.google.android.aicore may affect on-device AI features for other apps that depend on it; test on a pilot group first.
Verify and Validate the Gemini Configuration
Confirm all controls are applied and functioning across platforms.
chrome://policyValidate each layer end to end before considering the rollout complete.
- On a managed Windows device, open
chrome://policyand confirm the URLBlocklist, ExtensionInstallBlocklist, and any AI/GenAI policies are present with a Cloud or Platform source. Use the Reload policies button if needed. - Attempt to browse to
https://gemini.google.comand confirm it is blocked, and confirm an allowed URL such as Google search still works. - In the Microsoft Defender portal, review the Web content filtering reports for blocked connection attempts to the Gemini domains.
- On an Android Enterprise test device, confirm the restricted Gemini/AICore apps do not appear in the work profile.
- If you configured Chrome Enterprise Premium, test Gemini access from a compliant device (allowed) versus a non-compliant device (blocked) to validate the compliance-based access level.
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "URLBlocklist" -ErrorAction SilentlyContinueIf Gemini is still reachable after applying the URLBlocklist, the most common cause is a path-specific entry without wildcards or a policy that has not yet synced — reload policies at chrome://policy and confirm wildcard patterns. Compliance-based access changes can take time to propagate between Intune and Google.
Confirm the Gemini Controls Are Applied and Enforced
A successful configuration means Gemini access is blocked (or conditionally allowed) consistently across every layer you deployed, and each layer reports its policy as active from the expected source. Do not judge success by a single browser test — confirm the browser policy, the network backstop, the Android profile, and (if used) the compliance-based access path independently, because any one of them can silently fail while the others still block.
On a managed Windows device, open chrome://policy and confirm that URLBlocklist, ExtensionInstallBlocklist, and your default-search settings appear with a Source of Platform or Cloud and a Status of OK. A missing policy, a Source of User, or an error status means the profile did not apply to that device. For OMA-URI settings, confirm the corresponding registry values exist under HKLM:\SOFTWARE\Policies\Google\Chrome using PowerShell. In the Defender portal, review Web Content Filtering reports and confirm blocked connection attempts to Gemini domains are logged. On Android Enterprise devices, confirm Gemini and AICore do not appear (or are disabled) in the work profile. If you configured Chrome Enterprise Premium, verify that a compliant device is granted access and a non-compliant device is denied via Access Context Manager.
Interpret the result as enforcement, not just presence: a policy showing in chrome://policy proves it was delivered, but the URL test proves it actually blocks. Validate both.
- Gemini URLs are blocked in Chrome on managed devices;
chrome://policylists your Chrome policies with Source Platform/Cloud and Status OK; the expected registry keys exist; Defender logs blocked Gemini connections; Gemini/AICore are absent or disabled in the Android work profile; and compliant-vs-noncompliant devices are correctly allowed or denied where Chrome Enterprise Premium is used. - Gemini still loads despite the policy, policies are missing from chrome://policy or show a User source or an error status, the expected registry values are absent, Defender shows no blocked events, banned Android apps still appear in the work profile, or both compliant and non-compliant devices get the same access outcome. Any of these indicates a scoping, syntax, wildcard, or assignment problem to troubleshoot before rollout.
- Confirms the Settings Catalog / OMA-URI URLBlocklist reached the device and is active. Wildcards are present, so subdomains are covered.
- Returns the URLBlocklist value if the policy applied. No output means the OMA-URI/Settings Catalog policy did not reach this device.
- The definitive enforcement test. A wildcard URLBlocklist blocks all Gemini paths, not just the specific /app URL.
- Confirms the network-layer backstop is catching Gemini even if a browser policy is bypassed.
- Confirms the Managed Google Play and AICore restrictions applied to the Android Enterprise device.
Troubleshooting
Gemini is still accessible after applying the URLBlocklist policy
Cause: The blocklist entries target only specific paths (for example https://gemini.google.com/app) without wildcards, so other Gemini paths and subdomains remain reachable.
Rewrite the entries to use wildcard patterns that cover all paths and subdomains, such as https://gemini.google.com/* and https://*.gemini.google.com/*. Re-check chrome://policy to confirm the updated URLBlocklist is applied, and add a network-level backstop in Defender Web Content Filtering (Step 4) in case browser policy is bypassed.
Custom OMA-URI Chrome policy does not apply to any device
Cause: An incorrect ADMX-backed OMA-URI path or malformed XML/JSON value prevents the entire policy from being processed.
Validate the OMA-URI path against the Chrome ADMX policy names and confirm the Data type is String with correctly encoded <enabled/>/<disabled/> XML. Deploy to a small pilot group first, then verify with Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" on a target device before broad rollout.
Chrome shows no enterprise policies at chrome://policy
Cause: Chrome Enterprise is not deployed or managed by Intune, or the Win32 app assignment has not reached the device yet.
Confirm the Chrome Enterprise Win32 app shows as installed in the Intune admin center for the device, then reload chrome://policy and click Reload policies. Ensure the device is in the assigned group and force a sync from Company Portal if deployment is still pending.
Legitimate Google services break after enabling network-level blocking
Cause: Broad AI category or domain blocking in Defender Web Content Filtering also catches shared Google endpoints used by Search, Workspace or other services.
Add essential Google domains such as *.google.com/search to the allowlist and narrow the blocked URLs to Gemini-specific hosts (gemini.google.com, *.gemini.google.com, bard.google.com). Test each affected service and review Defender blocked-connection reports to identify over-blocking.
Gemini or AICore still appears in the Android work profile
Cause: The managed app was not synced from Managed Google Play, or the app configuration/device restriction policy is not assigned to the device group.
Re-sync from Apps > Android > Managed Google Play, confirm Gemini and com.google.android.aicore appear under Android apps, and verify the app configuration and device restriction policies are assigned to the correct Android Enterprise device group. Force a device sync and recheck the work profile.
Compliance-based (context-aware) Gemini access does not enforce as expected
Cause: The Intune connection in the Google Admin console, the Azure AD app registration/Graph permissions, or the federated credential is misconfigured, so device compliance signals are not shared.
Confirm the Intune integration in Google Admin console has the correct tenant ID, application ID and service account ID, grant admin consent for DeviceManagementManagedDevices.Read.All and DeviceManagementApps.Read.All, and verify the federated credential subject matches the Google service account ID before testing Access Context Manager rules.
Frequently asked questions
Can Microsoft Intune block Google Gemini in Chrome?
Yes. You deploy Chrome Enterprise through Intune, then use a Settings Catalog or Custom OMA-URI configuration profile to apply Chrome policies such as URLBlocklist and AI feature settings. For a stronger control you can add Microsoft Defender Web Content Filtering as a network-level backstop.
What is the difference between Settings Catalog and OMA-URI for Chrome policies?
Settings Catalog provides a searchable UI for the Chrome policies exposed in your tenant and is the easiest, least error-prone method. Custom OMA-URI lets you configure ADMX-backed Chrome policies that are not surfaced in Settings Catalog, but it requires exact policy paths and correctly encoded XML/JSON values.
Do I need Chrome Enterprise Premium to control Gemini access?
No. Basic URL blocking, AI feature restrictions and network filtering work with standard Chrome Enterprise policies and Defender. Chrome Enterprise Premium is only required for context-aware access that grants Gemini access based on Intune device compliance signals.
How do I block Gemini on Android Enterprise devices with Intune?
Connect Managed Google Play to Intune, add Gemini and the com.google.android.aicore system component as managed apps, then use app configuration and device restriction policies to disable AI features. Verify that the blocked apps do not appear in the work profile on a test device.
Why is Gemini still accessible after applying my URLBlocklist policy?
Blocking a single path such as https://gemini.google.com/app does not cover other paths or subdomains. Use wildcard patterns like https://gemini.google.com/* and https://*.gemini.google.com/* for comprehensive blocking, and check chrome://policy to confirm the policy is actually applied.
How can I verify that Chrome AI policies are applied on a device?
Open chrome://policy on the target device and confirm the relevant policies appear with a source of Cloud or Platform. You can also validate OMA-URI-deployed policies in the registry with Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome".
