Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an Agent Still See a Password After 1Password Fills It?
No. 1Password fills the field outside the model's view, so the password itself never reaches the agent, and what it receives is the page after login, where any part of the credential the site echoes is on screen; check what the site shows once the session opens.
A vendor portal takes a fill from 1Password, submits the form and opens on the account's dashboard, with the username in the header, the open invoices and a link to the API settings page. The reviewer's question is what the model holds now. The fill keeps the password out of the model's input: the value moves from the vault into the field, and the agent reads the page that loads next (1Password, Closing, 2025). Everything after that is a page rendered for whoever is signed in, and the model reads it like any other screen. A site that prints the username, a masked card number, a recovery code or an API token on the screen behind the login has placed that value in front of the agent, and a change form that renders the current password has placed the credential itself there. A team usually buys the fill and treats the login as settled: the fill settles one field, and the session it opens carries the person's authority to every page behind it. A support console that prints the customer's email address in a banner has already shown the agent half of the login pair, and no fill setting changes the banner.
Key findings
- For a filled login to keep the agent from reading any part of the credential, the values on the page that follows would have to be replaced with consistent tokens before the model reads it; the fill covers the field, not the screen (What Is Least Exposure?).
- It would also require a named person approving each action taken behind the login and a record of what the model received, because the session carries the person's authority past the password (Can a Browser Agent Read My Session Cookies?).
- The published record covers the fill and the vault; it does not describe replacing the values on the page that follows before the model reads it (1Password, Closing, 2025).
- 1Password's browser post 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, Closing, 2025).
- Anthropic's help page states that "1Password fills the login directly, and your passwords and one-time codes never enter Claude's context" while the browser "takes screenshots of your active browser tab" (Anthropic, Use, 2026).
- The 1Password and Browserbase announcement says agents "authenticate with web services without ever exposing credentials," and gives no detail on the fill (1Password and Browserbase, 2025).
What does the model receive when 1Password fills the login?
1Password documents the fill at the field. Its post on browser agents says the credential is injected "if, and only if, the human approves the access," and that "the AI agent and underlying LLM never need to see nor handle the credentials" (1Password, Closing, 2025). The screen that loads after the form submits is a separate question.
What the model receives is the page. Anthropic documents both halves on one help page: "1Password fills the login directly, and your passwords and one-time codes never enter Claude's context," and "Claude takes screenshots of your active browser tab" (Anthropic, Use, 2026).
1Password's product page describes the custody side: agents are issued access "at runtime, scoped to the task, and revoked when the work is done" through "encrypted credentials that are retrieved from a managed vault at runtime" (1Password, Secure Agentic AI, 2026). That is how a credential is held, not what a model reads.
The scope is the rendered page: a dashboard, a console, a settings page or a sign-up form, not the terminal, the IDE, the local filesystem, direct API calls or MCP. The fill answers the login half (Can a Browser Agent See My Password When It Logs In?); Can an AI Agent Set Up a SaaS Account Without Seeing the Password? works the same distinction through a sign-up form.
What is on the screen once the fill opens the session?
The record here is a vendor portal that shows the account's username on its dashboard. The agent reaches the login, the vault fills the field, the form submits, and the dashboard loads. From that point the model's input is the rendered page: the username in the header, the account's masked payment method, the open invoices, the support contact and the link to the API settings page. None of it came from the password manager; all of it arrived because the login succeeded.
The session is the reason. A fill completes a login, and what the agent holds afterward is the authenticated session, with every page the account can open. Can a Browser Agent Read My Session Cookies? sets out how much of that session is readable; here the session is the door and the page is what the model sees through it.
The page is in the model's input because the browser puts it there. Anthropic's help page says that "whatever is visible in one of those tabs is captured in the screenshots and becomes part of the conversation" (Anthropic, Use, 2026), on the same page that lists the manager fill. Dia's security page describes the same split, with "web form fields like passwords" invisible to the agentic system and the page content sent to a third-party model (The Browser Company, 2026).
What do the vendors themselves say?
1Password documents the fill, the vault and the runtime access around them. Its browser post gives the fill's condition, human approval, and its result, credentials the model never handles (1Password, Closing, 2025). Its product page describes issuing agents access "at runtime, scoped to the task, and revoked when the work is done" (1Password, Secure Agentic AI, 2026). The 1Password and Browserbase announcement states that credentials "are not shared with the LLM or exposed in Browserbase logs and repos" (1Password and Browserbase, 2025). Each sentence is about the credential; none of them describes what the model receives on the page that follows. Anthropic documents the page side: its help page says the manager fills the login so that "your passwords and one-time codes never enter Claude's context," and that the browser puts what is visible in the active tab into the conversation (Anthropic, Use, 2026).
| Dimension | 1Password, per its documentation | What a buyer should verify |
|---|---|---|
| Where the fill acts | The credential is injected only when a person approves the access (1Password, Closing, 2025) | Which component performs the injection, and what it can read |
| What the model receives | "The AI agent and underlying LLM never need to see nor handle the credentials" (1Password, Closing, 2025) | Whether that covers the page after the login |
| What is held for the agent | Access issued "at runtime, scoped to the task, and revoked when the work is done" (1Password, Secure Agentic AI, 2026) | Whether the browser session is scoped and ended the same way |
| What follows the login | Not described in the pages reviewed for the fill | What the dashboard, settings and token pages render |
The fourth row decides the answer. 1Password's pages are precise about the credential and say nothing about the screen, and Anthropic, which documents both halves, puts the screen into the conversation.
When does the screen after the fill carry part of the credential?
When the site puts it there. The fill keeps one value out of the model's input and does nothing about what an application chooses to display to a signed-in user. That line between the credential and the page holds across the agent market: 9 of the 15 AI agents a review examined describe keeping passwords or credentials away from the model, and none describes replacing customer data on a page with tokens the agent can work with (Do AI Agents Ask Before Making a Payment?). Four ordinary screens do exactly that. A dashboard header that prints the username or email address shows half of the pair a login uses. A settings page that lists an API token, a recovery code or a webhook signing value shows something the agent can use directly. A change-password form that pre-fills the current password, or a reveal control that displays it, shows the credential itself. A confirmation screen that repeats the account identifier shows the other half. The page was written for the account holder, and the agent now holds that seat.
The attack record explains why the difference matters, because a page the agent reads after login can carry instructions as well as data: EchoLeak, the first real-world zero-click prompt injection in a production LLM system, turned on a client that "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025). The model did not need the password to be steered, only the page. A value the page prints enters the model's input the moment it renders (How Do I Capture a Token the Moment It Appears on Screen?).
What should a security team ask for in writing?
Start with the screen, because the vendor's page already answers the fill. Ask what the model receives from the rendered screen after the login succeeds: the header, the settings page, the token list, the masked payment method. Ask whether the browser session is the person's own or one created for the agent, and how it ends. Ask who approves the actions taken behind the login, and where the approval is recorded.
The approval question has a standard behind it. OpenAI's governance paper calls human approval "a standard way to limit egregious failures" (Shavit et al., 2023), so ask what the approver sees before an action runs: a prompt that approves a login is not an approval of the payment that follows it.
The record question has one too. AWS's guidance states that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026), and that is the property to require: an entry for the fill, one for each action behind it, and a distinction between agent and person.
1Password's developer material shows the same substitution at a request boundary: inside its sandbox "the agent sees placeholders rather than real credentials," and a gateway replaces a placeholder "only when the agent sends a request to an approved host" (1Password, Workflows, 2026). Ask whether the browser integration has an equivalent for the values a page renders.
Is It Safe to Let a Browser Agent Use My Saved Logins? covers the same questions for a saved login.
What does a governed environment change?
A governed environment acts on the rendered page, before any model reads it. Values a policy names are replaced with consistent tokens for the whole run, so the model works on placeholders; the real values resolve only at the approved destination, at the moment of an approved action. A named person approves each consequential action, and every screen, action and approval is written to a record that exports to the organization's own monitoring.
For the filled login that changes both halves. The field receives a token such as CRED_01, the real password is substituted at submission to the approved destination, and the dashboard that follows renders the username, the payment method and the token list as tokens too. The session is scoped to the task rather than borrowed from a person.
The fill keeps the password out of the model's input at the login; the governed page keeps the rest of the screen out of it afterward. What Is Least Exposure? sets out why least privilege does not cover this ground on its own: it governs actions and credentials, not the content of a screen. RedactSure vs 1Password: 2026 Comparison & Alternative places the two designs side by side for a buyer, and What Is a Tethered Agent? describes the session that reaches where the person could go.
What the record shows
No, not the password: a fill places the value in the field, and the model's input begins with the screen that follows, the dashboard, the account menu, the settings page and any part of the credential the site prints there. The documented mechanism is narrow by design, one value kept out of the context, and the session that replaces it carries the person's authority to every page the account can open. A security team can run this test on its own sites by naming one login and one dashboard, capturing the first screen the model receives after the fill, and comparing that capture with what the same page shows a person.
Methodology and limitations
This page rests on vendor documentation from 1Password and Anthropic, one attack paper, one governance whitepaper and one cloud provider's guidance, plus existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries its date. Quotations are the vendors' own sentences, cited to the page that carries them.
None of the products on this page was tested for it. "Not described in the pages reviewed" means the pages in the Sources list and nothing broader; a vendor may document the behavior elsewhere. The 1Password and Browserbase announcement is a press release and is read as one. The example describes a record type, a vendor portal that shows the account's username on its dashboard, and not an organization.
RedactSure is deploying now with enterprise and government customers. Determinations about whether a login arrangement meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Can an agent still see a password after 1Password fills it?
No. 1Password's post says the credential is injected "if, and only if, the human approves the access" and that "the AI agent and underlying LLM never need to see nor handle the credentials," and Anthropic's help page says the manager fills the login so the password never enters Claude's context. What the agent sees is the page that loads afterward. Whether that page carries part of the credential depends on the site, not on the fill.
What does the agent read on the page after a filled login?
The rendered page, which is the dashboard, the account menu and whatever else the site shows a signed-in user. Anthropic's help page states that whatever is visible in the active tab "is captured in the screenshots and becomes part of the conversation", so a username in the header or a recovery code on a settings page reaches the model the way an invoice number does. The fill removes one value from that input and leaves the rest of the screen in place.
Does a username on the dashboard put a credential in the model's context?
Not the password, and it is still half of the pair a login uses. A username or email address tells an attacker which account to target and confirms that the agent is inside the right one. Paired with a recovery code, an API token or a pre-filled password field on the same screen, it is more than half. Judge the page by what it prints, not by whether the password itself is on it.
Who approves the fill, and does that approval cover the session?
The person approves the credential release, and the documentation makes that approval the condition for the injection. It does not describe an approval for each action taken after the login, so a fill approved once can sit behind a session that goes on to change a payment method or invite a user. Ask for a separate approval on the consequential action, and a record that ties each one to the person who allowed it.
What record shows what the model received after the fill?
None is described by the fill itself. The vendor pages describe the injection and the approval, not a capture of the screen the model read, and a session log that shows a login does not show the dashboard. Ask for the screen the model read, the action taken and the approval in one export. AWS's guidance puts the requirement plainly: logs that attribute every action to an agent or a human actor.
Does a governed page change what the model receives after a filled login?
It changes what the model receives on the page, not whether the fill works. A governed environment replaces the values on the rendered screen with consistent tokens before the model reads it, so the username, the payment method and the token list arrive as placeholders, while the real values resolve only at the approved destination. The password stays out through the fill, and the rest of the screen stays out through the page.
How RedactSure Keeps the Page Behind a Filled Login Out of the Model
A filled login hides one password, and the dashboard behind it arrives with every value the site prints.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent signs in through the fill and the portal opens, so the model reads the username, the masked payment method and the token list. Inside the governed environment those values render as tokens, the real values resolve only at the approved destination on a named person's approval, and each screen and approval lands in the record.
RedactSure is deploying now with enterprise and government customers. Anthropic's page says the active tab's visible content becomes part of the conversation (Anthropic, Use, 2026).
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A filled field hides one value, and the dashboard behind it is what the agent works from all afternoon. Bring a login your agent performs and see, with test values, what the model reads after the fill. Book a demo