Data Report · By Chris Sowa · Published
Last updated
Does Claude in Chrome Use Your Saved Logins and Open Sessions?
Anthropic documents that Claude in Chrome runs inside the user's Chrome and can request logins from 1Password; whether it acts within sessions already signed in is not described in the pages reviewed, and because it runs in the user's own browser that should be assumed until verified. Check which signed-in work applications are reachable from that profile.

Anthropic documents that Claude in Chrome runs inside the user's Chrome and can request logins from 1Password; whether it acts within sessions already signed in is not described in the pages reviewed, and because it runs in the user's own browser that should be assumed until verified. Check which signed-in work applications are reachable from that profile. The question matters because a browser session is a credential. An employee who has signed in to a support console, a payroll system and a cloud console that morning has three open sessions in the same Chrome profile, and an agent that operates that profile does not need a password to reach any of them; the cookie is already there. Anthropic's documentation describes a password manager integration for sites that ask for credentials, and is silent, in the pages reviewed, on sites that do not ask because the user is already in. OpenAI's documentation for ChatGPT Work shows the other design, a cloud browser of the agent's own that cannot reach local sessions. This page sets out what Anthropic's documentation says about logins, why running inside the user's profile matters for open sessions, how a separate cloud browser differs, what an agent with the user's sessions means for identity and attribution, what an organization should verify, and the claims a buyer should refuse. It builds on the general treatment of AI agent session isolation.
Key findings
- Anthropic's help center states that Claude in Chrome sees what is on the page and can act on it, defaults to an automatically approve mode that pauses when needed, and can request logins from 1Password; use of sessions already open in the browser is not described in the pages reviewed (Anthropic, 2026).
- Anthropic publishes a permissions guide and a page on safe use for Claude in Chrome, which describe site-level permissions and user practices rather than a session boundary between the agent and the user's signed-in applications (Anthropic, 2026).
- OWASP's session management guidance treats the session identifier as a credential for its lifetime, which means an agent acting within an open session is using a credential whether or not it ever saw a password (OWASP, 2024).
- OpenAI's documentation for ChatGPT Work states that website sign-in through the cloud browser is not available in Enterprise or Edu workspaces, and that allowing a website does not approve every action on that site, so the agent's browser is separate from the user's and sign-in is an administered choice (OpenAI, 2026).
- Anthropic reports that Claude asks users before high-risk actions like publishing, purchasing or sharing personal data, and that mitigations cut prompt injection success from 23.6 percent to 11.2 percent, (Anthropic, 2025).
- Agents open two gaps in the security stack, one in what reaches the model and one in whose identity the actions carry, and an agent in the user's own sessions sits in both (What Two Gaps Do AI Agents Open in the Security Stack?).
What does Anthropic's documentation say about logins?
Anthropic's getting-started page states that Claude sees what is on the page and can act on it, that the side panel defaults to an automatically approve mode that pauses when needed, that the extension can request logins from 1Password, and that it is available on all paid plans (Anthropic, 2026). The 1Password integration is the documented path for a site that asks for credentials: the agent requests the login from the password manager rather than asking the user to type it. The permissions guide (Anthropic, 2026) describes which sites the agent may act on, and the page on using Claude in Chrome safely (Anthropic, 2026) describes practices for the user.
What the pages reviewed do not address is the case where no login is requested because the user is already signed in. A browser extension operates within the browser profile it is installed in, and a profile carries the cookies and tokens of every session the user has opened. Whether Claude in Chrome acts within those sessions, whether it can be prevented from doing so for particular sites, and whether the user is told when it does are not described in the pages reviewed. This page does not state that the extension uses open sessions; it states that the documentation reviewed does not say, and that the architecture makes it the question to ask.
The distinction between a saved login and an open session is worth keeping. A saved login is a credential in a vault, and the 1Password integration is a documented, mediated path to it. An open session is a credential already in the browser, needing no mediation. The first is described; the second is the subject of this page.
Why does running inside the user's Chrome profile matter for open sessions?
OWASP's session management guidance treats the session identifier as a credential equivalent to the password for its lifetime, to be protected from exposure, bound to the user and terminated deliberately (OWASP, 2024). An agent operating in the browser that holds the identifier is operating with the credential. It did not see a password, and it did not need one.
Take a single record type: a customer account in a web-based support console, which the support agent signed in to at the start of the shift through the organization's single sign-on. The page shows the customer's name, email, phone, plan, payment method on file and ticket history. The employee asks Claude in Chrome to find the customer's last three tickets and draft a status update. If the extension acts within the open session, it navigates the console as the employee, reads the account record, and drafts the update, with no login step and therefore no 1Password request, no pause and no indication to any system that a model rather than a person was reading. The console's own log records the employee.
The same profile holds the other sessions of the day. If the task leads the agent to the payroll system, or a page it reads contains an instruction to visit one, the session there is open too. The prompt injection risk OWASP describes, in which content the model reads is treated as instruction (OWASP, 2025), is bounded in a cloud browser by what that browser can reach; in the user's profile it is bounded by what the user has signed in to. Anthropic's measured injection rate after mitigations, 11.2 percent (Anthropic, 2025), is the rate at which that boundary may be tested.
How does a separate cloud browser differ?
OpenAI's ChatGPT Work takes a different architectural position. Its documentation states that website sign-in through the cloud browser is not available in Enterprise or Edu workspaces, and that allowing a website does not approve every action on that site (OpenAI, 2026). The agent works in a browser of its own, in the vendor's cloud, with no access to the cookies in the user's Chrome, and in the enterprise tiers an administrator rather than an employee decides what it can reach.
| Dimension | Claude in Chrome, per its documentation | ChatGPT Work, per its documentation | What a buyer should verify |
|---|---|---|---|
| Where the agent's browser runs | Inside the user's Chrome | A cloud browser separate from the user's | Which sessions each can reach |
| Saved logins | Can request logins from 1Password | Website sign-in through the cloud browser not available in Enterprise or Edu workspaces | Who decides which sites the agent may sign in to |
| Open sessions | Not described in the pages reviewed | Not reachable, since the browser is separate | Whether any session boundary exists in the user's profile |
| Site allowance and actions | Site permissions, per the permissions guide | Allowing a website does not approve every action on that site | How actions are approved once a site is allowed |
Neither position is free. The cloud browser cannot reach local sessions, which is the point, but it also cannot work inside the applications the employee is already using without an administered sign-in. The in-browser extension can work anywhere the employee can, which is its usefulness and its exposure. AI agent session isolation sets out the general case, and setting up S3 with GitHub using OIDC rather than keys shows a workflow designed so the agent's session is its own.
What does an agent with the user's sessions mean for identity and attribution?
NIST's digital identity guidelines treat authenticators as protected elements of the identity lifecycle, bound to the subscriber who holds them (NIST, 2025). A session established through single sign-on is the product of those authenticators, and every action taken within it is attributed to the person who authenticated. An agent acting within that session inherits the attribution. The support console's log, the payroll system's log and the identity provider's log all record the employee, with no field for the fact that a model was at the controls.
That has two consequences. First, an action the agent takes that the employee would not have taken, whether through error or through an injected instruction, carries the employee's name, and an investigation cannot distinguish the two from the application's own records. Second, the organization's identity controls, which were designed around the question of who authenticated, have no purchase on the question of what is acting. Multi-factor authentication was satisfied at sign-in; the agent arrived afterward. The page on the two gaps agents open in the security stack names this as the identity gap, alongside the data gap of what reaches the model.
The in-browser design also decides what the model reads. Working inside the employee's session, the agent reads the customer account as the console renders it for the employee: name, email, phone, payment method. Whether that content should reach a model at all, and under which model vendor's terms, is the subject of whether open-weights models can work on regulated records; the point here is that the session question and the data question arrive together, because the session is what puts the page in front of the model.
What should an organization verify before enabling it?
The first verification is empirical. Install the extension in a test profile, sign in to one work application through the organization's single sign-on, close the application tab, and ask the agent to retrieve a record from that application. If it does so without a login step, the extension acts within open sessions, and the organization has its answer. If it requests a login, the documentation's silence has been resolved the other way for that configuration. Either result should be recorded with the extension version and the date, since the behavior may change.
The second concerns the profile. Which work applications are signed in during a typical day in the profiles where the extension would run, and which of those hold regulated or confidential records? The answer bounds what an agent in that profile could reach. Press reporting that Claude in Chrome was taking orders from other browser extensions (CSO Online, 2026) adds a third item: which other extensions are installed in those profiles, since they too are inputs to the agent.
The third concerns controls. Site permissions, per the permissions guide, decide where the agent may act; the organization should decide whether the applications holding sensitive sessions are permitted at all, and the safe-use guidance should be read for what it asks of the user. The approval mode should be examined for which actions pause, since Anthropic documents a pause before high-risk actions like publishing, purchasing or sharing personal data (Anthropic, 2025), and reading a customer record is none of those. None of these verifications requires the vendor's cooperation; they require an afternoon and a test profile.
What does a governed environment change?
In a governed environment, the agent does not run inside the user's own Chrome profile, so the open sessions and saved logins in that profile are not available to it by default, and anything it reaches through a session is tokenized before the model reads it.
The mechanism is a class of control that separates the agent's browser from the employee's and governs what happens inside it. Sensitive values on the rendered page are replaced with consistent tokens before any model reads them, so a signed-in application's records reach the model as tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging, so the record separates the agent's actions from the employee's.
This answers the two questions the previous section said to carry into an evaluation. Anthropic documents that the extension sees what is on the page, can act on it and can request logins from 1Password, while use of sessions already open is not described in the pages reviewed (Anthropic, 2026). OWASP treats a session identifier as a credential for its lifetime (OWASP, 2024). An environment that holds its own sessions under administered sign-in, and tokenizes pages before the model reads them, removes the dependency on a vendor statement about session behavior.
The control does not change the extension, the applications, the user's permissions or the model; it changes where the agent runs and what it holds while it works.
Where does RedactSure sit?
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design gives the agent a session of its own: it works in a governed environment in the customer's cloud, not in the employee's Chrome profile, so the employee's open sessions and saved logins are not reachable and the identity the agent acts under is the environment's, recorded as such. Values are substituted at the render layer before any model reads the screen, so the customer account arrives as CUST_001 with EMAIL_001 and PHONE_001, with the same token for the same value through the whole run. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, so the record distinguishes what the agent did from what the person did. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.
Deployments are in pilot. A pilot on one support or back-office task would show the agent reaching the application under its own session, the record as the model received it, and the approval that released each action. Everyone else controls where data can go. RedactSure controls what the AI can see.
Methodology and limitations
This page rests on Anthropic's help center documentation for Claude in Chrome (the getting-started page, the permissions guide and the page on safe use) and its pilot announcement, on OpenAI's ChatGPT Work overview, on OWASP's session management cheat sheet and its Top 10 for LLM Applications entry on prompt injection, on NIST's digital identity guidelines, on press reporting by CSO Online, and on RedactSure research pages on session isolation, the two gaps agents open, open-weights models and GitHub workflows. All sources were read as of October 16, 2026.
No hands-on testing of Claude in Chrome, ChatGPT Work or any other named product was performed, and the test profile procedure described on this page was not run for it. Whether Claude in Chrome acts within sessions already open in the browser is not described in the pages reviewed, and this page frames it as a question to verify rather than as a finding either way; where any other control is said to be not described, that too means not described in the pages reviewed, not that the product lacks it. Vendor documentation is read as a statement of design intent rather than as test evidence. Both products change quickly, and the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The support console and customer account described here are record types, not any organization's systems, and no customer or prospect is described.
Whether an employee's use of a browser agent within the organization's authenticated sessions is permitted under its identity policy, its contracts and its regulatory obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.
What the record shows
Anthropic's documentation describes an agent that works inside the user's Chrome and reaches saved logins through 1Password; it does not, in the pages reviewed, say whether the agent acts within sessions the user already has open, and an extension in the user's profile has those sessions available by construction. A session is a credential for its lifetime, so the question is whether the agent uses a credential the user never handed it, and the applications' own logs cannot tell, since they record the employee either way. OpenAI's ChatGPT Work shows the alternative shape, a separate cloud browser that cannot reach local sessions and, in enterprise tiers, cannot sign in at all; a governed environment with a session of its own, as in RedactSure's design, is the same shape with the organization's record attached. The test is to name one work application, sign in to it in a test profile, close the tab, and ask the agent to fetch a record; the presence or absence of a login step is the answer.
Frequently asked questions
Does Claude in Chrome use my open sessions?
Not described in the pages reviewed. Anthropic documents that the extension runs inside the user's Chrome and can request logins from 1Password, but the pages reviewed do not say whether it acts within sessions already signed in. Because an extension operates in the profile that holds those sessions, an organization should assume it can until a test in its own environment shows otherwise, and should record the result with the extension version and date.
Is a saved login the same as an open session?
No. A saved login is a credential in a vault, and the documented 1Password integration is a mediated path to it: the agent requests the login when a site asks for one. An open session is a credential already present in the browser as a cookie or token, requiring no request. OWASP's session management guidance treats that identifier as equivalent to the password for its lifetime, so an agent acting within it is using a credential without any login step.
How is ChatGPT Work different on this question?
OpenAI's documentation describes a cloud browser separate from the user's, which by construction cannot reach cookies in the user's Chrome. It also states that website sign-in through the cloud browser is not available in Enterprise or Edu workspaces, and that allowing a website does not approve every action on that site. The trade is that the agent cannot work inside the applications the employee is already signed in to without an administered path, which is a limit on usefulness as well as on exposure.
Will my applications' audit logs show that an agent acted?
Not if the agent acted within the user's session. The application records the authenticated user, and the identity provider records the sign-in that created the session; neither has a field for a model operating afterward. An action the agent took, whether by design, error or injected instruction, carries the employee's name. A record that distinguishes the agent's actions from the person's has to come from outside the application.
Can site permissions solve the session problem?
They narrow it. Site permissions, per the permissions guide, decide which sites the agent may act on, so excluding the applications whose sessions hold regulated records keeps the agent out of them. That is a reasonable first step, and it depends on the list being maintained as applications change. It does not change what happens on a permitted site with an open session, where the agent reads the page as the signed-in user with no login step.
What is the quickest way to get an answer for my organization?
Install the extension in a test profile, sign in to one work application through single sign-on, close its tab, and ask the agent to retrieve a specific record from that application. If it returns the record without a login step, it acts within open sessions in that configuration. Record the extension version and the date, since behavior may change, and repeat the test after updates. No vendor cooperation is required.
Book an AI Agent Security Review →
Bring your hardest questions.
Bring one sensitive workflow and the decisions your team needs to keep in its hands.
Book a demo









