Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Browserbase Keep a Browser Agent From Seeing My Credentials?
No, not the page: a fill step can keep the login out of the agent's context, and the authenticated page the agent opens next, with any token the account renders there, reaches its model like any other page. Ask what the model receives after the sign-in, not only during it.
A developer asks a browser agent to set up a hosted service: create the account, confirm the email, generate an API key and paste it into a repository's settings page. The sign-in can be delegated to a password manager that fills the form after a person approves, and the manager's own post says the model never handles that password. The screen after it is a different question. The console renders the new key once, beside the account name and the plan, and the agent reads it to finish the job. Whether the first step was hidden says nothing about the second. A product that hides a login may still hand over the page behind it, and the difference shows up on the second screen of a setup run. The record here is that pair, a login hidden and a token shown, and the answer turns on where a product puts its control: on the sign-in, on the session that follows, or on the page itself.
The stakes are practical. A credential that reaches a model sits in its context for the rest of the run, and any page after that can ask the agent to repeat it. A browser agent can log in without seeing the password. What it sees once it is logged in decides exposure, and that is where the products in this article differ.
Key findings
- For Browserbase to keep a credential out of the model on those accounts, the values on a page would have to be replaced with consistent tokens before the model reads it, and the real value would resolve only at the approved destination (What Is Least Exposure?).
- It would also require a named person approving each action after the sign-in and a record of what the model received on every screen the run opened (Can a Browser Agent Get Past Two-Factor Authentication Without Seeing My Codes?).
- Browserbase's documentation does not state that page values are replaced before the model reads them; it describes Contexts that store cookies and session tokens so a developer can log in once and reuse the state (Browserbase, Authentication, 2026).
- Browser Use's sensitive-data template shows a fill outside the model: "The LLM only sees placeholders (x_user, x_pass)," and "Real values are injected directly into form fields after the LLM call," a pattern a team wires in (Browser Use, Sensitive, 2026).
- 1Password's post on browser agents says the agent and underlying LLM "never need to see nor handle the credentials," injected "if, and only if, the human approves the access," which covers the fill and not the account page after it (1Password, 2025).
- A Context is "uniquely encrypted at rest" and "persists until you explicitly delete it or it becomes invalidated," which protects the stored session and not the page the session opens (Browserbase, Contexts, 2026).
What does a browser agent read during and after a login?
A browser agent works on pages the browser draws: a sign-in form, an account console, an API keys page, a billing settings page. A governed browser environment covers what the agent reads and does on those rendered pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a credential the agent prints in a command or reads from a file is outside the question here.
Browserbase runs browsers in the cloud and gives an agent a session it can drive, so the page is where a value becomes visible. A password manager fills the sign-in form. A Context stores the signed-in state for the next visit. Neither sits between the drawn page and the model once the session is open.
For example, one run opens four frames: the login form, the account home, the team settings page and the API keys page. A control that recognizes a credential only in the first frame governs one of the four. The exposure in question lives in the fourth, where the console displays a value the application generated after the person's approval had already been used (Can a Browser Agent Copy Customer Data From a Web App Into a Prompt?).
The question is where the control sits, not which vendor owns the browser (Enterprise Browser or Render-Layer Tokenization?).
What does the agent receive after the login form is filled?
The record is a login hidden and a token shown. A developer asks an agent to set up a hosted service. At the sign-in page a password manager fills the stored credential after a person approves. The 1Password post on browser agents states that "the AI agent and underlying LLM never need to see nor handle the credentials," injected "if, and only if, the human approves the access" (1Password, 2025). The context holds the field names and the username, not the password.
Then the console renders: the account is created, the onboarding flow asks for a project name, and the API keys page displays a key the agent has just generated. The key did not exist when the approval was given, so no manager held it and no approval covered it. The model reads it because the page is the page.
Browser Use's sensitive-data template describes the other arrangement: "The LLM only sees placeholders (x_user, x_pass)" and "Real values are injected directly into form fields after the LLM call" (Browser Use, Sensitive, 2026). It does not describe a value the application generates during the run, which is the key on this page.
A hidden login and a visible credential can sit in the same run (Can a Browser Agent See My Password When It Logs In?). The fill protects one frame, and the account page that follows is another (How Do I Capture a Token the Moment It Appears on Screen?).
Browserbase was not among the 15 AI agents reviewed. The 15 cover that pair unevenly, with 9 describing a control that keeps passwords or credentials from the model and 0 describing one for the customer data on the screen (Do AI Agents Ask Before Making a Payment?).
What do the vendors themselves say?
Browserbase's documentation answers the session half of the question in detail and leaves the page half unaddressed. Its authentication guidance tells a developer to "Apply Contexts → Store cookies, session tokens, and local storage to prevent repeated logins" and to "Log in once, then reuse the saved authentication state" (Browserbase, Authentication, 2026). For an authentication flow that needs more security, the same page suggests an app password, a stored credential the person or the manager holds (Browserbase, Authentication, 2026).
| Dimension | Browserbase, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | Contexts store "cookies, session tokens, and local storage" so an agent does not log in again | Whether the control covers a value the page generates after the sign-in |
| What the model receives | Not described in the pages reviewed | What the transcript holds on the page after the sign-in |
| Session lifetime | A Context "persists until you explicitly delete it or it becomes invalidated" (Browserbase, Contexts, 2026) | Who deletes it, and what a stolen Context gives an attacker |
| Encryption | "Because of this, Contexts are uniquely encrypted at rest to ensure security" | Which keys protect the store, and who holds them |
| Sign-in credentials | An app password for a flow that needs more security | Which component fills the field, and whether the model reads it |
Browser Use's Real Browser page takes the other side: it can "automate your existing Chrome browser, so you are already logged into your websites," and connecting to it preserves "login sessions, cookies, and extensions for authenticated tasks" (Browser Use, Real, 2026). The page describes convenience and not the risk of pointing an agent at a profile a person uses for everything.
1Password's post describes the sign-in as the controlled moment, with a person's approval as the condition for the fill, and the console after the fill is outside it.
Island's enterprise AI browser page takes the page-side approach: it will "Redact sensitive data before it reaches any AI provider and intercept AI responses before they render to the user," with protection at "the last mile, inside the browser" (Island, 2026). The page describes a browser a person uses, and it does not describe an agent driving a remote session.
What should a team ask for in writing?
The first question to ask in writing is what the model receives from a rendered screen after the sign-in, and whether any value on that screen is replaced before the model reads it.
Ask five more in writing: which component fills the sign-in and whether the model ever reads the filled value; whether the console pages the agent opens are drawn with tokens or with the values the application produced; who approves the agent's actions once it is signed in; where the session state lives and when it is deleted; and what record of what the model read can be exported to the buyer's own system.
Two documented controls show why. GitLab's documentation states that "When a job outputs the value of a masked variable, the value is replaced with [MASKED] in the job log," and warns that masking "is not a guaranteed way to prevent malicious users from accessing variable values" (GitLab, 2026). Masking changes an output, not what the process held when it produced it, and a page-level control has to pass the same test: does the substitution happen before the model reads, or in the text after it did?
Automation still runs on durable credentials. Datadog reports that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions" (Datadog, 2025), a count of long-lived identities in automation. A Context is the same shape of asset, and it "persists until you explicitly delete it or it becomes invalidated" (Browserbase, Contexts, 2026).
NIST's SSDF describes "a core set of high-level secure software development practices that can be integrated into each SDLC implementation," and its abstract page does not list the individual practices (NIST, 2022). A framework gives the categories to ask under, not the screen-level requirement, which has to be written into the vendor question and checked in the pilot.
What does a governed environment change?
A governed environment acts where the 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 with a placeholder such as KEY_001 where the console shows a key and ACCT_001 where it shows an account. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the policy and approves each consequential action, 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 record, that changes both frames. The sign-in is filled as before, and the account page that follows is drawn with tokens, including the key the agent generates during the run. The approval that releases the real value is tied to the destination the person approved, so the key reaches the repository setting and not the transcript.
It also changes what a team can check, because the record states what the model received on each page. The comparison for this vendor sets the two designs side by side: RedactSure vs Browserbase: 2026 Comparison & Alternative.
The scope stays the rendered page. A credential the agent prints in a terminal, reads from a file or sends through an API call is outside this control and inside the sandbox and credential-store rules set elsewhere.
What the record shows
The screen decides this question, not the login form. A fill step can keep a password out of the model, and the console that follows still renders the account, the plan and any key the agent generates, all of which the model reads. Browserbase's documentation covers the session and the sign-in, 1Password's release covers the fill, and Browser Use's template covers values a team lists in advance; none of the pages reviewed describes a substitution on the page after the sign-in. The conclusion is about placement: the credential is hidden where the control sits and visible everywhere else. A team can check its own tool by running one test sign-in on a test account, then writing down what the transcript held at the sign-in frame and again on the API keys page. If the key appears in the second entry, the page reached the model.
Methodology and limitations
This article rests on vendor documentation from Browserbase, Browser Use, 1Password and Island, NIST's SSDF page, GitLab's CI/CD variables reference and Datadog's State of DevSecOps 2025, with RedactSure research pages. The product statements are quoted from those pages. None of the products was tested for this page, and the example describes a record type, a login hidden and a token shown, not an organization. Vendor pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries the date for its page.
Where this article says a vendor does not describe something, it means the pages reviewed. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. Determinations about whether a workflow meets a contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Does Browserbase keep a browser agent from seeing my credentials?
No, not the page. Browserbase's documentation describes the session: Contexts store cookies, session tokens and local storage, and the agent reuses the saved authentication state on later visits (Browserbase, Authentication, 2026). That keeps the agent signed in. It does not change what the console renders once the agent is inside, and a key the account generates on an API keys page appears to the model as the page draws it.
Is the password hidden from the model during login?
Only where a fill tool does the typing. The 1Password post on browser agents says the agent and underlying LLM "never need to see nor handle the credentials," injected "if, and only if, the human approves the access" (1Password, 2025). Browser Use's template reaches the same result by keeping values out of the prompt and injecting them into the form after the model call (Browser Use, Sensitive, 2026). An agent that types a password itself has read it.
What does the model receive after the sign-in?
Whatever the page draws. An account console renders the account name, the plan, the team members and any credential the application generates, and the model receives those fields as part of the page it works from. Browser Use's template can hide values a team lists in advance, and it does not describe a newly generated key (Browser Use, Sensitive, 2026). Read the transcript at that frame, not only at the login.
Does a Context keep credentials out of the model?
No. A Context preserves the signed-in state so the agent does not log in again (Browserbase, Contexts, 2026). It is "uniquely encrypted at rest," which protects the stored session while it sits on the vendor's side. The encryption says nothing about the page the session opens, and the token a console displays there is a value the page produced, not a value the Context held.
Who approves the agent's login and the actions after it?
A person approves the fill, where a password manager is used; 1Password injects the value "if, and only if, the human approves the access" (1Password, 2025). The actions after the sign-in are a separate question. On the pages reviewed, the approval is tied to the sign-in request, and no approver is described for the key the agent generates or the repository setting it pastes the key into.
What record should a team ask for?
Ask for the page-level record: the fields the model read on each screen, the value it saw where a credential sat, the person who approved the action and the destination the real value reached. A session log shows that a Context was used, and it does not show what the page displayed, so ask for both and read them together. The two answer different questions, and only one of them can tell you what reached the model.
How RedactSure Keeps a Generated Token Out of the Model
A filled login leaves the console page, and the key it displays, for the model to read. Browserbase's own Contexts page says a Context persists until it is deleted, so the signed-in state outlives the task that created it.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent reads the key the keys page renders and can paste it into a repository setting or a prompt. Inside the governed environment the same page draws KEY_001, the real value resolves only at the destination a named person approved, and the record shows both frames.
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 login that a fill tool hides still leaves the keys page for the model to read. Bring one account your team provisions by agent and see, with test values, what the model reads and where the real token lands. Book a demo