Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Browser Agent Get Past Two-Factor Authentication Without Seeing My Codes?

Yes, when a password manager or the agent framework fills the one-time code outside the model, so the model directs the sign-in without holding the digits; a text-message code is typed by the person in a handover. A code is single-use, so check the session it opens and who approves what the agent does inside it.

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

A second factor exists to stop a login that has the password but not the person, and a browser agent is that case by design. The code, whether a rotating value from an authenticator app or a text message, is how the site decides the person is present, so an agent that signs in has to get the code into the form somehow. Two routes are documented. In one, a manager or the agent framework holds the credential and fills the code after the model has decided to submit, so the model works with a placeholder and never the digits. In the other, the code lands on a phone the agent does not hold, and the person types it in a handover of control. Either way the code expires within a minute and works once, which makes it the least valuable thing on the page. The session it opens is what lasts, and that is where the exposure question moves. This page uses one record type as its example, a time-based code filled by a manager into a sign-in form for a developer console. It works through what the vendor documentation describes, what changes when the code arrives by text, where a code can still surface in screenshots and recordings, why the session matters more than the code, and what a governed environment adds on the rendered pages that follow the login. Does Claude in Chrome Use Your Saved Logins and Open Sessions? covers the adjacent question of sessions already open in a browser.

Key findings

  • 1Password and Browserbase describe Secure Agentic Autofill as a way for AI agents to authenticate with web services "without ever exposing credentials," with "real-time approval prompts via 1Password mobile or desktop," so a person approves a fill the model never reads; the release describes the fill and not the pages that follow (1Password and Browserbase, 2025).
  • Skyvern's documentation on credentials, logins and 2FA states that "the model that drives the browser gets placeholders, not your values," and that connected vaults are read at run time, so the fill happens outside the model and the page after login is what the model reads (Skyvern, 2026).
  • Browser Use's sensitive data template says "the LLM only sees placeholders (x_user, x_pass)" and "real values are injected directly into form fields after the LLM call," and recommends use_vision=False "to prevent screenshot leaks," all of which covers values the developer passes in (Browser Use, Sensitive, 2026).
  • A study of browsing agents reports findings that include "prompt injection, domain validation bypass, and credential exfiltration," a risk to the session an agent holds after the code is accepted rather than to the code itself (Mudryi et al., 2025).
  • A governed environment replaces values with consistent tokens before any model reads the screen, so the account pages a second factor unlocks reach the model as placeholders, a control that least privilege over the login does not provide (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the model can direct a sign-in and the work that follows it without holding the code, the password or the record (What Is a Tethered Agent?).

Does a browser agent need to see the one-time code to sign in?

No. The model's job at a sign-in form is to decide that the field is the code field and that the next action is to submit. It does not need the digits to make that decision. The frameworks that document a placeholder design separate the decision from the fill: the model receives a placeholder in the page text it reads, decides to type into the field, and the real value goes into the field after the model's call. The manager or the framework produces the code from a stored credential at the moment of the fill.

The scope of this page is the rendered page in a browser. A governed browser environment covers what the agent reads and does on a page, which includes sign-in forms, consoles, dashboards and settings pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so nothing here describes a control over a code pasted into a shell or an API token used from a script.

The record type for this page is one time-based code, generated from a stored credential and filled into the second step of a sign-in form for a developer console. If the manager fills it, the model directs the step and never holds the code. If the person types it in a handover, the model may read it from the next page it is shown, which is the case the later sections take up. Sign-in and sign-up forms are already a measured leakage point for generalist web agents, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? sets out, and a code field is one more field on that kind of form.

What do the vendors themselves say?

1Password's release with Browserbase says Secure Agentic Autofill "allows AI agents to authenticate with web services without ever exposing credentials," that "credentials are not shared with the LLM or exposed in Browserbase logs and repos," and that approval is "human-in-the-loop" through real-time prompts on 1Password mobile or desktop; the release gives no implementation detail, and it describes the fill, not what the model reads on the pages that follow (1Password and Browserbase, 2025). The person is placed at the moment of use, which is where a second factor belongs.

Skyvern's documentation states that "the model that drives the browser gets placeholders, not your values," and that "saved passwords, card numbers and secrets are never shown again in the app or returned by the API"; the same page says "a typed value can still show up in later screenshots and page text," so the placeholder governs the fill and a separate Mask Secrets setting governs the afterimage (Skyvern, 2026).

Browser Use documents the same split for its sensitive_data mechanism, with placeholders in the model's text and real values injected into form fields after the model call, plus an allowed_domains restriction on navigation; the page covers values the developer passes in, and a code that arrives on a phone is not one of them (Browser Use, Sensitive, 2026).

Dimension Per the vendor documentation What a buyer should verify
Who fills the code Manager or framework, after the model's decision That the model's input carries a placeholder, not digits
Who approves 1Password: a person, by prompt Per fill or per session
What the model sees after Skyvern: typed values can reappear unless masked What the post-login page shows the model
Codes delivered by text Not covered Who types it, and on which screen

What changes when the code arrives by text message or push?

The fill has nowhere to come from. A time-based code is computed from a stored credential, so a manager or framework that holds the credential can produce it. A text message or a push approval goes to a device the agent does not hold, so the person reads it and acts: the agent pauses, the person types the code or taps approve, and the run resumes. Whether that handover is a documented takeover step varies by product and is not described in the pages reviewed, so test each framework with a text-message login and watch what the model is shown next.

The handover is where the code can reach the model. If the person types it into the agent's own browser window, the digits are in the page until the form is submitted, and a framework that reads page text or takes screenshots can pass that page to the model. A code on screen for ten seconds is a weak credential; the page that confirms the login and lists the account's details is not, and it arrives next. An agent connected to a mailbox can read an emailed code itself, which removes the person from the step; Is It Safe to Let ChatGPT Work Access Sensitive Company Data? records that OpenAI's help page says an agent with connected apps can access sensitive data like emails.

Where a service offers delegated access, the code question disappears. Arcade's write-up on agent authorization says that "when the agent needs Slack access, that's when you handle the OAuth flow," a route in which the person consents once and the agent holds a scoped token afterward; the write-up concerns tokens for API calls through connectors and does not describe what a model reads on a browser page (Arcade, 2025). A handover is a life-cycle control rather than a model control, the kind NIST's adversarial machine learning taxonomy says it identifies across the life cycle of AI systems (NIST, 2025).

Where could the code still surface after it is filled?

In three places: the page text after the fill, the screenshot of the form, and the recording of the session. A placeholder covers the moment of the fill, and the vendors that document placeholders add a caveat. Skyvern's page states that "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," which means the fill and the afterimage are governed by different settings, and the masking applies to values Skyvern typed, not to whatever a post-login page displays (Skyvern, 2026).

Browser Use's template makes the same point from the other side: it recommends setting use_vision=False "to prevent screenshot leaks," which closes the screenshot route for a filled value and also removes the model's view of the page image for the rest of the run (Browser Use, Sensitive, 2026). Its cloud documentation adds that "Zero Data Retention (ZDR) projects never record, even when recording is requested," which is the control for the third place, and it describes the recording and not the model's input (Browser Use, Secrets, 2026).

For a code, the afterimage matters less than it does for a password. A time-based code in a recording has expired by the time anyone reads it, and an accepted one-time code cannot be accepted again. What the recording and the screenshot also hold is the page after login: the account name, the organization, the billing contact, the list of API keys, whatever the console shows. That is the value that survives, and a team that has closed the code question should look at the same three places for the pages that follow it.

Why does the session matter more than the code?

Because the code is spent and the session is not. A session cookie, a remembered device or a key created during the run outlives the code. A study of browsing agents reports "prompt injection, domain validation bypass, and credential exfiltration" among its findings and demonstrates "how untrusted web content can hijack agent behavior," and a hijacked agent already past the second factor acts inside the session (Mudryi et al., 2025).

Durable credentials can also be memorized. A study of neural code completion tools found they "can not only return the precise piece of their training data" and reports that "two valid credentials were identified during our experiments," the fate of a durable credential that reaches a model's data and not of a code that expired before the next request (Huang et al., 2024).

The question for the session is the one Arcade frames: "Can this agent, acting for this user, perform this action on this resource?" (Arcade, 2025). An agent signed in with a person's second factor inherits that person's permissions, so Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? applies in full to the account the code unlocks. Where a platform holds the credential centrally, the session can be scoped in advance; Does AWS Bedrock Keep Company Credentials Away From Agents? records AWS's statement that centralized credential management removes the need to embed credentials in agent code. NVIDIA's OpenShell architecture page states that its sandbox "shares the boundary with the untrusted agent, so it never makes policy decisions," which governs sandboxed commands and does not describe a browser page (NVIDIA, 2026).

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 ACCT_001 for an account number or KEY_001 for a key shown on a console. 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 it covers the pages after the code. The fill itself is handled by the manager or the framework, and the governed environment does not need to see the code either. What it changes is the next page and every page after it: the account summary, the key list, the billing record and the member directory reach the model with the values the policy names replaced, whether the person typed the code in a handover or a manager filled it. A code that reaches the model through a handover is spent; an account page that reaches the model is not. The record also shows what the model was shown on each page, which none of the placeholder mechanisms reviewed describes for pages after login.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a code pasted into a shell or an API token used from a script is outside it. A team that uses a manager for the fill, a governed environment for the pages and a scoped session for the permissions has closed three different routes.

Methodology and limitations

This page rests on the public documentation and press releases of 1Password with Browserbase, Browser Use, Skyvern, Arcade and NVIDIA for the vendor material, two research preprints, one NIST publication 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. Where a vendor page covers a mechanism in general, such as placeholders for typed values, the page is cited for that mechanism and not for a claim about time-based codes in particular unless the page makes one.

RedactSure did not test any of the frameworks hands-on, and no sign-in with a second factor was run for this page. "Not described in the pages reviewed" means the pages reviewed and nothing broader; the handover of a text-message code in particular should be tested in each product a team uses. Vendor features change, and the page carries its date. The research preprints concern browsing agents and code completion tools in general and are cited for the principle, not for a measurement of any product named here. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as a time-based code filled into a developer console's sign-in form, and not organizations.

Determinations about whether a sign-in flow meets a legal, contractual or regulatory requirement, including any rule on multi-factor authentication for a given class of system, 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 its own login, repeated after each release of the framework and the manager, since a change to either would change the answer. The date on this page marks when the documents were read.

What the record shows

The vendor pages answer the title question by describing where the fill happens. A manager or framework that holds the credential can produce and fill the code after the model has decided to submit, and the vendors that document the design say the model receives a placeholder. A code delivered by text has no such path and is typed by the person in a handover, where the next page is what the model reads. In both cases the code is spent at once, and the research record on hijacked agents and memorized credentials points at the durable things: the session, the saved password, the key created during the run. None of the placeholder mechanisms reviewed describes what the model is shown on the page after login, which is the page that holds the account. One sign-in with a second factor on a test account settles it for a given agent: capture what the model received on the code step and on the page that followed, and compare the two.

Frequently asked questions

Can a browser agent get past two-factor authentication without seeing my codes?

Yes, for a time-based code, when a manager or the agent framework holds the credential and fills the code after the model's decision; Skyvern and Browser Use document placeholders in the model's input, and 1Password with Browserbase describes a fill the model never reads with a person approving it. For a text-message code the person types it in a handover, and the model may read the page it was typed on. In either case the account page that opens next is the one worth looking at.

Does the agent see a code that I type during a handover?

It can. When a person types a code into the agent's own browser window, the digits are in the page until the form submits, and a framework that passes page text or screenshots to the model can pass that page along with everything else on it. The code expires within a minute and was accepted once, so what the model gains is small. The page that confirms the login is what the model reads next, and that page holds the account.

Is a one-time code worth protecting at all?

Less than a password, and far less than the session. A time-based code expires in seconds and a one-time code is spent on use, so a model that read one cannot replay it. A password or key that reaches a model's data can be returned later, and a session cookie or remembered device keeps working after the code is gone. Spend the effort on the session's scope and lifetime, on the pages the model reads inside it, and on the record of what it was shown there.

Which setting hides the code from screenshots?

In Browser Use, use_vision=False, which the sensitive data template recommends to prevent screenshot leaks; it also removes the model's view of the page image for the rest of the run. In Skyvern, Mask Secrets, which the credentials page says hides a typed value in later screenshots and page text. Both cover values the framework typed, so test what a screenshot of the post-login page shows before relying on either for anything but the fill.

Can an agent with mailbox access read the code itself?

If the code is emailed and the agent's connected apps include the mailbox, yes, and the person is then no longer part of the step. OpenAI's help page for its agent says that with connected apps the agent can access sensitive data like emails, files or account settings. A second factor that the agent can read by itself is a second password, so keep the delivery channel on a device or account the agent does not hold.

What should a security team ask for in writing?

Ask where the fill happens and whether the model's input carries a placeholder or the digits, who approves a fill and whether approval is per fill or per session, what the model is shown on the page after login, whether screenshots and recordings are on, and what scope and lifetime the session has. Ask what happens when a code arrives by text, and who types it. Ask for the answers against a named version of the framework and the manager, because the next release may change the fill.

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 the Page After a Second Factor Away From the Model

The vendors reviewed above fill the code where the model cannot read it, but none describes the account page that opens once the code is accepted.

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

Before: the manager fills the code, the account page renders, and the model reads the organization name, the billing contact and every key listed. Inside the governed environment: the fill is unchanged, the page reaches the model as ACCT_001 and KEY_001, and its one change waits for a named person's approval.

RedactSure is deploying now with enterprise and government customers. Browser Use recommends use_vision=False to prevent screenshot leaks.

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

See it on your own workflow

Passing the second factor is the easy part, and the risk sits on the account page that opens after it. Bring a sign-in your agent already handles and see, with test values, what the model reads once that page loads. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.