Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Zscaler Browser Isolation Hide Data From the AI Model?
No. Browser isolation keeps web code off the device, and the model reading the rendered page still receives its values, so ask what the model reads on that screen and who approves each action.
A claims agent opens a pending claim inside an isolated browser session. The page is drawn on Zscaler's infrastructure, the laptop receives a picture of it rather than the page's own code, and the claim number, the claimant's name, the date of birth and the reimbursement account all appear in it. Isolation did its job: no web code touched the device. The model read every field on the screen.
Two boundaries get called isolation, and this question is about the second. The first runs between the endpoint and the web, and remote rendering was built for it. The second would run between the values a page shows and the model that reads them. Zscaler's pages describe the first, on the session and on the AI traffic, and none describes a step that changes a value on the claim screen before a model reads it. The session is isolated; what a security team has to establish is what the model was handed while it was.
That gap has a cost for the organization's record. A claim number and an account number that enter a model's context travel with the run, into the next prompt, the transcript and the note the agent drafts (What Is the PII Wall?).
Key findings
- For a claim screen to stay out of a model's reach, the policy values would have to render as consistent tokens before any model reads the page, with real values released only at an approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment, submission or record change the agent makes with those values, and a record of what the model received on each screen (RedactSure vs Zscaler: 2026 Comparison & Alternative).
- Zscaler's generative AI page offers browser isolation for AI applications and does not state that a value on the rendered page is replaced before a model reads it (Zscaler, Generative AI, 2026).
- The same page restricts "clipboard use for uploads and downloads" inside an isolated session, a rule about what a person can move, not what a model can read (Zscaler, Generative AI, 2026).
- The AI Security page states that the platform "sits inline across the full AI workflow" and applies inline DLP "to every model, agent, and API call in real time" (Zscaler, AI Security, 2026).
- A redaction model trained on rendered pages reports "more than doubling text-extraction baseline accuracy (0.753 vs 0.357 mAP@50)," an accuracy measure for finding values in pixels (Zhao, 2026).
What does browser isolation actually isolate?
Remote rendering moves execution. The page's code runs in a browser on the provider's infrastructure, and the endpoint receives a representation of the result, so a hostile script in a bought application has no process on the laptop to reach (How to Protect Data Without Cloud Browser Rendering?). The data on the page travels where it always did: the application draws it, and whoever reads the drawing sees it.
Zscaler's description of the feature in its AI context is narrow. The generative AI page offers to "render AI and ML applications in Browser Isolation to allow user prompts while restricting clipboard use for uploads and downloads" (Zscaler, Generative AI, 2026). The sentence names two effects, prompts allowed and clipboard restricted, and says nothing about the values the application draws.
Web code is untrusted, a laptop holds sessions worth stealing, and rendering elsewhere removes both exposures. That is the right shape for the problem the feature solves.
An agent changes what the session is for. A person watching an isolated screen sees the isolation working; nobody watches the agent's read, which is the event that matters here. Enterprise Browser or Render-Layer Tokenization? sets the two neighboring categories beside this one. The read is the exception in the review: one of the 86 AI security and data protection products describes masking the values on the pages an agent works in, and 58 document control over where data can go (How Many AI Security Products Control What an AI Agent Sees?).
What does the model receive from an isolated page?
The record is a pending claim in a claims platform the organization bought: claim number, claimant name, date of birth, policy number, reimbursement account, and a notes field from the adjuster's call. A browser agent asked to summarize the claim reads those fields the way any computer-use agent does, from the rendered page, whether it consumes the document, the accessibility tree or a screenshot.
Isolation does not shorten the list. The screen renders the same values in the same places, and only the machine doing the drawing changed, so the model receives the claim number, the name, the date of birth and the account number.
An evaluation of web agents found they "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025). The failure is an agent using a field it did not need.
The session removes the channels a person uses to carry a value out: there is no local download folder, and the clipboard is restricted. Those controls reduce where a value can go after the read, not what is on the screen during it. Utility is the usual objection, and the record answers it: replacing identifiers with consistent pseudonyms and restoring them after the model's work reduces semantic utility errors by a factor of five compared with baseline techniques (Does Masking Data on Screen Break Browser Agents?).
What do the vendors themselves say?
Zscaler describes the control in three places, none of them the rendered page.
| Dimension | Zscaler, per its pages | What a buyer should verify |
|---|---|---|
| Where the control sits | "Zscaler sits inline across the full AI workflow" (Zscaler, AI Security, 2026) | Whether a page an agent reads in a bought application crosses it |
| What the model receives | "filter sensitive data from LLMs" (Zscaler, AI Security, 2026) | Whether a value is replaced on the page before the read |
| What record exists | "the data is stopped in transit and the attempt is recorded" (Zscaler, OpenShell, 2026) | Whether the record shows the screen as the model read it |
The AI Security page applies inline DLP "to every model, agent, and API call in real time," and its control list runs from "filter sensitive data from LLMs" to "block access by role in real time," both rules about a transaction rather than a page (Zscaler, AI Security, 2026).
Its blog sets the boundary at a runtime that "contains the agent and governs what it can see, do, and reach," with Zscaler picking up "at the moment the agent reaches beyond the runtime" (Zscaler, OpenShell, 2026). The runtime there is NVIDIA's product; Zscaler adds inspection of the calls the agent makes outward, after the read.
Not described in the pages reviewed is a step that replaces a value on the rendered page before a model reads it. That absence is the gap this page set out to check.
Where does the DLP check stop and the model start?
DLP inspects content as it moves. Zscaler's generative AI page promises to "Secure sensitive data from GenAI apps by enforcing DLP blocking across GenAI interactions," and it adds that a buyer gets "a better understanding of GenAI use by seeing all input prompts users send to apps" (Zscaler, Generative AI, 2026).
Both describe a check on a request, where the prompt is visible and a policy can stop it. A claim screen is drawn before the agent writes a prompt about it, so the prompt carries the claim number and the account number when DLP reads it. A block stops that request, and the next attempt reads the same fields.
De-identification has a defined shape: HHS describes "two methods that can be used to satisfy the Privacy Rule's de-identification standard," Expert Determination and Safe Harbor, and a clipboard rule performs neither (HHS Office for Civil Rights, 2012).
The nearest published design is a "simple, modular, and model-agnostic defense operating at the agent-tool interface," which its authors report "achieves perfect security with high utility across all four public benchmarks" (Bhagwatkar et al., 2026). It sits at the tool boundary, after the read.
Detection quality is the other half: the benchmark's best model reports 0.753 mAP@50 on rendered pages, a measure of detection, not of what a model is shown (Zhao, 2026). A field that renders ACCT_014 carries no value to detect (Runtime Tokenization vs DLP for AI Agents).
Who approves what the agent does in an isolated session?
An approval is a decision about one action, made by a person, with the amount and the destination in view. Zscaler's pages describe access policy and inspection, which decide what a session may reach and what happens to a call; "block access by role in real time" is a rule set before the run (Zscaler, AI Security, 2026). A rule is not a person looking at a reimbursement.
The post about runtime boundaries makes the distinction from the other side. Its reading of public incidents is that "in each case the agent had more access than its task required, and nothing stood between it and the systems it touched" (Zscaler, OpenShell, 2026).
The blog adds "governing each call by identity and policy, with inline inspection" and reports that "the data is stopped in transit and the attempt is recorded" (Zscaler, OpenShell, 2026). That record answers an investigator's question after the fact, not the question of who saw the amount before the payment left.
The incidents show why that matters: "Cursor's agent deleted PocketOS's production database via a single rogue API call" (Columbia DAPLab, 2026). A named approver who sees the claim and the account number can refuse a payment a policy would have allowed, and a better model does not remove the need for that person (Does a Smarter Model Stop Prompt Injection?).
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. The values chosen by policy are replaced with consistent tokens for the whole run, so a claim screen renders CLAIM_8841, CLAIMANT_014 and ACCT_014 and the model works on those. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each payment, submission or record change, and every screen as the model read it, every action and approval is written to a record that exports to the organization's own monitoring.
For this page's question, the change is what the model receives: a claim screen that would have shown a name and an account number shows two tokens in the same positions, and the summary is written about a claim the agent can still identify.
The lab puts the failure in the same place: the incidents are "the predictable consequence of deploying agents that can write to systems designed only to be read by careful humans" (Columbia DAPLab, 2026). A render-layer control leaves the agent able to write, and changes the values the agent writes about.
A session control decides where a page can run, and a render-layer control decides what it shows while the model reads it. The vendor named in the title has a comparison page that sets the two placements side by side: RedactSure vs Zscaler: 2026 Comparison & Alternative.
What the record shows
The values a model receives from an isolated page are the values that page rendered, because isolation moves where the page runs and leaves the drawing intact. The session controls reviewed here act on the copy path, the prompt traffic and the calls an agent makes outward, and none of them replaces a claim screen's name and account number before the model reads it. Those controls protect the browser and the flow, and they leave the model's input as the page drew it. To test it, name one agent and one claim screen, ask for a summary of the claim, and compare the text the model received with the page as it rendered. Where the two match, the values reached the model and the session only protected the endpoint.
Methodology and limitations
This page rests on Zscaler's product and blog pages, regulator guidance on de-identification, one lab position paper and three research papers. Vendor pages were read as of October 23, 2026, and each Sources line carries its date. Public documentation read in full gives a sound view of where each product applies its control.
No product on this page was tested for it. Not described in the pages reviewed means the pages recorded for that product do not address the point, and vendor features change. The products are described from their documentation, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization. Determinations about whether a workflow meets a regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers, and nothing replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Does Zscaler Browser Isolation hide data from the AI model?
No, not the data the model reads on the page. Isolation moves where the application runs and sends the endpoint a representation, and its own description pairs that with a restricted clipboard for uploads and downloads. The rendered claim screen still carries the claim number, the name and the account number, and a model reading it receives them. What changes the answer is a value replaced on the rendered page before the model reads it.
What does the model receive from a page rendered in isolation?
The same fields the page shows, in the same places. In a claims platform that means the claim number, the claimant's name, the date of birth, the policy number and the reimbursement account, whether the agent reads the document, the accessibility tree or a screenshot. Isolation changes the machine that draws the page, not its contents. A reviewer should ask for the screen the model read, field by field.
Does restricting the clipboard keep a value out of the model's context?
No. The clipboard is one channel for moving a value out of a session, and restricting it narrows what a person can copy or paste. It does not change what the page draws, so the model's read is unaffected. A value can still leave through a prompt the agent composes, a note it writes or a tool call it makes. The restriction protects a different boundary from the one the title asks about.
Does Zscaler's DLP check run before the model reads the page?
No, the check runs on the request. DLP blocking applies to GenAI interactions, and the vendor's own account of the control is that it can see the input prompts users send to apps. By then the agent has read the claim screen and written a prompt that contains its values. A block stops that request, and the next attempt reads the same fields, so only a substitution at the page keeps the read from carrying the value.
Who approves the payment an agent starts from an isolated session?
Nobody, from the pages reviewed. Zscaler describes role-based access, inline DLP and inspection of the calls an agent makes outward, all of which decide what a session or a call may do. None of them puts a person in front of one reimbursement with the amount and the destination visible. An approval carries a name and sits outside the model; a policy that allowed the action is a different control.
What record shows what the model saw on an isolated page?
A record of the attempt, not of the read. The vendor pages describe inspection of each call an agent makes outward and a note that an attempt was stopped, which tells an investigator a call was blocked. They do not show the claim screen the model read, the values on it, or the person who released a real value. A team that needs that record should ask for the screen as tokens, the approval and the release.
How RedactSure Keeps an Isolated Claim Screen Out of the Model
An isolated session keeps web code off the laptop and still hands every field on the claim screen to the model that reads it. Zscaler's page restricts "clipboard use for uploads and downloads," which governs the copy path.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent reads the claim number, the claimant's name, the date of birth and the reimbursement account, and drafts the note from them. Inside the governed environment the same screen renders CLAIM_8841, CLAIMANT_014 and ACCT_014, and a named person approves the reimbursement, with the real account number resolving only at the payment destination.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A claim number read inside an isolated session stays in the model's context for every later prompt of the run. Bring one claim task and see, with test values, what the model reads and where the real account number lands. Book a demo