ChatGPT Desktop App Includes an In-App Browser: How Do You Secure Embedded Browsers? Joby Menon (SVP, Product Management | Zscaler)

Zscaler Zero Trust Browser Extension runs inside the embedded browser of the ChatGPT desktop app. The same policies, detections, and enforcement your users get in Chrome, Edge, Firefox, and Safari is now available for the browser in ChatGPT desktop app. These security controls are for the web pages ChatGPT opens on the user’s behalf.  Whereas the conversation/prompt the user does with ChatGPT is secured by  Zscaler’s AI Security products. I hope the distinction between the two is clear and both are important. We will discuss and demonstrate three scenarios: monitoring every website ChatGPT opens, blocking paste on a specific site, and blocking a whole URL category. All three use policies can be configured from the Zscaler Zero Trust Browser admin console. The Gap: AI Apps Now Ship Their Own BrowsersThe ChatGPT desktop app is a native application, but it isn’t only that. Since OpenAI folded its Atlas browser into the unified desktop app in July, ChatGPT ships with a full Chromium browser inside itself, so its agent can open web pages, fill forms, look things up, and click through sites on the user’s behalf. Other AI applications are shipping the same pattern. This is very useful. It also opens a door most enterprises haven’t noticed is there.When an AI app opens a page inside its own embedded browser, that page is running on your user’s machine, under your user’s identity, with the user’s cookies and access. But it’s doing that in a browser your controls may never touch. IT hasn’t deployed anything into it. The policies you rely on in your standard browsers don’t automatically reach it. If someone wants to do something they wouldn’t be able to do in their normal browser, “just ask ChatGPT to open it for you” starts to look like the shortest path around your controls.We didn’t want the AI-app embedded browser to become that path. Where The Control SitsThe good news is that the embedded browser in the ChatGPT desktop app is Chromium. Our Zero Trust Browser Extension already runs across every browser our customers use: every Chromium-based browser (Chrome, Edge, and the rest), plus Firefox and Safari. That means the moment the extension is loaded inside ChatGPT’s embedded browser, it behaves the same way it does in any of those browsers.That includes page-level monitoring, clipboard and paste controls, URL category matching, DLP inspection, file upload and download policy, and any other rule the extension already enforces. There is no separate rulebook for the embedded case. The same policy engine that decides what a user can do in Chrome decides what the ChatGPT agent can do when it opens the same page inside itself. And because the embedded browser is Chromium, everything above works whether the user is on macOS or Windows.Figure 1. The Zero Trust Browser Extension already runs across Chromium-based browsers, Firefox, and Safari. The embedded browser inside the ChatGPT desktop app is Chromium, so the same policies apply there too.Deploying the extension into the embedded browser uses the same MDM-based method you already use for your other browsers, with one addition: the deployment script needs an explicit change to target the ChatGPT desktop app’s embedded browser. Installing the extension for Chrome does not cover it automatically. Once that change is in place, your existing policies apply the moment the embedded browser loads a page. See It In actionThe demo below runs on the ChatGPT desktop app on macOS. The user prompts the assistant, ChatGPT’s in-app browser control skill opens the embedded browser, and the Zero Trust Browser Extension enforces policy on whatever the page tries to do. We walked through three scenarios that map to controls IT teams already use in mainstream browsers. 1. Monitor Every Website the Agent OpensThe starting posture is visibility. In this scenario, a policy called Monitor All Website Visits is attached to a test user, with a single catch_all rule that fires whenever page.url exists. Effect: Allow. Severity: Informational. Nothing gets blocked. Everything gets logged.The user asks ChatGPT to open google.com in the embedded browser. ChatGPT replies “I’m using the in-app browser control skill to open Google in the embedded browser,” waits for approval, and opens Google in a new tab inside the ChatGPT window. The extension records it. In the admin console, a new detection lands for that page load with all the usual context: user, device posture, extension version, browser (Chrome), IP, geolocation, and the URL itself. From the SOC’s point of view, ChatGPT opening a page looks the same as any other browser tab opening a page.1.1 The user asks ChatGPT to open google.com in the embedded browser. ChatGPT uses its in-app browser control skill to handle the request, and asks for approval before opening the page.1.2 Google.com loads in a new tab inside the ChatGPT window.1.3 The detections list in the Zscaler admin console shows the page-open events flowing in under Monitor All Website Visits, effect Allow.1.4 A single detection carries the full record: policy, rule, effect, user identity, and device posture.Monitor mode is where most teams should start when they turn this on. Before you write block rules for ChatGPT, you want to know what your users are actually doing with the embedded browser.2. Block Paste on a Specific SiteThe second scenario shows a paste block. The policy is called Block Paste on DLP Test Site, with a rule block_paste_dlptest_domain that matches when page.url.domain is equal to dlptest.com. Effect: Block. Severity: Medium.Inside the ChatGPT embedded browser, the user opens dlptest.com, copies a line of text from the ChatGPT conversation, and tries to paste it into the HTTP POST form. The rule doesn’t care what the text is: on this domain, any paste is blocked. The extension catches it, shows the Zscaler “Paste Blocked” modal directly in the page, and drops a detection into the admin console with the rule that fired and the clipboard text that was blocked. The user sees a clear reason. The SOC sees the event and the content. Nothing reaches dlptest.com.2.1 The Zscaler Paste Blocked modal renders inside the ChatGPT embedded browser, directly over the dlptest.com form.2.2 The detection for Block Paste on DLP Test Site carries the user, the device posture, and the blocked clipboard text itself, captured inside the ChatGPT embedded browser.This is a normal DLP control. It just happens to work in a browser most enterprises don’t realize their users have.3. Block a URL Category (Gambling)The third scenario is a category-based block. The policy is called Block Gambling websites, and its rule matches whenever page.url.category is one of Gambling. Effect: Block. Severity: Medium.The user asks ChatGPT to open a gambling website in the embedded browser. ChatGPT tries pokerstars.com. The extension recognizes the category and replaces the page with the Zscaler Content Blocked interstitial. ChatGPT then narrates its own failure back to the user: “That site didn’t load in the embedded browser, so I’m retrying with another established gambling site.” That attempt gets blocked too. The block isn’t silent. The user sees why. The SOC sees the events.Notice what the agent did, though: it treated the block as a transient failure and went looking for another site that would satisfy the request. A domain blocklist would have lost that race. A category rule catches the second attempt exactly as it caught the first, and every attempt lands in the console.3.1 The Zscaler Content Blocked page inside ChatGPT’s embedded browser. The blocked URL, pokerstars.com, is shown alongside a “Request For Exception” button.3.2 Detection detail for Block Gambling websites: reason page.url.category is one of Gambling, effect Block, severity Medium.These three scenarios are a small slice of what’s available. Because the extension is running inside a Chromium browser, whatever policies you already enforce in your other browsers can be enforced here: DLP, file upload and download policy, credential protection, tenant restrictions, and so on. The point is not the specific rules we demonstrate in this demo. The point is that the embedded browser is no longer a blind spot. Why This Couldn’t WaitAI apps that ship an embedded browser are becoming common. ChatGPT is the loudest example, but it isn’t alone. Every AI product that runs an agent on the desktop has an incentive to give that agent a browser it can drive, and these apps reach mainstream users, not just the developers who adopted agent tools early. Every one of them is a second browser on the machine that the user didn’t install and IT didn’t configure. Closing that gap while the pattern is new is much easier than closing it once it’s widespread.Agents will use the embedded browser to do work under the user’s identity. That’s the whole point of embedding a browser in an AI app. It means the same audit and governance questions we ask about human web activity, and about WebMCP tool calls, now apply to page loads driven by an agent inside an AI app: which agent opened this page, on whose behalf, and what happened next. Today the extension answers the last two. Every page the agent opens is logged and enforced under the user’s identity, and what happens next is in the console, where it looks like any other Chromium page load. Telling agent-driven activity apart from the user’s own browsing is the next step, and it’s what the agent-aware policy work below is for. What’s NextThe Zero Trust Browser Extension is available today for the ChatGPT desktop app’s embedded browser, on both macOS and Windows. If you already run the extension in your other browsers, update your deployment to cover the embedded browser and your existing policies carry over. Reach out to your account team for a demo, or visit the product page to learn more.We’re working on the same coverage for other AI applications shipping their own embedded browsers, and on tighter, agent-aware policy primitives for cases where the caller is a model rather than a human. Zero Trust Browser is a must have security tool for every enterprise.  The flexible deployment options it provides Extension, Enterprise Browser, Cloud Browser Isolation and natively integrated with ZTE for application access and advanced data and cyber controls is unmatched.  

​[#item_full_content] Zscaler Zero Trust Browser Extension runs inside the embedded browser of the ChatGPT desktop app. The same policies, detections, and enforcement your users get in Chrome, Edge, Firefox, and Safari is now available for the browser in ChatGPT desktop app. These security controls are for the web pages ChatGPT opens on the user’s behalf.  Whereas the conversation/prompt the user does with ChatGPT is secured by  Zscaler’s AI Security products. I hope the distinction between the two is clear and both are important. We will discuss and demonstrate three scenarios: monitoring every website ChatGPT opens, blocking paste on a specific site, and blocking a whole URL category. All three use policies can be configured from the Zscaler Zero Trust Browser admin console. The Gap: AI Apps Now Ship Their Own BrowsersThe ChatGPT desktop app is a native application, but it isn’t only that. Since OpenAI folded its Atlas browser into the unified desktop app in July, ChatGPT ships with a full Chromium browser inside itself, so its agent can open web pages, fill forms, look things up, and click through sites on the user’s behalf. Other AI applications are shipping the same pattern. This is very useful. It also opens a door most enterprises haven’t noticed is there.When an AI app opens a page inside its own embedded browser, that page is running on your user’s machine, under your user’s identity, with the user’s cookies and access. But it’s doing that in a browser your controls may never touch. IT hasn’t deployed anything into it. The policies you rely on in your standard browsers don’t automatically reach it. If someone wants to do something they wouldn’t be able to do in their normal browser, “just ask ChatGPT to open it for you” starts to look like the shortest path around your controls.We didn’t want the AI-app embedded browser to become that path. Where The Control SitsThe good news is that the embedded browser in the ChatGPT desktop app is Chromium. Our Zero Trust Browser Extension already runs across every browser our customers use: every Chromium-based browser (Chrome, Edge, and the rest), plus Firefox and Safari. That means the moment the extension is loaded inside ChatGPT’s embedded browser, it behaves the same way it does in any of those browsers.That includes page-level monitoring, clipboard and paste controls, URL category matching, DLP inspection, file upload and download policy, and any other rule the extension already enforces. There is no separate rulebook for the embedded case. The same policy engine that decides what a user can do in Chrome decides what the ChatGPT agent can do when it opens the same page inside itself. And because the embedded browser is Chromium, everything above works whether the user is on macOS or Windows.Figure 1. The Zero Trust Browser Extension already runs across Chromium-based browsers, Firefox, and Safari. The embedded browser inside the ChatGPT desktop app is Chromium, so the same policies apply there too.Deploying the extension into the embedded browser uses the same MDM-based method you already use for your other browsers, with one addition: the deployment script needs an explicit change to target the ChatGPT desktop app’s embedded browser. Installing the extension for Chrome does not cover it automatically. Once that change is in place, your existing policies apply the moment the embedded browser loads a page. See It In actionThe demo below runs on the ChatGPT desktop app on macOS. The user prompts the assistant, ChatGPT’s in-app browser control skill opens the embedded browser, and the Zero Trust Browser Extension enforces policy on whatever the page tries to do. We walked through three scenarios that map to controls IT teams already use in mainstream browsers. 1. Monitor Every Website the Agent OpensThe starting posture is visibility. In this scenario, a policy called Monitor All Website Visits is attached to a test user, with a single catch_all rule that fires whenever page.url exists. Effect: Allow. Severity: Informational. Nothing gets blocked. Everything gets logged.The user asks ChatGPT to open google.com in the embedded browser. ChatGPT replies “I’m using the in-app browser control skill to open Google in the embedded browser,” waits for approval, and opens Google in a new tab inside the ChatGPT window. The extension records it. In the admin console, a new detection lands for that page load with all the usual context: user, device posture, extension version, browser (Chrome), IP, geolocation, and the URL itself. From the SOC’s point of view, ChatGPT opening a page looks the same as any other browser tab opening a page.1.1 The user asks ChatGPT to open google.com in the embedded browser. ChatGPT uses its in-app browser control skill to handle the request, and asks for approval before opening the page.1.2 Google.com loads in a new tab inside the ChatGPT window.1.3 The detections list in the Zscaler admin console shows the page-open events flowing in under Monitor All Website Visits, effect Allow.1.4 A single detection carries the full record: policy, rule, effect, user identity, and device posture.Monitor mode is where most teams should start when they turn this on. Before you write block rules for ChatGPT, you want to know what your users are actually doing with the embedded browser.2. Block Paste on a Specific SiteThe second scenario shows a paste block. The policy is called Block Paste on DLP Test Site, with a rule block_paste_dlptest_domain that matches when page.url.domain is equal to dlptest.com. Effect: Block. Severity: Medium.Inside the ChatGPT embedded browser, the user opens dlptest.com, copies a line of text from the ChatGPT conversation, and tries to paste it into the HTTP POST form. The rule doesn’t care what the text is: on this domain, any paste is blocked. The extension catches it, shows the Zscaler “Paste Blocked” modal directly in the page, and drops a detection into the admin console with the rule that fired and the clipboard text that was blocked. The user sees a clear reason. The SOC sees the event and the content. Nothing reaches dlptest.com.2.1 The Zscaler Paste Blocked modal renders inside the ChatGPT embedded browser, directly over the dlptest.com form.2.2 The detection for Block Paste on DLP Test Site carries the user, the device posture, and the blocked clipboard text itself, captured inside the ChatGPT embedded browser.This is a normal DLP control. It just happens to work in a browser most enterprises don’t realize their users have.3. Block a URL Category (Gambling)The third scenario is a category-based block. The policy is called Block Gambling websites, and its rule matches whenever page.url.category is one of Gambling. Effect: Block. Severity: Medium.The user asks ChatGPT to open a gambling website in the embedded browser. ChatGPT tries pokerstars.com. The extension recognizes the category and replaces the page with the Zscaler Content Blocked interstitial. ChatGPT then narrates its own failure back to the user: “That site didn’t load in the embedded browser, so I’m retrying with another established gambling site.” That attempt gets blocked too. The block isn’t silent. The user sees why. The SOC sees the events.Notice what the agent did, though: it treated the block as a transient failure and went looking for another site that would satisfy the request. A domain blocklist would have lost that race. A category rule catches the second attempt exactly as it caught the first, and every attempt lands in the console.3.1 The Zscaler Content Blocked page inside ChatGPT’s embedded browser. The blocked URL, pokerstars.com, is shown alongside a “Request For Exception” button.3.2 Detection detail for Block Gambling websites: reason page.url.category is one of Gambling, effect Block, severity Medium.These three scenarios are a small slice of what’s available. Because the extension is running inside a Chromium browser, whatever policies you already enforce in your other browsers can be enforced here: DLP, file upload and download policy, credential protection, tenant restrictions, and so on. The point is not the specific rules we demonstrate in this demo. The point is that the embedded browser is no longer a blind spot. Why This Couldn’t WaitAI apps that ship an embedded browser are becoming common. ChatGPT is the loudest example, but it isn’t alone. Every AI product that runs an agent on the desktop has an incentive to give that agent a browser it can drive, and these apps reach mainstream users, not just the developers who adopted agent tools early. Every one of them is a second browser on the machine that the user didn’t install and IT didn’t configure. Closing that gap while the pattern is new is much easier than closing it once it’s widespread.Agents will use the embedded browser to do work under the user’s identity. That’s the whole point of embedding a browser in an AI app. It means the same audit and governance questions we ask about human web activity, and about WebMCP tool calls, now apply to page loads driven by an agent inside an AI app: which agent opened this page, on whose behalf, and what happened next. Today the extension answers the last two. Every page the agent opens is logged and enforced under the user’s identity, and what happens next is in the console, where it looks like any other Chromium page load. Telling agent-driven activity apart from the user’s own browsing is the next step, and it’s what the agent-aware policy work below is for. What’s NextThe Zero Trust Browser Extension is available today for the ChatGPT desktop app’s embedded browser, on both macOS and Windows. If you already run the extension in your other browsers, update your deployment to cover the embedded browser and your existing policies carry over. Reach out to your account team for a demo, or visit the product page to learn more.We’re working on the same coverage for other AI applications shipping their own embedded browsers, and on tighter, agent-aware policy primitives for cases where the caller is a model rather than a human. Zero Trust Browser is a must have security tool for every enterprise.  The flexible deployment options it provides Extension, Enterprise Browser, Cloud Browser Isolation and natively integrated with ZTE for application access and advanced data and cyber controls is unmatched.