Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Dia Browser Safe to Use for Work?
No, not on work accounts whose pages carry customer or health data: Dia's own page says it "sends your prompt and the relevant page content to a third-party AI model" and excludes PHI work. It becomes workable when values are replaced on the rendered screen before the model reads them, a named person approves, and a record exists.
A product manager opens her analytics dashboard in Dia, asks for the three accounts most at risk this quarter, and gets a paragraph naming customers, renewal dates and revenue. Dia's security page says the prompt and "the relevant page content" go to a third-party AI model, and the same page says the browser "should not be used for work that involves PHI or other data you're obligated to protect under a law like HIPAA."
The mitigations the page lists are narrower. Password fields and irreversible action buttons are invisible to the agentic system, which stops an agent from typing a password or pressing a button the page treats as irreversible. The account names, IDs and contract values in a dashboard's tables and cards are neither, so they render as text and reach the model the way any other text does (Does an AI Agent See Everything on Your Screen?). The useful question is what one screen sends, who approves an action built on it, and what record survives the run, because those answers decide whether a dashboard task is a small convenience or an exposure the organization cannot measure.
Key findings
- For Dia to be safe on a work account, the values on the dashboard would have to be replaced with consistent tokens such as CUST_001 before the model reads the rendered page, with real values resolving only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving every submission or record change the agent proposes, and a record of what the model received on each screen (RedactSure vs Dia: 2026 Comparison & Alternative).
- Dia's page describes two field classes its agent cannot see and a 30-day retention period, and it does not describe replacing the values on a page before the model reads them (The Browser Company, 2026).
- It states that Dia "sends your prompt and the relevant page content to a third-party AI model," which makes the rendered dashboard the model's input (The Browser Company, 2026).
- Dia states that "Web form fields like passwords and irreversible action buttons are invisible to the agentic system," a limit on two field classes, not on the names and contract values the rest of the page renders (The Browser Company, 2026).
- Harvard's guidance states that "the riskiest agent setup combines three things: access to private data, exposure to untrusted content, and the ability to send data outward," the combination a dashboard task creates in a browsing agent (Harvard, 2026).
What does Dia's agent receive from the analytics dashboard?
The record for this page is one dashboard and one request. A product manager opens the renewal pipeline, which lists account names, account IDs, annual contract values and a short churn note for each customer, and asks Dia to summarize the three accounts most at risk. Dia's security page states that it "sends your prompt and the relevant page content to a third-party AI model," so the page's content travels with the question (The Browser Company, 2026). The model receives the names, the IDs, the contract values and the note.
Nothing on the dashboard is a password field or an action button, so the two controls the vendor advertises have no purchase here. What reaches the model is the render: the table's text, the card labels, the note the account team typed. The AgentDAM benchmark found that web agents "are prone to inadvertent use of unnecessary sensitive information," and a summary of three accounts does not need every contract value on the page (Zharmagambetov et al., 2025).
The question is then practical: what the page shows, what the model received, and whether the two sets differ. On Dia as documented they do not, because the page content is the model's input (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?).
Does hiding password fields keep the dashboard out of the model?
A field-hiding rule is a control on what the agent may type or press, and a dashboard's values are display text. Dia's page states that "Web form fields like passwords and irreversible action buttons are invisible to the agentic system," which covers two input classes and says nothing about the customer names, IDs and contract values a page prints (The Browser Company, 2026).
A review of 15 AI agents places Dia among the 9 that document keeping passwords or credentials away from the model, with 0 of the 15 documenting the same for the customer data a page shows (Do AI Agents Ask Before Making a Payment?).
The page's own exclusion points the same way. It says Dia "should not be used for work that involves PHI or other data you're obligated to protect under a law like HIPAA," which draws a line around a category of work rather than describing a filter on what the model reads (The Browser Company, 2026). A PHI record displayed in a portal's table is not a password field, and hiding password fields would leave it on the screen.
A login control that injects a credential only "if, and only if, the human approves the access" is a boundary at the password field, and the password field is the one the vendor already hides (Is It Safe to Let a Browser Agent Use My Saved Logins?). It does not follow that the page behind the login is covered. Columbia's DAPLab states that "trustworthy agent automation cannot be solved at a single layer of the stack," and field hiding is one layer at the input edge (Columbia, 2026). The check for a team is narrow: name one value the field hiding does not cover, such as a customer name in a table, and ask whether anything stops it from reaching the model.
What do the vendors themselves say?
Dia's security page is the primary record: "Dia sends your prompt and the relevant page content to a third-party AI model," "Web form fields like passwords and irreversible action buttons are invisible to the agentic system," content "isn't tied to your account, is retained for 30 days, and then deleted," and Dia "should not be used for work that involves PHI or other data you're obligated to protect under a law like HIPAA" (The Browser Company, 2026).
| Dimension | Dia, per its security page | What a buyer should verify |
|---|---|---|
| What the model receives | "Dia sends your prompt and the relevant page content to a third-party AI model" | Which fields on one screen reach the model |
| The field classes it hides | "Web form fields like passwords and irreversible action buttons are invisible to the agentic system" | Whether the work values are form fields or rendered text |
| Work it excludes | "should not be used for work that involves PHI or other data you're obligated to protect under a law like HIPAA" | Whether the account falls under that description |
| Injection posture | Assumes "prompt injections may occur" and relies on "layered controls" | What a successful injection can collect from the open tab |
The pattern is a boundary around inputs and retention. A per-run record an employer can export is not described in the pages reviewed, and the vendor's exclusion of PHI work is the plainest statement that some accounts are out of scope.
Coder's guidance for running agents is the other vendor document this page reads, and it addresses authority rather than content: teams should "be sure not to give agents full permissions on behalf of a user" and should give agents "separate identities with limited scope" (Coder, 2026). The advice is written for coding agents, and for a browser agent it decides which accounts are in reach, not what a page shows once the agent is inside.
What happens when a dashboard page carries an injected instruction?
Dia's security page says it assumes "prompt injections may occur" and that it keeps users safe "through layered controls" (The Browser Company, 2026). Layers that decide which sites open shape what the agent may do, not what the model reads. OWASP's Top 10 for Agentic Applications for 2026 is a peer-reviewed framework of the most critical risks for autonomous systems, and a browser agent that reads a work page sits inside it (OWASP, 2026).
A study of permissive information-flow labels found that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). OWASP catalogues a related attack in which an adversary "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations," so an approval step is only as good as what the person is shown (OWASP, HITL Dialog Forging, 2025).
A firewall study cautions that "existing agentic security benchmarks are easily saturated by a simple approach," which makes a clean score a statement about the test (Bhagwatkar et al., 2026). Harvard's guidance asks teams to "require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible," a rule about authority rather than the page (Harvard, 2026).
An injection that lands then collects what the model already read: the names, IDs and contract values on the page. A paste into a chat window is one way that content leaves (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 dashboard renders as CUST_001 and ACCT_001, with AMT_001 for contract values a summary does not need. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the policy and approves each submission or record change, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
The renewal table the model reads contains tokens, so a summary written from it carries tokens into the transcript and any file the agent produces. A churn note, including any instruction hidden in it, sits in a context of tokens, so a successful injection collects placeholders rather than account names. The submission waits for a named person, and the record states what the model received and who approved the action.
Adoption is running ahead of control: the PII Wall page records that 62% of organizations are at least experimenting with AI agents and 23% are scaling them anywhere, and the gap between those numbers is where a screen-level control matters (What Is the PII Wall?). For the vendor on this page, the two designs are set side by side on the same dimensions in RedactSure vs Dia: 2026 Comparison & Alternative. The control's scope is the rendered page; a file read in a repository, a shell command and a direct API call are governed elsewhere.
What the record shows
A screen is read whole unless its values are replaced with consistent tokens before any model reads the rendered screen, and the dashboard's account names, IDs and contract values are exactly the values a summary does not need. The vendor's security page records what the model receives, which work it excludes, how long content is retained and how local deletion works; it records no approver role and no per-run record a team can export. That answers the title for a work account: the browser governs what its agent types, not what its model reads. A team can test one dashboard task by naming the screen, running the summary once, comparing the request with the content that reached the model, and asking who could produce that comparison for an auditor after the run.
Methodology and limitations
This page rests on The Browser Company's Dia security page, Coder's guidance for running agents, two OWASP resources, Harvard's generative AI guidance, Columbia's DAPLab page, three research papers 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 21, 2026, and each Sources line carries the date for its page.
The products on this page are described from their public documentation, and none was tested for this page; RedactSure is deploying now with enterprise and government customers. Where the pages reviewed are silent on a behavior, this page reports the silence rather than inferring a capability. Vendor features change, and the page carries its date. The example describes a record type, an analytics dashboard at a product team, not an organization. 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 Dia Browser safe to use for work?
No, not on work accounts whose pages carry sensitive data. The security page says Dia "sends your prompt and the relevant page content to a third-party AI model" and that it "should not be used for work that involves PHI or other data you're obligated to protect under a law like HIPAA." The answer changes when the values are replaced before the model reads the screen.
What does Dia's agent read on an analytics dashboard?
It reads the rendered page, minus the two field classes the vendor hides. A dashboard's table, cards and notes are ordinary page content, and the security page says that content goes to a third-party model with the prompt. Filtering by field type does not apply, because none of those values sits in a password field or behind an irreversible button. A request for three at-risk accounts can therefore put every customer name and contract value on the screen into the model's context.
Does hiding password fields keep the rest of the screen out of the model?
No. The hiding covers password fields and irreversible action buttons, both controls on what the agent may type or press. A dashboard's account names, IDs and contract values are display text, so they render to the model whether or not a password field elsewhere on the site is hidden. The limit is the field class, not the screen, and hiding one kind of input leaves the rest of the page as it was.
Who approves an action Dia's agent proposes?
No approver role is described. The security page says irreversible action buttons are invisible to the agentic system, which limits what the agent can press, and it says the browser assumes "prompt injections may occur" and relies on "layered controls." A limit on buttons is not a named person reviewing a submission. The guidance reviewed here asks for "human approval for high-impact, sensitive, irreversible, or externally visible actions" before they run (Harvard, 2026).
What record does Dia leave of what its agent read?
It leaves a retention and deletion policy, not a run record an employer can hold. The security page says content data "isn't tied to your account, is retained for 30 days, and then deleted," and that clearing local chats, files or history removes them from the device. Thirty days of vendor-side retention answers a different question from what the model received on one screen and who approved the action that followed.
What should a security team verify before allowing Dia on a work account?
Start with one screen and one task. Ask what the model receives from that screen, field by field, whether the values can be replaced before the model reads it, who approves a submission built on the page, and what record survives the run. Then run the task and compare the answer with the screen. A vendor page that documents field hiding and a retention period answers none of the four.
How RedactSure Keeps a Dashboard's Customer Values Out of the Model
A summary task reads every account on the dashboard, and hiding password fields in the browser does nothing to the values that render as text. Dia's own page records that the prompt and "the relevant page content" go to a third-party model.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the model receives the dashboard as drawn, with customer names, account IDs and contract values in the text it reads. Inside the governed environment: those values are replaced with tokens on the rendered screen, so the agent works from CUST_001 and ACCT_001, and the real values resolve only at the destination a named person approved.
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 dashboard that renders customer names and contract values to an agent puts both in the model's context for the rest of the run. Bring one dashboard task and see, with test values, what the model reads and who approves the submission. Book a demo