Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Browser Agent Fill In a Form Without Seeing the Values?

Yes, through placeholder substitution at fill time, which Browser Use and Skyvern document: the model directs the typing and the real value enters the field after the model's call. The gap both document is the next page, where the typed value can reappear as text or in a screenshot, so check what the model receives after the save.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Filling a form is the most common thing a browser agent does with a credential, and the agent frameworks have a documented answer for it. The model is shown a placeholder such as x_pass, decides where to type, and the framework writes the real value into the field after the model has made its decision. For the fill itself that works, and two vendors describe it in nearly the same words. The question that remains is what happens one click later. A saved form is usually followed by a page that shows what was saved, and that page is read by the same model that was kept away from the value during typing. This page takes one record type, an environment variable form in a hosting dashboard where an agent pastes a database connection string and the next page lists the variable with its value, and works through how fill-time substitution works, what the vendors state about it, where the value reappears, what the research record says about a value in the model's context, what credential hygiene adds after the fact, and what a control at the render layer changes. Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? covers sign-up and checkout forms as a measured leakage point; this page covers the fill-and-echo sequence as a class.

Key findings

  • Browser Use's sensitive data documentation states that "the LLM only sees placeholders (x_user, x_pass)" and that "real values are injected directly into form fields after the LLM call," so the fill itself proceeds without the model holding the value, and the page says nothing about the page that follows the fill (Browser Use, Sensitive, 2026).
  • Skyvern's credentials documentation says "the model that drives the browser gets placeholders, not your values," and adds that "a typed value can still show up in later screenshots and page text," which names the gap this page is about (Skyvern, 2026).
  • Browsing agents have been shown to be hijacked by untrusted web content, with credential exfiltration among the demonstrated outcomes, so a value that reappears in the model's context is a value an attacker can ask for (Mudryi et al., 2025).
  • OWASP's CI/CD guidance says to "prefer using temporary credentials over static credentials" and to "avoid sharing the same set of credentials across multiple contexts," which limits what an echoed value is worth (OWASP, 2026).
  • A governed environment that replaces values with consistent tokens before any model reads the screen masks the confirmation page as well as the form, because the substitution acts on every rendered page in the run (What Is Render-Layer Tokenization?).
  • In that environment real values resolve only at the approved destination at the moment of an approved action, so the connection string reaches the dashboard's field and the model works on a token throughout (What Is the PII Wall?).

How does placeholder substitution at fill time work?

The design is the same in each implementation that documents it. The developer hands the framework a dictionary of credentials before the run, each under a short name. The text the model receives is filtered so that the real values never appear in it, and the names appear instead. When the model decides to type into a field, it types the name, and the framework replaces the name with the value at the moment it writes to the field. The model has directed a fill without ever holding what was filled.

For the example record, the agent opens the environment variables form in a hosting dashboard, reads a page with two empty fields, and decides to type x_db_url into the value field. The framework writes the real connection string. Up to this point the model's context holds the page, the field labels and the placeholder, and nothing else. Browser Use's open-source page describes exactly this: "the LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text," and "real values are injected directly into form fields after the LLM call" (Browser Use, Sensitive, 2026).

The scope of this page is the rendered page. A governed browser environment covers what the agent reads and does on a rendered page, including dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A connection string set with a command-line tool is a different route with different controls, and no browser control governs a shell. The fill-time mechanism has a boundary of its own: it acts on the text the model is sent and on the field the framework writes to, and not on the page the browser renders after the save.

What do the vendors themselves say?

Browser Use pairs the placeholder filter with two settings on the same page, "Set use_vision=False to prevent screenshot leaks" and "Use Browser(allowed_domains=[...]) to restrict navigation," each of which limits what the model is sent and neither of which rewrites a page that displays a saved value (Browser Use, Sensitive, 2026). Its cloud secrets guidance adds that "Zero Data Retention (ZDR) projects never record, even when recording is requested," which keeps a value off a stored recording and does not change what the model read during the run (Browser Use, Secrets, 2026). A separate page describes connecting to an existing Chrome profile so the agent is "already logged into your websites," which removes the login form from the task and leaves every later page readable as before (Browser Use, Real, 2026).

Skyvern states the mechanism and its edge in two sentences: "the model that drives the browser gets placeholders, not your values," then "a typed value can still show up in later screenshots and page text, so turn on Mask Secrets in an agent's settings to hide it there too," so the masking covers values Skyvern typed from a stored credential or a connected vault and nothing a page shows that Skyvern did not type (Skyvern, 2026).

1Password's post on browser agents says "the AI agent and underlying LLM never need to see nor handle the credentials," injected "if, and only if, the human approves the access," a design for logins the vault already holds and not for the page a site renders after the login succeeds (1Password, 2025). A per-run record of each screen as the model received it is not described in the pages reviewed for any of the three.

Where does the value reappear after the fill?

On the next page, in three forms. The first is a confirmation or review step that displays what was entered so a person can check it. The second is a settings list that shows saved values in place, which is what the example dashboard does when it lists the variable with its value after the save. The third is a screenshot of either page, which carries the value as pixels whether or not the text extract was filtered.

Each form reaches the model by the ordinary route. The agent's next decision needs the next page, so the framework sends it, and the fill-time filter has no name to substitute, because the value on that page is page content and not a value the model typed. Browser Use's recommendation to set use_vision to False closes the screenshot route for every page and leaves the text route open (Browser Use, Sensitive, 2026).

Dimension Fill-time placeholders, per Browser Use and Skyvern documentation What a buyer should verify
Fill Model types a placeholder; framework writes the value That the trace of the fill step holds the placeholder only
Next page, text Not covered by the filter; Skyvern masks values it typed What the text extract of the confirmation page contains
Next page, screenshot Browser Use recommends use_vision False; Skyvern Mask Secrets What a screenshot of the saved variable shows
Values the page generates Not covered Whether a generated credential is ever masked
Record of what the model saw Not addressed on the pages cited A per-run record of each screen as received

A fill-time control is tested at the fill step, and the next page is where the test continues. What Can an AI Agent See in Your GitHub Settings? walks the same sequence through one platform's token pages.

What does the research record say about a value the model can see?

That it can be taken. A study of browsing agents reports findings that "include prompt injection, domain validation bypass, and credential exfiltration" and demonstrates "how untrusted web content can hijack agent behavior" (Mudryi et al., 2025). The hosting dashboard is trusted, but the agent that saved the variable goes on to read a README, a ticket or a documentation page, and any of them can carry an instruction to repeat what the context holds. The connection string on the confirmation page is what the instruction asks for.

The defenses in the record act on the request, not on the context. The LlamaFirewall preprint describes PromptGuard 2 as "a universal jailbreak detector that demonstrates clear state of the art performance" and reports that its alignment checker "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches," with no quantitative results on the abstract page (Chennabasappa et al., 2025). Progent describes privilege control for agents and states that it "significantly reduces attack success rates while maintaining high utility," again without numbers on the abstract page (Shi et al., 2026). An adaptive attack study that bypassed 12 published defenses against jailbreaks and prompt injections, most at rates above 90 percent, is the reason to assume some requests get through (How Do You Protect AI Agents Against Prompt Injection?).

A detector that stops most injections leaves a residue, and the residue collects whatever the context holds. A model that holds a placeholder at the fill and the real value on the next page is protected at the first step and exposed at the second. The attacker does not need the fill step.

What does credential hygiene add after the fill?

A ceiling on the damage. OWASP's CI/CD guidance says to "prefer using temporary credentials over static credentials," to "avoid sharing the same set of credentials across multiple contexts," and to "detect secrets pushed to and stored on code repositories," and gives no rotation interval for a static credential (OWASP, 2026). Applied to the example record, a short-lived connection string scoped to one environment is worth less when echoed than a long-lived one shared across staging and production.

Detection closes the loop on what escaped. GitLab's documentation states that "pipeline secret detection runs as part of a project's CI/CD pipeline" and that "you should always revoke and replace exposed secrets as soon as possible," which catches a value an agent pasted into a repository file and acts after the paste (GitLab, 2026). It does not see a value that stayed in a model's context or a trace. The scale is set out in How Do You Let an AI Agent Manage API Keys Without Reading Them?, which reports GitGuardian's count of more than 28 million new credentials exposed in public commits across 2025.

Sonatype reported that "56% of the malware discovered in Q1 2025 was related to data exfiltration," up from 26% in the previous quarter, with no figure for credential theft on its own (Sonatype, 2025). Hygiene reduces the value of what leaks; it does not reduce what the model was shown.

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 on every page, not only at the fill. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this question the difference is the next page. The fill-time mechanism substitutes once, at the field, and the confirmation page arrives unfiltered. A render-layer control substitutes on the confirmation page too, because the policy that tokenized the value on the form recognizes the same value when the dashboard lists it and renders the same token. The model sees that DB_URL was saved with value SECRET_001 and reports the task complete. The real string reached the dashboard at the save, which was the approved action at the approved destination, and nothing the model read afterward carries it. A screenshot of a tokenized page shows the token.

The control covers the rendered page and not the terminal, the IDE, the local filesystem, direct API calls or MCP, so a value set from a shell stays with the shell's controls. Within that scope it also answers the question the vendor pages leave open: what the model saw on each page, kept as a record a security team can read after the run. Enterprise Browser or Render-Layer Tokenization? sets the control against the enterprise browser, which governs where a person moves data and not what a model reading a permitted page receives.

Methodology and limitations

This page rests on the public documentation of Browser Use, Skyvern and 1Password for the vendor section, three research preprints, OWASP's CI/CD guidance and GitLab's documentation for credential hygiene, one vendor research release, and existing RedactSure research pages. Sources were read between October 20, 2026 and October 21, 2026. Quoted facts are cited to the page that states them, and the preprints are cited for the findings their abstracts state and not for figures that appear only in their full text.

RedactSure did not test Browser Use, Skyvern or 1Password hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The table summarizes the documentation as read and is not a configuration guide. The research papers concern attacks and defenses in general and are cited for the principle only. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as an environment variable form in a hosting dashboard, and not organizations.

Determinations about whether a configuration meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against a copy of its own form, with the trace of the fill step and the next page read side by side, repeated after each release of the framework, since a change to the filter or to the masking setting would change the answer. The date on this page marks when the documents were read, and a later release should be treated as unreviewed until the test is repeated.

What the record shows

The vendor pages answer the title question for the fill and leave the next page open. Browser Use and Skyvern both document a model that types a placeholder while the framework writes the value, and Skyvern states that the typed value can reappear in later page text and screenshots. The research record shows that a value in context can be asked for by untrusted content and that the defenses in the record reduce the asking without ending it. Hygiene and detection lower what an echoed value is worth and act after the echo. A control that substitutes at render, on the form and on the page that follows it, is the one that keeps the value out of the context on both, and it is the one RedactSure's design is built around. A practical test takes one agent and one form: fill it with a disposable credential, then read the trace of the page after the save for the value.

Frequently asked questions

Can a browser agent fill in a form without seeing the values?

Yes, for the fill step. Browser Use and Skyvern both document placeholder substitution: the model is sent a short name instead of the credential, decides where to type, and the framework writes the real value into the field after the model's call. The model never holds the value during the fill. What the documentation does not claim is that the page after the submit is treated the same way, and that page is where a saved value is usually displayed.

Why does the value show up again after the submit?

Because the next page is content, not a value the model typed. A confirmation step, a settings list or a screenshot shows what was saved so a person can check it, and the agent reads that page to decide its next action. The fill-time filter has nothing to substitute there, since no placeholder name appears on the page. Skyvern says this in its own documentation and offers Mask Secrets for values it typed, which is the setting to turn on and then test on the page after the save.

Does turning off vision close the gap?

It closes the screenshot route and leaves the text route open. Browser Use recommends use_vision False to prevent screenshot leaks, and with it off the model receives no pixels of the confirmation page. The text extract of that page still carries any value the page prints, so the setting narrows the exposure rather than removing it. Test both routes on the fill step and again on the page after the save.

Does a password manager integration solve this?

For the login, largely. 1Password describes injecting credentials so the agent and the model never handle them, with a person approving the access. That covers values the vault already holds and the moment they are used. It does not describe the pages a site renders after the login succeeds, and a settings page that prints a saved credential is read as any other page. Treat the vault as the control for the fill and look elsewhere for the echo.

What should a team do if a value was echoed into a trace?

Rotate it, scope its replacement narrowly and search for it. OWASP's CI/CD guidance says to prefer temporary credentials over static ones and to keep one set of credentials to one context, which caps what the echoed value can reach. GitLab's secret detection catches a value that landed in a repository and says to revoke and replace it at once. A trace held by the agent framework needs its own search, since pipeline detection does not read it.

How does render-layer substitution differ from fill-time substitution?

Fill-time substitution acts once, on the field, with a name the developer supplied. Render-layer substitution acts on every page the model reads, replacing values chosen by policy with consistent tokens before the model sees them, so the confirmation page carries the same token as the form. The real value resolves only at the approved destination when a named person approves the action. The difference is which pages are covered, and the next page is the one that decides.

About the author

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.

How RedactSure Keeps a Filled Value Off the Next Page

Fill-time substitution acts once at the field, so the page after the save reaches the model unfiltered with the value the agent never typed.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent types x_db_url, the framework writes the connection string, and the next page lists the real value for the model to read. Inside the governed environment: the model types SECRET_001, the named person approves the save, the real string reaches the field, and the next page renders DB_URL as SECRET_001.

RedactSure is deploying now with enterprise and government customers. Skyvern's own documentation states that "a typed value can still show up in later screenshots and page text."

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

A filled value that reappears on the next page undoes the protection at the field. Bring a form your agent already completes and see, with test values, what the model reads on the page after it saves. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.