Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Run Skyvern on Customer Records?
No, not on a live support queue: Skyvern's documentation says a typed value can still "show up in later screenshots and page text," and Mask Secrets hides it there only when someone turns the setting on. Run a queue of synthetic records, or replace the values a record renders with tokens before the model reads the page.
A support team that hands its ticket queue to a browser agent is handing over a customer list: names, email addresses, order numbers, partial card numbers, dates of birth and the free-text message that explains the problem. Skyvern's model reads the list, the ticket and the account page as the browser draws them. The credentials page names the channel: a typed value can still "show up in later screenshots and page text," and Mask Secrets is a setting an operator turns on to hide it there (Skyvern, 2026). A customer's name and date of birth are not credentials Skyvern stores, so no placeholder stands in for them, and nothing on the page replaces them before the model reads the record. That distinction sets the answer for a given queue: a synthetic one, seeded with test values, is workable, and a live one is not safe to run as shipped. What is at stake is a transcript that is a copy of the customer base. Customers are already wary: according to Pew Research Center, "more adults in the US think AI will have a negative impact on them personally, and on society in general" (MIT Technology Review, Hate, 2026).
Key findings
- For Skyvern to be safe on a live support queue, the values a customer record renders would have to be replaced with consistent tokens before the model reads the screen, so a name and a card number reach the agent as CUST_014 and CARD_001 (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, exported to the team's own monitoring (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
- Skyvern's published documentation does not state that the values a customer record renders are replaced before the model reads them; its page describes placeholders for saved logins and a Mask Secrets switch (Skyvern, 2026).
- Skyvern's page states that "The model that drives the browser gets placeholders, not your values," which covers a login the product stores and not the record a queue draws (Skyvern, 2026).
- The same page warns that "A typed value can still show up in later screenshots and page text," so a record arrives by screenshot and by text, and the switch is set per agent (Skyvern, 2026).
- A University of Zurich study found that injections asking an agent to leak personal data seen during a task reached "average attack success rates (ASR) around 20 percent" (Alizadeh et al., 2025).
What does Skyvern read when it opens a support queue?
One support queue is the record. The list view carries a name, an email address, a partial card number and a status; the detail view adds the message above the address, date of birth and account tier an agent updates. A Skyvern task opens the list, opens one ticket and drafts a reply, and the model chooses each next click from that page.
Skyvern's documentation says what the model sees of it: "A typed value can still show up in later screenshots and page text," so the model receives both the picture and the text of the record it works (Skyvern, 2026). The placeholder rule on the same page covers credentials, and a customer's address is not one, so it arrives as the page draws it.
Two things make that reading expensive. The first is volume: a run that reads two hundred tickets leaves a transcript that is a copy of the customer base. The second is the attack path, because private data on the page, text a customer wrote and a reply that leaves the building sit together on a queue (Is It Safe to Let AI Agents Read External Web Pages?). Masking is not a floor a buyer can assume: the survey of enterprise agents found data masking for LLMs currently disabled for agents (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?).
Does Mask Secrets cover the customer record, or only the login?
Mask Secrets is a switch in an agent's settings. The documentation's instruction is to "turn on Mask Secrets in an agent's settings to hide it there too," where "there" is the later screenshot and the page text a typed value would otherwise appear in (Skyvern, 2026). It covers the value an agent types, and a login is that value.
A customer's address is what the queue returns. Skyvern states that "Saved passwords, card numbers and secrets are never shown again," and that connected vaults are read at run time, two promises about the values the product keeps, not about a field another system renders (Skyvern, 2026). No store holds the address, so the switch has nothing to hide.
Skyvern was not among the products in the two reviews, which covered 15 AI agents and 86 AI security products; across that set, none describes, in its public documentation, replacing the customer data an agent reads on a screen with tokens it can work with (Do AI Agents Ask Before Making a Payment?; How Many AI Security Products Control What an AI Agent Sees?).
Arcade's description is that "Arcade holds the credential, makes the call, and returns only the result," which keeps a token out of the context and still hands the model the record the call returned (Arcade, 2026).
The model cannot be asked to protect the record by refusing either. "Because the mechanisms of refusal are probabilistic, they're never likely to be all that reliable" (MIT Technology Review, Say No, 2026), and a defender tests continuously for the same reason: according to Shi and colleagues at Google DeepMind, Google runs "a suite of adaptive attack techniques to run continuously against past, current, and future versions of Gemini" (Shi et al., 2025).
What do the vendors themselves say?
The credentials page answers a narrower question than the title asks.
Skyvern's page states that "The model that drives the browser gets placeholders, not your values," a placeholder for a login the product stores (Skyvern, 2026). The next sentence warns that "A typed value can still show up in later screenshots and page text," which names the channel and offers a setting rather than a policy over the record, and it adds that "Saved passwords, card numbers and secrets are never shown again," a promise about what Skyvern keeps (Skyvern, 2026).
| Dimension | Skyvern, per its documentation | What a buyer should verify |
|---|---|---|
| What the model receives | "The model that drives the browser gets placeholders, not your values" | Which values on the record were stored as credentials, and which the page renders |
| Screenshots and text | "A typed value can still show up in later screenshots and page text" | Whether an operator turned Mask Secrets on, and what it leaves visible |
| Approval | The page covers logins, not approvals | Who approves a reply, refund or status change |
| Record | The page describes no run record | What the run exports, and to whose monitoring |
The table separates a stored value from a rendered one: a customer's address is rendered, not stored, so the credential rows describe a control that runs past it.
Who approves a refund or a record change when the agent works the queue?
Skyvern's documentation describes credentials, logins and 2FA, and an approval step on a customer record is not described in the pages reviewed. That gap matters, because the action a queue most needs gated is the refund.
FINRA's 2026 oversight report flags that "AI agents acting autonomously without human validation and approval" and that "Agents may act beyond the user's actual or intended scope and authority" (FINRA, 2025). FINRA's 2026 oversight report also notes that "Complicated, multi-step agent reasoning tasks can make outcomes difficult to trace or explain, complicating auditability," which is the record problem a support queue inherits (FINRA, 2025).
Disclosure rules arrive first. When the queue holds student records, Education Department guidance states that "student information may only be disclosed to an online educational service company in compliance with FERPA," a rule about the disclosure and not about what the model reads (U.S. Department of Education, 2026).
A CRM announcement from October 2026 describes proposed field updates that are not saved automatically, and does not list which records or fields its skills read (How Do You Protect Customer Data When Dynamics 365 Copilot Agents Work CRM Records?). That is an approval of a kind, not a named approver on a support queue.
Does a queue of synthetic records make Skyvern safe to run?
Partly, and the part it covers is the customer data. Synthetic records carry invented names, addresses and card numbers, so a task that reads them all day leaves a transcript that identifies nobody. The vendor's controls then do the job they were built for, keeping the login to the ticketing system away from the model.
What a synthetic queue does not change is that login. The account on the test tenant is a real credential with real access, and the model still receives the page the test tenant draws. A test queue that reuses a production login, or one seeded from a production export, defeats the point. The test tenant is where a team can read the page as the model receives it, with invented values in every field.
The label on the data is the weak part. A test label describes the environment and not the data, so a copy of the queue that still identifies a person carries the same obligation (Does GDPR Apply When a Coding Agent Reads Customer Data in a Test Database?).
So the rule is a property of the fields rather than of the environment name: invented values are fine, a de-identified export is workable with review, and a copy that still names people is a live queue wearing a test label.
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 support queue shows CUST_014, MAIL_014 and DOB_014 where the record had a name, an address and a date of birth. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each reply, refund and status change, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
For this queue the change is what the run leaves behind. A transcript of two hundred tickets that holds tokens is a record of work; the same transcript with names and dates of birth is a copy of the customer base. The approval changes too, because the person sees the change against the tokenized page rather than a summary the model wrote.
Its scope is the rendered page only. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a queue worked through an API is outside it. The difference between a browser-side control and a render-layer one is drawn in (Enterprise Browser or Render-Layer Tokenization?).
What the record shows
Three things decide the answer for a support queue: what the model receives from the rendered record, who approves a change to it, and what record survives the run. The pages reviewed describe placeholders for stored logins, a setting that hides a typed value in later screenshots and page text, and vaults read at run time. They do not state that a record's fields are replaced before the model reads them, and they name no approval on a reply, a refund or a status change. The conclusion for this queue: a seeded queue of synthetic records is workable, a live one is not, and the difference is the identity in the fields. A marked field on one test ticket is enough: run the task, then set what the model received beside what the screen displayed.
Methodology and limitations
This page rests on a browser agent's documentation, a credential-custody vendor blog, two research preprints on prompt injection and data leakage, FINRA's 2026 oversight report, federal student-privacy guidance, two press analyses and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it, and each is described from its public documentation; vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization. An absence noted on this page means the pages reviewed do not describe the thing, not that a product cannot do it. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Is it safe to run Skyvern on customer records?
No, not on a live queue of real customer records. Skyvern's credentials page covers the login: the model gets placeholders for stored credentials, a typed value can still appear in later screenshots and page text, and Mask Secrets is a switch an operator turns on (Skyvern, 2026). A customer's name and address are not stored credentials, so no placeholder stands in for them. Seed a queue with test values before a real record goes near a task.
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 a screenshot while vision is on. Skyvern states that a typed value "can still show up in later screenshots and page text," the same path a record's fields take (Skyvern, 2026). Nothing distinguishes a typed value from one the application displayed, so treat every field as read. A screenshot is a picture of the same record, with the same values.
Does Mask Secrets make a customer record safe to read?
No. It hides a value the agent typed from later screenshots and page text, which is a real reduction for a login and no help for a name the queue renders (Skyvern, 2026). The setting is turned on per agent, and it says nothing about which fields on a record matter. Ask whether the record's values are replaced before the model reads the page. The record is the thing to protect, not the login.
Who approves a refund or a status change?
No one that the credentials page names. The documentation describes logins, 2FA and vaults, and a person approving a reply, refund or status change is not described in the pages reviewed. The application records the change under the account the task signed in with, usually a person's login, which names the seat rather than the approver. An approval that carries weight names the person, shows the page the model read and lands in a record that exports.
What record shows what the model read?
The application's audit log shows the change, the account and the timestamp, and it does not show the page the model received. FINRA's 2026 oversight report points at that gap when it notes that "Complicated, multi-step agent reasoning tasks can make outcomes difficult to trace or explain, complicating auditability" (FINRA, 2025). A record that answers the question carries the screen as tokens, the action taken and the name of the approver.
Can an agent work a queue of synthetic records?
Yes, when the names, addresses and card numbers are invented and the credentials are scoped to a test tenant. The exposure that makes a live queue unsafe is the identity in the fields, which a synthetic record lacks. The boundary is a real record pasted into a test ticket: a test label describes the environment and not the data, so one real customer in the export changes the answer.
How RedactSure Keeps Customer Records Out of the Model's View
An agent that reads a customer's name and address has already taken the record. Skyvern's page says a typed value can still "show up in later screenshots and page text," which is the channel a queue travels on.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the task opens the queue and the model reads the ticket's name, address and message, and the reply it writes carries all three. Inside, the queue renders CUST_014 and MAIL_014, the support lead approves the reply and the status change, and the real values reach the ticket at that approval.
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
The difference between a work record and a customer list is what the page shows the model. Bring one queue task and see, with test values, the page as the model receives it, the approval and the record. Book a demo