Choose the control you actually need.
Service access, account access and sensitive-data protection answer different questions. Test the one your policy depends on.
- 01Block the service
- Can this device reach the AI service?
A domain, category or application rule can deny access on the network or client paths it controls.
It does not distinguish personal and work accounts on the same service, or inspect the content of a permitted prompt.
- 02Restrict the account
- Can employees use only the approved workspace?
An account or tenant restriction needs a supported identity, browser or security-product feature for that specific service.
Verify allowed and denied accounts, sign-in changes and bypass paths. A domain block alone is not an account restriction.
- 03Inspect the content
- Can this prompt or file be sent?
A supported DLP path evaluates the information against the configured policy and applies its available response.
Test typed text, pasted text and uploads separately. Content inspection does not by itself restrict the signed-in account.
Method reference: July 2026. Control distinctions updated September 2026. Vendor menus and supported actions change; treat the paths as configuration orientation and validate your current deployment.
Scroll horizontally to compare all columns.
| Method | Where it enforces | Best for | What it misses |
|---|---|---|---|
| Microsoft Defender for Cloud Apps + Entra | Devices onboarded to Defender for Endpoint | Microsoft 365 E5 / Defender shops | Paths outside supported, onboarded devices |
| Zscaler (ZIA Cloud App Control) | Traffic steered through Zscaler | Existing ZIA deployments | Traffic not steered through the configured service |
| Netskope (Real-time Protection) | Traffic steered through Netskope | Existing Netskope SSE deployments | Unsteered traffic and unverified app actions |
| DNS / firewall / browser policy | Configured network/resolver or managed-browser path | Existing DNS, firewall or browser management | DNS-over-HTTPS, hotspots, personal devices |
Block ChatGPT with Microsoft Defender for Cloud Apps and Entra
If you run Microsoft 365 with Defender for Endpoint, this is the cleanest path: one Unsanctioned tag enforces at the endpoint for browsers, the desktop app, and scripts alike.
Confirm prerequisites
You need devices onboarded to Microsoft Defender for Endpoint, cloud protection and network protection enabled, required browser protection configured, and the Defender for Endpoint integration switched on in Defender for Cloud Apps settings. Without these, the Unsanctioned tag is monitoring-only.
Find ChatGPT in the Cloud app catalog
In the Microsoft Defender portal, open Cloud apps, then Cloud app catalog, and filter by the Generative AI category. Microsoft maintains this category and groups over a thousand known generative AI services, including ChatGPT and OpenAI.
Tag the app as Unsanctioned
Select ChatGPT and apply the Unsanctioned tag. The app's domains sync to Defender for Endpoint as custom URL indicators, and network protection can enforce the block on supported onboarded devices. Test the required browsers and applications rather than assuming every client and transport is covered.
Carve out exceptions with Entra
Keep the app unsanctioned for everyone, then use Microsoft Entra Internet Access web content filtering with Conditional Access to allow specific groups (for example, an approved pilot team) to reach it.
Plan desktop-app controls
Use the supported application-control or device-management capabilities for each operating system. Verify installation and launch behaviour on your managed devices; Windows and macOS controls are not interchangeable.
What this misses
Enforcement only reaches devices onboarded to Defender for Endpoint. Microsoft's own deployment guidance notes users can still reach unsanctioned apps from unmanaged devices and personal networks. Personal phones, home laptops, and BYOD stay invisible.
Block ChatGPT with Zscaler
Zscaler Internet Access ships an AI & ML Applications category with per-app actions, so you can block outright, warn, isolate, or allow with upload controls.
Add a Cloud App Control rule
In the ZIA Admin Portal, go to Policy, then URL & Cloud App Control, and add a Cloud App Control rule using the AI & ML Applications category. Zscaler maintains this category and includes ChatGPT and the OpenAI platform.
Scope the rule
Select ChatGPT (and any other OpenAI apps you want covered), then scope the rule to users, groups, departments, or locations. Most teams start with a broad scope and carve out an approved pilot group.
Pick the action
Choose Block to deny access outright, Caution to show a warning page users can click through, or Isolate to run the session in Zscaler Browser Isolation. For an allowed service, confirm the upload or tenant-restriction features supported by your deployed Zscaler configuration and test the intended action.
Or block the whole URL category
Alternatively, block the AI & ML Applications URL category in URL Filtering. This is broader and catches more tools, but it also breaks any legitimate AI tool your teams already rely on.
What this misses
Zscaler only controls traffic that is steered through it. Devices without Client Connector, phones on cellular, and personal machines bypass the policy entirely. Caution pages also lose their effect once users learn to click through them.
Block ChatGPT with Netskope
Netskope covers generative AI through a maintained web category and per-app controls in Real-time Protection, including coaching templates and tenant-level instance awareness.
Create a Real-time Protection policy
In the Netskope admin console, go to Policies, then Real-time Protection, and create a new policy. Netskope also offers a dedicated AI Guardrails policy type for generative AI controls.
Set the destination
Choose the Generative AI category to cover the whole class of tools, or select the ChatGPT cloud app specifically. Netskope maintains the category and tracks hundreds of generative AI applications in its Cloud Confidence Index.
Choose Block or User Alert
Set the action to Block, or use User Alert with a coaching template that warns users and lets you point them to the approved alternative. If using instance-aware restrictions, verify that the intended work account is allowed and the personal account is denied on the supported path. Do not infer this from a domain block.
Apply and order the policy
Scope the policy to users, groups, or organizational units, place it correctly in the policy order, and publish. Test with a pilot group before enforcing organization-wide.
What this misses
Same steering limitation: only traffic through the Netskope client or gateway is controlled. Category coverage also lags brand-new AI tools, so the newest app your employees found this week may not be categorized yet.
Block ChatGPT with DNS, firewall, or browser policy
No SSE platform required. Domain and category blocking at the network edge is the fastest method to deploy, and the easiest to bypass.
Block the ChatGPT web domains
At your DNS filter or firewall, block chatgpt.com and chat.openai.com, plus the asset domains the app loads from: oaistatic.com and oaiusercontent.com. Wildcard the subdomains. Confirm the domains and expected impact against your current application and policy.
Decide on api.openai.com separately
Blocking api.openai.com affects direct API traffic traversing the controlled path. A SaaS provider may call the API from its own backend, outside that path. Inventory the actual requests and expected impact before applying the rule.
Use your firewall's AI category if it has one
Most current NGFW and DNS-filtering vendors ship a generative AI or AI services category. Category blocking catches sister tools automatically, at the cost of occasional false positives on legitimate services.
Add a managed-browser blocklist
For managed browsers, push the URLBlocklist policy for Chrome and Edge through Group Policy or MDM with the ChatGPT domains. This holds even when the device is off the corporate network, but only inside the managed browser.
What this misses
DNS and firewall rules only apply on networks and resolvers you control. DNS-over-HTTPS, mobile hotspots, home Wi-Fi, and personal devices all bypass them, and OpenAI ships new domains over time. Browser blocklists only hold inside the managed browser.
Why blocking ChatGPT fails as a strategy
Every method above works on the slice of devices and networks it can see. The problem is what happens on the rest. The research and practical considerations below explain why blocking needs supporting controls.
of AI users brought their own AI tools to work. Blocking one sanctioned path does not remove the demand.
Microsoft and LinkedIn, 2024 Work Trend Index
of people using AI at work were reluctant to admit using it for their most important tasks. Blocking can encourage less visible usage.
Microsoft and LinkedIn, 2024 Work Trend Index
Blocking ChatGPT alone leaves alternatives such as Claude, Gemini, DeepSeek and Perplexity. Assess the tools and data paths employees actually use.
Coverage consideration
A policy that leaders bypass is harder to sustain. Apply approved-tool and data-handling rules consistently, including to senior executives.
Policy consideration
Rules on paper do not enforce themselves. Pair acceptable-use policies with appropriate technical controls, training and incident-response procedures.
Security consideration
Usage outside monitored paths can leave teams without the evidence needed to detect and investigate incidents. Review visibility gaps alongside blocking policies.
Monitoring consideration
Blocking is a whack-a-mole game against a catalog that keeps growing. Aona’s catalog tracks more than 10,000 AI tools. When one tool is blocked, employees may move to a personal device or an alternative. The organizations that reduce risk are the ones that can see usage and control the data, not the ones with the longest blocklist.
Explore the wider evidence and its sources on our Shadow AI Statistics 2026 page.
Govern ChatGPT: discover, set policy, protect data, coach
Keep a short blocklist for tools you genuinely cannot accept. For everything else, govern the usage instead of fighting it.
Discover what is actually in use
Build an inventory of observed employee AI use. Aona matches activity from deployed browser extensions and native endpoint apps against a catalog of more than 10,000 AI tools. Complement this with review of embedded SaaS features and paths outside deployed coverage.
Shadow AI discovery →Set policy per tool and per role
Sanction a default assistant, allow low-risk tools, and restrict the genuinely risky ones. Engineering, legal, and marketing do not need the same rules. A short allow-with-conditions list beats a long blocklist that ages badly.
Generative AI DLP →Block or redact only the sensitive data
Instead of blocking the tool, stop the data that should not leave: credentials, customer records, source code, financials. On supported installed-client paths, Aona applies configured prompt and file policies. For a supported DOCX, XLSX or PDF redaction action, inspect the returned file and its layout before approval.
DLP for ChatGPT →Coach in the moment
When someone pastes something risky, tell them why it is risky right there in the flow of work and point them to the approved path. In-the-moment coaching changes behavior in a way a block page never does.
Workforce AI security →