Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to protect sensitive data without cloud browser rendering?

Rendering inside a governed environment the organization controls, with policy-chosen values tokenized before a model reads the screen, separates custody of the screen from its content. Moving rendering to a provider's cloud only changes who runs the browser; the full record is still assembled and displayed, so an AI model reading that session receives every value.

Browser fields become protected tokens through a transparent gate before reaching a model window.

Rendering inside a governed environment the organization controls, with policy-chosen values tokenized before a model reads the screen, separates custody of the screen from its content. Moving rendering to a provider's cloud only changes who runs the browser; the full record is still assembled and displayed, so an AI model reading that session receives every value. Cloud rendering solves a real problem, isolating active web content from the endpoint, but it is not the only place a screen can be produced. If the browser session runs in a controlled virtual environment under the organization's own keys and policies, and policy-chosen values are replaced with tokens through render-layer tokenization, the model that assists with the work never receives the real values, and no third-party rendering service sits in the path. What follows examines what cloud rendering actually does, where rendering can happen instead, and what has to be true of the alternative for the protection to hold. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Remote browser isolation executes page content in a browser running on the provider's infrastructure and sends the endpoint a representation of the result, in Cloudflare's design a stream of draw commands rather than page code (Cloudflare, 2025).
  • Moving rendering to a cloud service changes who operates the environment where real values are displayed, so the governance question is about custody of the rendered screen, not only about malware isolation (NIST, 2011).
  • Rendering can also happen in a governed environment the organization controls, including a secure virtual machine, where the screen is produced for a specific piece of work rather than for general browsing (NIST, 2020).
  • Protection does not require the rendered screen to carry real values. Values selected by policy can be swapped for consistent tokens at the moment of rendering, before a model reads the screen, so custody and content are separate decisions (RedactSure Research, 2026).
  • RedactSure's published design follows this pattern: supervised AI co-workers operate applications as rendered inside a governed environment, with customer-held keys and ciphertext the company states it cannot decrypt (RedactSure, 2026). Deployments are in pilot.

What does cloud browser rendering actually move, and what does it leave exposed?

Cloud browser rendering, usually sold as remote browser isolation, moves execution. The page's code, including JavaScript and plugins, runs in a browser on the provider's servers, and the user's device receives a visual representation of the outcome (Cloudflare, 2025). Cloudflare's documentation describes its variant as sending the endpoint commands for how to draw the final page, so active content is never executed locally (Cloudflare, 2025). The security logic is sound: code that never runs on the laptop cannot exploit the laptop, and a session can be discarded when the tab closes.

What the design does not change is the content of the screen. The remote browser still assembles the real record: the real name, the real account number, the real balance. Those values exist in rendered form inside the provider's environment, are encoded into the stream sent to the endpoint, and are displayed in full to whoever holds the session. Isolation answers the question of where code executes. It does not answer the question of who or what reads the values on the screen, because in a cloud-rendered session the values are present at every stage, in the provider's browser, in transit as drawing instructions, and on the endpoint display.

This distinction matters more now that the reader of a screen is often a model rather than a person. A human employee is authorized to see the record in front of them. An AI agent acting on that screen is a new reader with a different risk profile, because everything in its context can be copied, logged, or extracted by a manipulated instruction placed in the content it reads (Greshake et al., 2023). Cloud rendering was designed before that reader existed, and its documentation frames the benefit in terms of protecting the device from the page (Cloudflare, 2025). Protecting the data from the reader is a separate problem that rendering location alone does not solve.

Where can rendering happen instead of a provider's cloud?

There are three realistic placements. The first is the endpoint itself, an ordinary local browser, which is where most work happens today and where no isolation or substitution occurs unless other controls are added. The second is a provider's cloud, the remote isolation model described above. The third is an environment the organization governs directly: a virtual machine or isolated session under the organization's own administration, keys, and retention rules, dedicated to a defined piece of work.

NIST's cloud guidance makes the underlying point that placement is a custody decision. When a function moves to a service operated by someone else, the organization delegates part of its control over the environment and must govern through contract and configuration rather than directly (NIST, 2011). NIST's definition of cloud computing describes the same arrangement from the other side: in each cloud service model the consumer does not manage or control the underlying infrastructure (NIST, 2011). The zero trust architecture publication adds that access decisions should be made per session, close to the resource, based on policy rather than network location (NIST, 2020). A governed rendering environment is an application of that idea to screens: the session is created for one task, policy is applied to it before work begins, and the session ends when the work ends.

The governed option differs from classic virtual desktop infrastructure in scope. A virtual desktop reproduces a whole working environment for a person, indefinitely. A governed rendering session exists for a workflow: these applications, this record set, these permitted actions. That narrower scope is what makes it practical to apply data policy to the screen itself, because the session knows which task it is serving and can be configured for that task alone.

Placement also decides the failure modes an organization accepts. A provider cloud introduces dependence on that provider's availability, data handling, and regional footprint. A self-governed environment concentrates responsibility internally: patching, capacity, and monitoring belong to the organization or to the vendor operating the environment under its control. Neither is automatically safer. The question is which custody arrangement matches the sensitivity of what appears on the screen.

What must happen at the render layer for the alternative to protect values?

Keeping rendering out of a public cloud service protects data only if something also changes on the screen. If a governed session renders real values and hands them to a model, the organization has reproduced the exposure of ordinary browsing inside a more expensive box. The protective step is substitution at the render layer: as each screen is produced, values that policy marks as sensitive are replaced with consistent tokens before the screen reaches the model.

Consistency is the property that makes this workable rather than merely cautious. When the same account number appears on four screens as the same token, ACCT_001, an agent can match, compare, and carry the reference through the task. When each appearance produced a different placeholder, the agent would treat one customer as four and the workflow would fail. The token carries identity without carrying content, so reasoning about relationships between values remains possible while the values themselves stay in the source application.

Policy has to decide which values are substituted, and that decision needs an owner. In RedactSure's published design, a component it calls the Planner sets which values are tokenized for each screen and what the agent may do there, and an identified person confirms that policy before a run starts. The same design states that real values are revealed only at approved destinations, at the moment an approved action needs them, so resolution is an event with a destination and a reason, not a standing permission.

Encryption supports the arrangement but does not replace it. In the same published design, work runs with customer-held keys and the vendor holds ciphertext it states it cannot decrypt. That addresses custody of stored and transmitted material. It would not, by itself, stop a model from reading a decrypted value on a screen, which is why the substitution step, not the encryption step, is the one that protects data from the reader.

How does governed rendering handle applications the organization does not own?

Much of the sensitive work in an enterprise happens in applications the organization cannot modify: a payer portal, a banking platform, a vendor's case system, a government site. Controls that require an integration, an API, or a code change in the target application do not reach these systems. A rendering-based approach reaches them by construction, because it works with the application as presented, the same rendered interface a person would use.

RedactSure describes its co-workers in exactly those terms: they complete browser workflows across an organization's existing applications, worked as rendered, with no per-application integration and no change to user permissions. The significance for the rendering question is that protection travels with the session rather than with the application. The organization does not need the portal's owner to cooperate, to expose an interface, or to accept a plug-in, because the substitution happens on the organization's side of the glass, in the session it governs.

The limits are real. An application that detects automation may refuse the session. An interface built from scanned images or unusual controls may render values in forms that detection handles poorly, so substitution coverage depends on how values appear on screen. And a session that works as rendered inherits the application's own availability and behavior, including slow pages and unexpected layout changes. Governed rendering widens the set of applications a data control can cover. It does not make those applications more cooperative than they are.

What are the honest tradeoffs of keeping rendering out of a public cloud service?

Design Where the screen is produced Who operates that environment What the model receives
Ordinary local browsing The user's device The organization, through endpoint management Whatever the screen shows, in full
Cloud browser rendering The isolation provider's cloud The provider, under contract The full rendered record, unless separate controls intervene
Governed rendering with tokenization A controlled virtual environment The organization or its vendor under the organization's keys Tokens in place of policy-chosen values
API-based automation No screen is produced The application's owner, through its interface Structured data the interface returns

The first tradeoff is operational weight. Cloud isolation is a mature, scaled service; a governed environment must be provisioned, patched, and monitored, and its capacity rises and falls with the work given to it. The second tradeoff is coverage shape. Cloud rendering typically applies to browsing generally, while a governed session is usually scoped to defined workflows, which leaves ordinary browsing outside it. The third tradeoff is where trust concentrates. Cloud rendering asks the organization to trust a provider with the rendered content of everything isolated. Governed rendering asks it to trust its own configuration, its keys, and the discipline of its policy owners.

Performance belongs in the tradeoff list as well. Streaming a rendered interface adds a hop compared with a local browser, in both cloud and governed designs, and the size of that cost depends on distance, session design, and the application. Neither design should be adopted on a vendor's assurance about responsiveness; both should be measured on the organization's own workflows, because no comparative primary-source benchmark between the two designs was found.

How should an organization choose between the two designs?

Start by separating the two risks that are often merged in procurement discussions. If the dominant worry is hostile web content reaching endpoints, isolation is the control that addresses it, and its location in a provider cloud is a reasonable price. If the dominant worry is sensitive values reaching readers who should not hold them, including AI models, then the deciding feature is not where rendering happens but whether values are substituted before they are read, and by whom the rendering environment is governed.

Three questions sort most cases. First, whose environment will hold the rendered record, and under whose keys? Second, does the design change what appears on the screen for a model reader, or only where the page executes? Third, can the design cover the applications where the sensitive work actually happens, including the ones the organization does not own? A design that answers all three in the organization's favor protects data without cloud rendering. A design that answers only the first leaves the newer, model-shaped exposure untouched.

For many organizations the honest answer is layered: isolation for general browsing risk, governed and tokenized sessions for the narrower set of workflows where agents handle sensitive records. The two designs are not enemies. They solve different problems that happen to share a browser.

Where does RedactSure sit?

RedactSure's design answers both the custody question and the content question for agent workflows involving sensitive data. The work runs in a governed secure environment, a virtual machine deployed into the cloud the customer's posture requires, under customer-held keys, with ciphertext RedactSure itself cannot decrypt, so custody of the underlying values does not pass to an outside rendering service. Policy-chosen values are replaced with consistent tokens at the render layer before a model reads the screen, so the screen an agent actually receives does not contain those values in readable form even though the source application itself is unchanged. The model is handed the task's fields with identifiers as tokens, and real values resolve only at approved destinations at the moment of an approved action.

The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy before the run and approves every payment, submission and record change while it runs, under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM. No per-application integration is required and user permissions do not change. The environment is model agnostic. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on vendor documentation for remote browser isolation, principally Cloudflare's published description of how its Browser Isolation service executes and renders content (Cloudflare One documentation, 2025; vendor documentation), and on NIST publications covering cloud custody and zero trust session design: SP 800-145 and SP 800-144 (2011) and SP 800-207 (2020), all official guidance. Greshake et al. (arXiv:2302.12173, 2023; preprint) is cited for the finding that instructions placed in content a model reads can redirect it. All sources were read as of October 13, 2026. RedactSure's design is described only in terms the company itself publishes: governed environment, render-layer substitution, customer-held keys, human approval of consequential actions, and pilot status.

No rendering environment was tested, no latency or throughput figures are reported, and no comparative benchmark between cloud-rendered and governed-rendered sessions was found in the primary sources consulted, so none is claimed. No hands-on testing of Cloudflare Browser Isolation or any other named product was performed; what each product does is taken from its documentation. Product documentation describes intended behavior; it is not independent verification of any implementation. Vendor features change, and the page carries its date and is revised when the documentation changes. The payer portal, banking platform and case system examples describe application types, not any organization; no customer or prospect is described.

Whether a cloud-rendered, governed or layered design meets an organization's requirements for a given workflow belongs to its counsel, its assessor and its own security and compliance officers, who hold the facts about the records, the applications and the risk tolerance involved. The sources above inform that determination; they do not make it.

What the record shows

Cloud browser rendering protects endpoints from web content, and it does that job by moving execution into a provider's environment, where the full record is still assembled and displayed. Protecting sensitive data is a different task, and it can be done without that move: the design that answers both the custody question and the content question keeps rendering in an environment the organization governs and replaces policy-chosen values with consistent tokens before a model reads the screen. A design that moves rendering without changing the screen leaves every value readable by every reader of the session, including an AI agent. Judge the two designs in that order: first who operates the environment and holds the keys, then what the screen contains when an agent reads it.

Frequently asked questions

Does avoiding cloud rendering mean giving up isolation altogether?

No. Isolation describes separating execution from the endpoint, and that separation can be provided by a governed virtual environment as well as by a provider's cloud. What changes is who operates the environment and under whose keys and retention rules it runs. The protective step for sensitive data is separate from isolation in both designs: values still need to be substituted at the render layer before a model reads the screen, or the isolated session will display the full record in a safer room.

Is a governed rendering environment the same thing as a virtual desktop?

They share machinery and differ in scope. A virtual desktop reproduces a person's whole working environment, usually for general use over a long period. A governed rendering session is created for a defined workflow, with policy set for that task: which values are tokenized on each screen and which actions are permitted. That narrower scope is what allows data policy to be applied to the screen itself, and the session ends when the work ends rather than persisting as a general-purpose desktop.

What happens to a real value when a task actually needs it?

In RedactSure's published design, the value is resolved only at an approved destination, at the moment an approved action requires it. The model works with the token throughout its reasoning, and the substitution is reversed only where the value must be entered or submitted, under the run's approval rules. A named person approves consequential actions such as payments, submissions, and record changes as they happen, so resolution is a supervised event rather than a standing capability the agent carries.

Does cloud browser rendering hide sensitive data from an AI agent?

No. Remote browser isolation moves where page code executes; it does not change what the rendered page contains. The provider's browser assembles the real record, encodes it into the stream sent to the endpoint, and displays it in full to whoever holds the session. An AI agent reading that session receives every value on the screen unless a separate control substitutes tokens before the model reads it. Isolation protects the device from the page, not the data from the reader.

Can governed rendering cover applications the organization does not own?

Yes, because it works with the application as presented, the same rendered interface a person would use, and the substitution happens in the session the organization governs rather than inside the application. No integration, API or code change in a payer portal, banking platform or government site is needed. The limits are the application's own: automation detection may refuse the session, and values rendered as images or unusual controls may be detected less reliably.

Is governed rendering slower than cloud browser isolation?

No comparative benchmark between the two designs was found in primary sources, so no figure is claimed. Both stream a rendered interface and so add a hop compared with a local browser; the size of that cost depends on distance, session design and the application. The reliable approach is to measure both on the organization's own workflows rather than accept any vendor's assurance about responsiveness, and to scope the governed session to the workflows where it is needed.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.