Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Dia Insert Data Into Third-Party Sites Without Your Approval?
No, not on work accounts whose pages carry sensitive data. Dia's page says it "won't insert data into third-party sites without your approval," and that it "sends your prompt and the relevant page content to a third-party AI model"; the approval gates the write, and the answer turns on values replaced before the model reads the page.
A supplier renewal form asks for a company name, a billing address, a tax number and the bank account for payment, and Dia can fill it from what the browser knows about the person signed in. The browser composes the values, shows them, and waits before writing them into the vendor's page. The Browser Company says Dia "sends your prompt and the relevant page content to a third-party AI model" (The Browser Company, 2026), and the same security page puts an approval in front of the insertion, the step where values leave the browser for someone else's site. The person decides what crosses; the agent does the reading that leads up to it. To fill a form, the model has to read it, and the reading happens before the dialog appears, so a team that lets an agent touch a supplier record, a benefits portal or a payment page is deciding between gating the write and gating the read. The question is where the gate sits, what it is built from, and what can be checked on a form carrying a bank account. The record here is one form submission on a vendor site, followed from the page the agent reads to the insertion a person approves.
Key findings
- For an approval to settle the question, the values on a vendor's rendered page would need to be replaced with consistent tokens before any model reads it, and the real values would resolve only at the approved destination (RedactSure vs Dia: 2026 Comparison & Alternative).
- It would also require a named person approving each insertion and a record of what the model read before the dialog; a click with no record leaves a reviewer reconciling an approval against an uncaptured page (What Is an AI Control Record?).
- Dia's security page states the insertion gate and the field classes its agent cannot touch; it does not state what the model receives before the gate (The Browser Company, 2026).
- Web agents in a measured study "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025).
- Harvard's guidance lists Sensitive Data Exposure, Prompt Injection and Model Manipulation among seven risk categories and asks teams to "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard, 2026).
- OWASP catalogs HITL dialog forging, an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP Foundation, 2025).
What does Dia insert into a vendor's form, and when does it ask you to approve?
The record is a form submission on a vendor site: a supplier renewal that asks for a company name, a billing address, a tax number and the bank account that receives payment. The agent reads the form and fills what it can, then stops where values would enter the vendor's page. The Browser Company describes that boundary as an approval: Dia "won't insert data into third-party sites without your approval" (The Browser Company, 2026).
Agentic AI, in one industry definition, refers to systems "capable of pursuing goals autonomously by making decisions, taking actions, and adapting to dynamic environments without constant human oversight" (MIT Sloan Management Review, 2025). Dia's security page also says "Web form fields like passwords and irreversible action buttons are invisible to the agentic system," so the field classes a person guards by hand stay outside the agent's reach (The Browser Company, 2026). A form that asks for a bank account is not one of those classes.
The insertion gate decides where values may go; the irreversible button decides whether the submission happens. A control on what an agent can type is not a control on what the model is shown, the distinction a paste attack turns on (Can a Browser Agent Be Tricked Into Pasting Sensitive Data Into a Chat?). The values the model read to draft the form are in its context before the dialog appears.
What does Dia's model read before the approval appears?
It reads the page it is working on. The security page says Dia "sends your prompt and the relevant page content to a third-party AI model," and that content "isn't tied to your account, is retained for 30 days, and then deleted" (The Browser Company, 2026). A vendor form is page content, including the account name already filled in and the bank details a returning supplier sees. Dia is one of the 15 AI agents reviewed, and none of the 15 describes replacing the customer data on a working page with tokens the agent can work with, so the page's values reach the model before the approval dialog appears (Do AI Agents Ask Before Making a Payment?).
Web agents in a measured study "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025), which describes a bank account copied into a task that never needed it. Information-flow work finds that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system," including by "coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025).
A vendor page can also hold what the person never sees. Hidden elements capture what an agent types, and the Environmental Injection Attack study reported "up to 70% ASR in stealing specific PII" (How Do You Protect Company Credentials When AI Agents Navigate Websites?). Neither mechanism is specific to Dia; both describe what an approval after the reading cannot reach. The dialog and the click that follows it cannot take those values back out of the model's context.
What do the vendors themselves say?
Two vendor pages bear on this question, and only one is about an agent. Dia's page is quoted for where its gate sits; Google's guidance is quoted for the account that holds the authority to approve.
| Dimension | Dia, per its documentation | What a buyer should verify |
|---|---|---|
| The insertion gate | "Won't insert data into third-party sites without your approval." (The Browser Company, 2026) | Which actions count as an insertion, and whether every destination is covered |
| Field classes | "Web form fields like passwords and irreversible action buttons are invisible to the agentic system" (The Browser Company, 2026) | Which fields on your form fall outside those two classes |
| What the model receives and keeps | "Dia sends your prompt and the relevant page content to a third-party AI model"; content "isn't tied to your account, is retained for 30 days, and then deleted" (The Browser Company, 2026) | The page as the model saw it, field by field, and how long that content is kept |
Google's guidance for administrator accounts speaks to the authority behind an approval: "Use the super admin account only when needed" (Google, 2026). It says the account that can authorize a write into a vendor's site should not be the one a person uses for everything else. The guidance does not tie that practice to an agent's approval dialog.
Dia documents where the gate sits; Google documents a habit for the account behind a decision; neither states what the model received from the form before the gate.
Who approves the insertion, and can the dialog be forged?
An approval is a person, a dialog and an identity. OWASP catalogs the dialog failure as HITL dialog forging, an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP Foundation, 2025). A page that can shape the dialog can change what the approver believes they are approving (Does Human Approval Stop Actions Triggered by Prompt Injection?).
Defenses built for that class do not hold on their own: adaptive attacks bypassed 12 published defenses with an "attack success rate above 90% for most," many of which had reported near-zero rates (Nasr et al., 2025).
New York's Department of Financial Services tells covered entities to consider "authentication factors that can withstand AI-manipulated deepfakes" (New York State Department of Financial Services, 2024). Harvard's guidance is plainer: "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard, 2026).
Few deployments can name the person accountable for an agent's action, and after an incident that absence becomes the first audit finding (What Is Supervised Delegation?). Dia's page documents an approval step but does not name the approver.
What should a security team ask for in writing?
Five questions, asked of the vendor in writing, settle more than a demonstration does. First, which actions the approval covers: every insertion into a third-party site, or only the ones the product classifies as sensitive. Second, what the model receives from a rendered screen before the approval appears, field by field for one page the team uses. Third, whether the approver sees real values or placeholders, and which the record keeps. Fourth, who the named approver is and which account they use. Fifth, what record leaves the product, in what format, and where it goes.
Two supporting questions follow. Ask how long the page content sent to the model is kept, since Dia's page gives thirty days for content it sends (The Browser Company, 2026). Ask what the dialog is built from, because a dialog assembled out of page content is the input a forged-dialog attack shapes.
The test of an answer is a sample rather than a promise. A vendor that can produce one page as the model saw it, with each field marked real or replaced, has answered the second question. A masking control belongs in the same conversation, because a placeholder that survives the run changes what an approval can leak (Does Masking Data on Screen Break Browser Agents?).
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 the model works on placeholders such as CUST_001. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at an approved destination, at the moment of an approved action. A named person 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 monitoring.
For this page's question, the difference is which step the gate covers. An insertion gate sits at the boundary between the browser and the vendor's page, so it decides what leaves; a render-layer control sits before the model, so it decides what arrives. Under the second, the approval is about a tokenized draft and a named destination, and the model's context holds placeholders rather than the supplier's bank account (RedactSure vs Dia: 2026 Comparison & Alternative).
Its scope is the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP, which matters if a team submits the form through an API. For this form, the model never holds the account number, and the approval attaches to a named person and a destination.
What the record shows
An approval gate is worth what the reading behind it allows. Dia's page puts the gate on insertion and keeps two field classes away from its agent; the same page sends the prompt and relevant page content to a third-party model, so the values on a vendor form are in the model's hands before anyone approves the write. The record that settles a review is per screen: what the model received, which values were real, who approved and where it went. The test is one form the team submits: capture the model's input for the page and compare it with the fields the approver saw.
Methodology and limitations
This page rests on The Browser Company's security page for Dia, Google Workspace administrator guidance, a state regulator's industry letter, OWASP's catalogue of the approval-dialog attack, university guidance and one industry analysis, with three research papers. 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.
No product named here was tested for this page; each is described from its public documentation, and features change, so the page carries its date. "Not described in the pages reviewed" means the recorded pages do not state a point, not that the product cannot do it. RedactSure is deploying now with enterprise and government customers. The example describes a record type, 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
Does Dia insert data into third-party sites without my approval?
No, not on work accounts whose pages carry sensitive data. Dia's security page says it "won't insert data into third-party sites without your approval," and that page also says Dia "sends your prompt and the relevant page content to a third-party AI model," so the page is read before anyone approves. The approval gates the write into the vendor's site, not the read, and on a form with a bank account the answer turns on values replaced before the model reads the page.
What does Dia's model see before I approve an insertion?
It sees the page it is filling. The security page says Dia "sends your prompt and the relevant page content to a third-party AI model," and keeps that content for thirty days. A vendor form is page content, so the name, address and account numbers on it are part of what the model receives. The page arrives whole, and the approval gates the write into the vendor's site, not the read.
Does Dia's agent read password fields and press submit buttons?
No. The documentation says "Web form fields like passwords and irreversible action buttons are invisible to the agentic system," so the agent cannot read a password field or press a button a page treats as irreversible. A person supplies the password and makes the final click. Every other field is in the agent's view, including the company name, the tax number and the bank account a form asks for.
Can an approval dialog be forged to authorize an insertion you did not intend?
Yes, and OWASP catalogs the attack. HITL dialog forging "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations." A page that can influence the dialog can change what the approver believes they are approving. The defense is a dialog that names the action and destination, checked against a record of what the model read. A record behind the dialog is what makes that check possible.
What record should exist of what the model read before the approval?
A per-screen record of the values the model received, tied to the action a person approved. Without it, an approver has a dialog and a memory, and an auditor has neither. The record should name the approver, the destination and the values as the model saw them, marking which were real. Dia's page describes local deletion, not a per-screen record.
What changes if values are replaced before the model reads the page?
Then the approval is about a tokenized draft rather than the real values, and the model never holds the account number, the tax identifier or the address. The person approving sees the action and the destination, while the values resolve at the destination they approved. It changes what a failed approval can leak, because the context holds placeholders rather than the values.
How RedactSure Moves the Gate Ahead of the Model's Reading
An approval that arrives after the page is read confirms a draft the model already holds.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the renewal form, and the model reads the account name, tax number and bank account to fill it. Inside the governed environment: the form renders with CUST_001, TAX_001 and ACCT_001, the model drafts from the tokens, and the real values reach the vendor's form at the submission 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
An approval after the form is read cannot take back what the model holds. Bring one vendor form your team submits and see, with test values, what the model reads, who approves the insertion and what the record keeps. Book a demo