Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Is a Secure Alternative to Browser Use for Vendor Portal Automation?
A secure alternative to Browser Use for vendor portal automation replaces the values a portal displays with consistent tokens before any model reads the screen, then releases a real value only at the approved destination. Ask whether the account number the portal echoes after sign-in is covered, who approves the payment, and what record the run leaves.
A vendor portal is where a finance team pays its suppliers: a login, an invoice list, an account number printed at the top of the page, and a Pay now button beside each row. An agent can take the repetitive part, opening each invoice, checking the amount against the ledger and preparing the payment. The page a person would read without thinking about it decides the risk, because the account number, the balance and the invoice list reach the model as text and often as a screenshot. Browser Use, the open-source library many of these agents are built on, documents a careful design for the values an agent types: the model composes the action from a placeholder and the library injects the real value into the field after the call. A portal prints the number after sign-in rather than receiving it from the agent, and that difference decides whether the model works on the account or on a token. Three questions settle the choice: what the model reads on the portal screen, who approves the payment, and what the run leaves behind.
Key findings
-
For a Browser Use agent to be safe on a vendor portal, the values the portal renders would have to be replaced with consistent tokens before any model reads the screen, so the account number arrives as ACCT_001 on every page of the run (What Is a Protected Browser for AI Agents?).
-
It would also require a named person approving each payment, submission and record change, and a record of what the model received on each screen, exported to the organization's own monitoring (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
-
Browser Use's page covers the text an agent types and not the text a portal displays, and it does not describe what the model receives from the account page that renders after login (Browser Use, Sensitive, 2026).
-
The page states that "The LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text," and that "Real values are injected directly into form fields after the LLM call" (Browser Use, Sensitive, 2026).
-
It adds two narrower controls, "Set use_vision=False to prevent screenshot leaks" and "Use Browser(allowed_domains=[...]) to restrict navigation," which bound what the agent sees and where it goes (Browser Use, Sensitive, 2026).
-
Bhagwatkar and colleagues report a "simple, modular, and model-agnostic defense operating at the agent-tool interface" that "achieves perfect security with high utility across all four public benchmarks," and finds that "existing agentic security benchmarks are easily saturated by a simple approach" (Bhagwatkar et al., 2026).
What does a Browser Use agent read on a vendor portal page?
The record for this page is one vendor portal of the kind a facilities supplier runs: a sign-in page, then an account page that prints the account number, the balance and an invoice list. The number arrives as text and, with vision enabled, as pixels in a screenshot, so it sits in the model's context before the agent decides anything about the invoice.
Browser Use's template is written for the other kind of value, the one a developer supplies for the agent to type. Its example is a login form, where the model works from x_user and x_pass and the library injects the real strings after the call (Browser Use, Sensitive, 2026). A portal prints the account number from its own records, so no supplied value exists for a placeholder to stand in for.
An agent that fills a form without seeing the values still reads the confirmation page, where an application repeats what it saved (Can a Browser Agent Fill In a Form Without Seeing the Values?). A key a console generates during the run is sharper still, because no developer supplied it, as Can a Browser Agent Read an API Key It Just Generated? describes.
Substitution at the render layer moves the control to the page: the page is drawn, the fields chosen by policy are filled from a store, and the model is shown a consistent token such as ACCT_001 where the number sits (What Is Render-Layer Tokenization?). The token stays the same across the run, so the agent can match the account on the invoice list and the payment form without holding the digits.
What happens when a portal page carries a hidden instruction?
A vendor portal carries text other people wrote: invoice memos, supplier names, a chat widget in the corner, and on a bad day a note in a remittance field. Any of it can carry an instruction the agent reads as its own.
Siddiqui and colleagues describe the path: "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). The DAPLab authors say the same of existing controls: "access control governs who can touch data, integrity constraints govern what gets stored, but neither governs how data flows and is used during agentic execution" (DAPLab, Environments, 2026).
Filtering at the agent-tool interface is the defense most often proposed, and its results reward a close read. Bhagwatkar and colleagues report a defense that "achieves perfect security with high utility across all four public benchmarks," and the same paper finds that "existing agentic security benchmarks are easily saturated by a simple approach" (Bhagwatkar et al., 2026). A defense measured against benchmarks its authors call weak assures less than a control that removes the value first.
What an instruction collects is decided earlier, by what the model was shown. If the model read the account number, the instruction can ask for it and get it; if it read ACCT_001, it collects a token that means nothing outside the environment that issued it (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
What do the vendors themselves say?
The vendor pages here are Browser Use's sensitive data template and Coder's best-practices guide for AI coding agents, and both are specific about their boundary.
Browser Use describes the placeholder as a filter on input: the model sees x_user and x_pass, and the real values are injected into the form fields after the LLM call (Browser Use, Sensitive, 2026). The same page gives two further controls, "Set use_vision=False to prevent screenshot leaks" and "Use Browser(allowed_domains=[...]) to restrict navigation," which narrow the image path and the set of sites the agent may visit (Browser Use, Sensitive, 2026). Coder writes the general caution: "LLMs and agents can be dangerous if not run with proper boundaries," and it advises against giving an agent "full permissions on behalf of a user" in favor of separate identities "with limited scope whenever interacting autonomously" (Coder, 2026).
| Dimension | Browser Use, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | On the text the agent supplies: "we filter your sensitive data from the input text" (Browser Use, Sensitive, 2026) | Whether the account number a portal prints is inside that boundary |
| What the model receives | "The LLM only sees placeholders (x_user, x_pass)" for a value the agent types (Browser Use, Sensitive, 2026) | One portal screen, shown field by field |
| Restoring a value | "Real values are injected directly into form fields after the LLM call" (Browser Use, Sensitive, 2026) | What restores a value the page displays, and who releases it |
| Record and approval | The page describes placeholders, screenshots and navigation, not an approval step (Browser Use, Sensitive, 2026) | A person's name against the payment, and a record of what it read |
Of 86 AI security and data protection products reviewed, 0 describe reversible tokenization of what an agent reads on a screen, and one describes masking on a page (How Many AI Security Products Control What an AI Agent Sees?).
Who approves the payment, and what record does the run leave?
Browser Use's page stops at the field. An approval step and a record are separate controls, and the organizations that write about them put both outside the model. An approval is only as good as the authority behind it, and Harry Ghuman, CEO, Alpha Decisions, described the point on a HAL podcast: "AI actually took the action, but it didn't give itself the legitimate authority. Somebody else gave it that authority" (What Is the AI Delegation Frontier? Harry Ghuman on Who Gave the AI Its Authority). For a portal run, that somebody is the named approver in the record.
OpenAI's governance paper treats human approval as "a standard way to limit egregious failures," and it sets the accountability bar plainly: "at least one human entity is accountable for every uncompensated direct harm" (OpenAI, 2023). The same paper asks that "Actions that can only be reviewed after the fact should be more easily reversible" (OpenAI, 2023), a useful test for a payment, since a submitted remittance is not easily reversed.
AWS's Agentic AI Lens states the logging requirement in one line: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). For a portal run, the log has to separate the named approver from the agent that prepared the payment, and the agent's session from the clerk's.
Data minimisation points the same way. The GDPR requires personal data to be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" (Regulation 2016/679, 2016), and a payment needs the invoice number and the amount while the account digits stay out of the model. What answers an auditor is the screen the model read, the action as it was proposed, and the approval with a name on it.
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 a policy chooses are replaced with consistent tokens for the whole run, so the supplier's account is ACCT_001 on the account page, in the invoice list and in any note the agent writes. Real values resolve only at an approved destination, at the moment of an approved action, so the digits reach the payment form the approver saw and not the transcript. A named person approves each payment, submission and record change, and the screen, the action and the approval land in a record that exports to the organization's own monitoring.
Scope is the last limit: the control covers what the agent reads and does on a rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP.
The gap between experiment and scale is where it sits: 62% of organizations are at least experimenting with agents and 23% are scaling them (What Is the PII Wall?), and the stack problem is a layer problem, because "trustworthy agent automation cannot be solved at a single layer of the stack" (DAPLab, Infrastructure, 2026). The nearest comparison is Browser Use itself, set beside this control class (RedactSure vs Browser Use: 2026 Comparison & Alternative).
What the record shows
Three things decide the answer, each at the layer where the page is drawn: whether the values a portal renders are replaced before any model reads the screen, who approves the payment the agent prepared, and what record of the run survives. Browser Use's page settles the first for typed values and leaves the printed page alone, so the account number a vendor portal shows after sign-in reaches the model as itself. The research record is why that matters: a filter at the tool interface posts strong benchmark results, and the same paper calls those benchmarks easily saturated, so a control that depends on catching an instruction is a different bet from one that keeps the value out of the model. A security owner can settle it in an afternoon by running one portal task with a test account, then searching the trace for the account digits and naming the person who approved the payment.
Methodology and limitations
This page rests on Browser Use's sensitive data template and Coder's guide for AI coding agents, OpenAI's governance paper, a ServiceNow and university study of indirect prompt injection, a peer-reviewed information-flow paper from Microsoft and Cambridge, GDPR Article 5(1)(c), AWS's Agentic AI Lens, and two Columbia DAPLab posts. Vendor pages were read between October 16, 2026 and October 21, 2026. Public documentation read in full gives a sound view of where each product applies its control.
The products on this page are described from documentation and none was tested for this page; "not described" means the pages reviewed, and vendor features change, so a release after this page's date is unreviewed. The example describes a record type, a supplier portal, not an organization. Whether a payment flow meets a contractual or regulatory requirement belongs 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
What is a secure alternative to Browser Use for vendor portal automation?
One that keeps the portal's values out of the model, names the person who approves each payment, and keeps a record of both. Browser Use documents placeholders for the values an agent types, plus a vision setting and a domain allowlist. The account number a supplier portal prints after sign-in sits outside that mechanism, so the alternative has to act on the rendered page.
Does Browser Use keep the account number a portal shows out of the model?
No, not the number the portal prints. The template covers values a developer supplies for the agent to type, where the model sees x_user or x_pass and the library injects the real string after the call. A portal draws the account number from its own records after sign-in, and that page renders to the model as text or as a screenshot. Vision off removes the screenshot path and leaves the page text, so test the account page, not the login form alone.
Who approves a payment the agent prepared on the portal?
A named person outside the model, if the environment is built that way. Browser Use's page describes substitution and navigation, and it does not describe an approval step, so the person at the keyboard is the only actor in the loop by default. That is a safeguard for the clerk, not an approval for a controller. A payment needs an approver who is not the account the agent signed in as, and the approval should name the amount and the invoice.
What record does finance get of one run on a supplier portal?
From Browser Use's pages, none that is described: they cover what the model sees when it types and where it may navigate, and a template keeps no log. AWS's guidance asks for logs that separate an agent's actions from a person's, the requirement to write down. A governed environment produces that record as the run happens, with the page as the model read it and the approval beside it.
What changes when a hidden instruction reaches the agent on a portal page?
Where the damage stops. An instruction in an invoice memo or a supplier name can redirect the run, and data read in one component can be spread by the model. A filter at the tool interface may catch it, and its own authors note that the benchmarks used to measure it are easily saturated. What the instruction collects is decided earlier, by what the model was shown. On a page rendered as tokens, it collects a token.
What should a security team ask a vendor in writing?
Which values on a rendered screen are replaced, and by what policy; where the real value is restored and who approves that release; who approves a payment or a record change; and what record of the screen and the approval the organization can export. Ask about the account page after sign-in, not the login form alone, because that is where a portal repeats the number. An answer the documentation does not support stays unanswered until a test confirms it.
How RedactSure Keeps a Portal's Account Number Out of the Model
An agent that reads a portal's account number has already read it, and a control on the field it types into changes nothing.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent signs in on the clerk's session, the portal prints the account number, and the digits sit in the transcript for the rest of the run. Inside the governed environment: the page renders with ACCT_001 in place of the number, the invoice numbers and amounts stay for reconciliation, and the real account reaches the payment form only on a named approver's release.
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 account number a portal echoes after sign-in is the value a controller asks about first. Bring one supplier portal task and see, with test values, what the model reads, who approves the payment and what the record holds. Book a demo