Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Run Browser Use on Customer Records?
No, not on a live customer queue: Browser Use's sensitive-data page leaves the page text and, with vision on, a screenshot in front of the model, and its filter covers only values you pass in. Ask what the model receives from a rendered screen before an agent reads a real record.
A support queue is where customer records collect: names, email addresses, order numbers, partial card numbers, dates of birth, and the free-text message that explains the problem. Point a browser agent at the queue and it reads the list, the ticket and the account page. Every step draws a page, and every page reaches the model that chooses the next click. Browser Use's sensitive-data example is candid: "the LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text", and the same page advises to "set use_vision=False to prevent screenshot leaks", which concedes a second channel into the model (Browser Use, 2026). The filter covers values you register; a customer's name, address and date of birth are not on it until someone adds them.
A wrong reply is the smallest part of what is at stake. A queue that carries a name, an address and a date of birth identifies a person, and a run that read two hundred tickets holds the whole queue; the customer's own message is text an outsider can write. McKinsey's State of AI research finds 62% of organizations at least experimenting with AI agents and 23% scaling them anywhere (What Is the PII Wall?).
Key findings
- For Browser Use to be safe on a live support queue, the values on each customer record would have to be replaced with consistent tokens before the model reads the screen, so the agent works CUST_014 and ACCT_014 and real fields resolve only at an approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each reply, refund and status change, and a record of the page the model received, because "human oversight breaks under scale" once one person clears a queue (DAPLab, 2026).
- Browser Use's published documentation does not state that values on a customer record are replaced before the model reads them; its sensitive-data page describes placeholders for values you pass in and a switch that turns screenshots off (Browser Use, 2026).
- The same page states that "the LLM only sees placeholders (x_user, x_pass)", a filter that covers the values you hand the agent and not the name, address and date of birth a queue renders, and it advises to "set use_vision=False to prevent screenshot leaks", which names the screenshot as a path to the model and leaves the page text in front of it (Browser Use, 2026).
- Brave's researchers showed that an attacker can "hide prompt injection instructions in images using a faint light blue text" that a screenshot-reading agent acts on, so an attachment is an input channel (Sahib and Chaikin, 2025).
What does Browser Use read when it opens a support queue?
The record for this page is a support queue. The list view carries a name, an email address, an order number and a partial card number. The detail view carries the customer's message above the fields an agent updates: address, date of birth and account status. FINRA's comparison of the two account-record rules lists "Date of Birth, for an individual" and a tax identification number among the fields a record holds (FINRA, 2026).
A Browser Use task opens that list, reads the detail page and drafts a reply. The model reads the page the browser renders: the list rows, the field values, the customer's message and any attachment. Browser Use's page is explicit that the filter applies to values you pass in: "real values are injected directly into form fields after the LLM call" (Browser Use, 2026). That keeps a typed password out of the model and leaves the customer's record as page text.
Those placeholders stop at the login. In a review of 15 AI agents, Browser Use is the one that offers them, for credentials only, while 9 describe keeping passwords or credentials away from the model and 0 describe a token standing in for the customer data on the page (Do AI Agents Ask Before Making a Payment?).
Tokenization draws that difference: a surrogate value carries no exploitable meaning on its own while the real value sits in a separate store, the pattern the payments industry built to shrink the scope of systems that handle card numbers (How Can AI Agents Work With Customer Records Without Seeing the Actual Data?). Browser Use's page describes no equivalent for a record it is reading.
What does the model receive from a customer record it reads?
A Browser Use task perceives the page twice: as text and, while vision is on, as a screenshot. The screenshot carries whatever the page draws, including an image a customer attached to the ticket.
Brave's researchers showed that an attacker can "hide prompt injection instructions in images using a faint light blue text" that screenshot-reading agents act on (Sahib and Chaikin, 2025). A queue that accepts attachments accepts a page an outsider can write. The page text is not the only channel. A study of vision language models in oncology found that they "can be compromised by prompt injection attacks", with prompts embedded in images that are "non-obvious to human observers" (Clusmann et al., 2024). The study tested four closed medical models, not enterprise agents.
The three conditions that make an injection pay are present at once: private data on the page, untrusted text in the customer's message and attachment, and an outbound path through the reply or a URL the agent can open (Is It Safe to Let AI Agents Read External Web Pages?). A simple injection asking an agent to leak what it saw reached an average attack success rate around 20 percent in a University of Zurich study (Does Prompt Injection Expose Customer Records?).
What do the vendors themselves say?
The vendor pages answer different halves. Browser Use documents what its model receives and which controls it offers; Google and Coder document the account an agent signs in with, and none describes an approval step on a customer record.
Browser Use's sensitive-data example gives the model less than the page holds: "The LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text" (Browser Use, 2026). The filter covers values you pass in, so a customer field is covered only if someone listed it. The same page turns screenshots off with "set use_vision=False", which handles the image channel and leaves the text open, and restricts navigation with "Use Browser(allowed_domains=[...]) to restrict navigation", a limit on where the agent goes, not on what a permitted page shows (Browser Use, 2026).
Google's guidance says to "use the super admin account only when needed", which limits which account opens the queue and says nothing about what a page shows (Google, 2026). Coder's guidance states that "LLMs and agents can be dangerous if not run with proper boundaries" and asks for separate identities with limited scope, which limits what an agent may reach and leaves what it reads unaddressed (Coder, 2026).
| Dimension | Browser Use, per its documentation | What a buyer should verify |
|---|---|---|
| What the model receives | "The LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text" | Which fields count as sensitive, and whether the record's are |
| Screenshots | "Set use_vision=False to prevent screenshot leaks" | Whether vision is off, and what text still reaches the model |
| Values the agent types | "Real values are injected directly into form fields after the LLM call" | Which values are injected, and what the page shows after |
| Approval and record | Not described in the pages reviewed | Who approves a change, and what record exports |
The table separates a value the agent types from a value the page renders; the exposure is in the second.
Who approves a change to a customer record, and what record shows it?
The documented human step in a Browser Use run is a fill, not an approval. The model decides to type, and the value is injected after the model call, a control on what the model holds and not on what the run does (Browser Use, 2026). Nothing describes a person confirming a reply, refund or status change before it lands.
Coder's guidance asks for "separate identities with limited scope whenever interacting autonomously" and warns that agents "can be dangerous if not run with proper boundaries", which limits what an agent may reach and leaves what it reads unaddressed (Coder, 2026). Google's guidance says to "use the super admin account only when needed", a rule about which account opens the queue, not what the page shows (Google, 2026).
A person can be the approver and still not be the control. A systematic review of automation bias describes it as "the tendency to over-rely on automation", which is what an approval step becomes at two hundred tickets a morning (Goddard et al., 2012). An approval that carries weight names the person and lands in a record that exports. The Cloud Security Alliance's AI Controls Matrix sets out "243 control objectives across 18 domains", a catalogue to check controls against (Cloud Security Alliance, 2025).
The record has to carry the screen as well as the action. A security analysis of browsing agents reports that "our findings include prompt injection, domain validation bypass, and credential exfiltration", the steps an attack chains before data leaves the page (Can a Browser Agent Be Tricked Into Pasting Sensitive Data Into a Chat?).
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. Values chosen by policy are replaced with consistent tokens for the whole run, so a queue shows CUST_014, MAIL_014 and DOB_014. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each refund, reply and record change, and every screen as tokens, every action and every approval lands in a record that exports to the organization's monitoring.
For a support queue it changes what a run leaves behind. A transcript of two hundred tickets that holds tokens is a record of work; one that holds names and dates of birth is a copy of the customer base. It also changes the approval: the person sees the change against the tokenized page, not a summary the model wrote.
Its scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a queue worked through an API is outside it. A lab that studies agent infrastructure concludes that "trustworthy agent automation cannot be solved at a single layer of the stack", which is the argument for a control where the page is drawn (DAPLab, 2026). The comparison with the open-source agent is in (RedactSure vs Browser Use: 2026 Comparison & Alternative).
What the record shows
A queue is only as safe as the control over three things: what the model receives from the rendered page, who approves a change to the record, and what record survives the run. The vendor pages describe placeholders for values passed in as sensitive, a vision switch and domain allowlists, and they do not state that a record's fields are replaced before the model reads them or that a person approves a reply, refund or status change. For a support queue the answer is specific: a stripped export is workable, the live queue is not. A team can settle it on one ticket: open a test record with a marked field, run the task, and compare what the model received with what the screen showed.
Methodology and limitations
This page rests on Browser Use's open-source documentation, Google's and Coder's guidance for administrator and agent accounts, a FINRA comparison of two account-record rules, the Cloud Security Alliance's AI Controls Matrix, a lab page from Columbia's Data, Agents, and Processes Lab, a systematic review of automation bias, an imaging study of vision language models and existing RedactSure pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it. The products are described from their public documentation, and vendor features change. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a support queue, and not an organization. FINRA's comparison is dated September 2003 and contains brief summaries, so its field list is not current rule text. Which values are replaced on a rendered page, who approves a write and what record is exported are not described in the pages reviewed.
Frequently asked questions
Is it safe to run Browser Use on customer records?
No, not on a live queue of real customer records. Browser Use's sensitive-data page describes placeholders for the values you pass in as sensitive and a vision switch for screenshots, and the page text still reaches the model, so a customer's name, address and date of birth are read as ordinary text (Browser Use, 2026). A queue stripped of those fields changes the answer. Run one test ticket first and read what the model received before a real record goes near it.
What does the model receive from a customer page?
The page as the browser draws it: the list rows, the field values on the detail view, the customer's message and, while vision is on, a screenshot. Browser Use documents a placeholder filter for values you register and a switch that turns screenshots off, and no step that replaces the record's fields before the model reads them. Treat every field on the page as read.
Does turning off vision make a customer record safe to read?
It closes one channel and leaves the other. The page advises setting use_vision=False to prevent screenshot leaks, which removes the image and says nothing about the text the agent reads to choose its next click (Browser Use, 2026). A message a customer typed still arrives as text, and an instruction inside it still reaches the model. Vision off is a useful setting and not an answer to the record question.
Who approves a reply, a refund or a status change?
No one that the documentation names. The documented human step in the run is a fill: the model decides, and the value is injected into the form. A reply, a refund or a status change lands under the account the agent signed in with, which is usually a person's login. An approval that means something names the approver, shows the change and the page the model read, and lands in a record that exports.
What record shows what the model read?
The application's own audit entry, and that is the gap. A CRM records the field change under the account the agent used, with a timestamp and the old and new value. It does not record the page the model received, the instruction in a customer's message or the screenshot the model acted on. A queue needs the screen as the model saw it, the action taken and the name of whoever approved, exported to the team's own monitoring.
Can an agent work a stripped customer export?
Yes, when the identifying fields are gone before the run. A list of ticket numbers, dates, order numbers and product names gives an agent work without a customer attached, and the exposure here turns on values that identify a person. A name, an address or a date of birth is an identity, and a case number is not. Strip those fields, run the export against a test queue, and keep the live queue out of the session.
How RedactSure Keeps Customer Records Out of the Model's Context
An agent that reads a customer's name and date of birth has already taken the record, and controls on where data goes leave that step alone. Browser Use's own page advises to "set use_vision=False to prevent screenshot leaks", which closes one channel and leaves the page text open.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the model receives the customer's name, address and date of birth as it drafts a reply. Inside: the queue shows CUST_014, MAIL_014 and DOB_014, and the support lead approves the status change before the real values resolve.
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 queue that renders as tokens leaves a work record instead of a customer list. Bring one ticket and see, with test values, what the model receives, who approves the change and what lands in the record. Book a demo