Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Browser Agent Read My Session Cookies?

An agent attached to your browser profile uses your session cookies, which is the point of attaching it, and an agent with a script tool can read any cookie the site did not mark HttpOnly. Treat the live session, not the password, as the credential the agent holds, and decide which sites it may carry that session to.

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

A browser agent that connects to an existing Chrome profile inherits whatever that profile is logged into, because the login lives in cookies and the cookies live in the profile. That is the feature the vendors advertise, and it is also the answer to the title question: the agent does not need to read the cookie to use it, and where a cookie lacks the HttpOnly flag, a script the agent runs can read its value as well. The password managers and placeholder mechanisms that protect the typed password at login do not govern the session the login creates. This page takes one record type as its example, a billing console session for a customer account that an agent reuses after a person signed in. This means a control approved for the login does not answer for the session: what Browser Use, Skyvern and 1Password document stops at the login step, so a team has to decide how to scope and record a reused session and what untrusted content can make the agent read on the rendered page. Can a Browser Agent See My Password When It Logs In? covers the typing moment; this page starts the moment after.

Key findings

  • Browser Use's real browser documentation says the connection "allows you to automate your existing Chrome browser, so you are already logged into your websites," and that it preserves "login sessions, cookies, and extensions for authenticated tasks," so every open session is in reach (Browser Use, Real, 2026).
  • Browser Use's sensitive data template states that "the LLM only sees placeholders (x_user, x_pass)" and that "real values are injected directly into form fields after the LLM call," a control on the typed value and not on the session cookie that the login then sets (Browser Use, Sensitive, 2026).
  • 1Password says "the AI 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 login and not the session it creates (1Password, 2025).
  • A study of browsing agents reports "prompt injection, domain validation bypass, and credential exfiltration" and shows "how untrusted web content can hijack agent behavior," the route by which a held session is spent (Mudryi et al., 2025).
  • A governed environment replaces values chosen by policy with consistent tokens before any model reads the screen, so the account record a session unlocks reaches the model as ACCT_001 and not as the customer's data (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the values the model worked on were placeholders (What Is a Tethered Agent?).

Why does an agent attached to a browser profile hold the session?

Because a session is a cookie, and a cookie is a file in the profile. When a person signs in to a billing console, the site sets a session cookie, and every later request from that profile carries it. An agent that connects to the same profile sends the same cookie on every request, so the console treats it as the signed-in person. Browser Use documents this as the purpose of its real browser mode: the connection "allows you to automate your existing Chrome browser, so you are already logged into your websites" (Browser Use, Real, 2026). The same page says the mode preserves "login sessions, cookies, and extensions for authenticated tasks."

The scope for this page is the rendered page. A governed browser environment covers what an agent reads and does on a page, including dashboards, consoles, settings pages and sign-up forms, and does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent in an attached profile goes anywhere its supervisor could go and does real work there at machine speed; the tethered agent definition describes authority rather than capability.

The record type for this page is one billing console session for one customer account. A person signs in, then hands the profile to an agent to reconcile an invoice. The agent never typed the password, so no placeholder mechanism was involved, and the session cookie is the only credential in play. Everything the console renders for that account, the billing address, the card on file, the invoice history, is available to the agent while the cookie is valid, and the agent needs none of the cookie's bytes to use it. Using the session is routine; reading the cookie is the narrower question taken up below.

What do the vendors themselves say?

Browser Use's sensitive data template says "the LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text," and "real values are injected directly into form fields after the LLM call," which governs the typed password and not the session cookie the site sets after the form is submitted (Browser Use, Sensitive, 2026). It advises "Use Browser(allowed_domains=[...]) to restrict navigation," which limits where a held session can be carried. Its cloud secrets guidance states that "Zero Data Retention (ZDR) projects never record, even when recording is requested," a control on storage after the run, not on what the session reached (Browser Use, Secrets, 2026).

Skyvern's credentials documentation says "the model that drives the browser gets placeholders, not your values," and "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," so the masking follows a typed value and not a session (Skyvern, 2026). It adds that connected vaults are read at run time, the moment of login.

1Password describes injection "if, and only if, the human approves the access," so the approval governs the login, not the pages the session then opens (1Password, 2025). A control on the session cookie after login is not described in the pages reviewed for any of them.

Dimension Browser Use and Skyvern, per their documentation What a buyer should verify
Typed password Placeholders; value injected after the model call Where the session cookie then lives
Attached profile Preserves login sessions and cookies Which sites are signed in before the agent starts
After the run ZDR projects never record What the model read during the session

Sometimes, and it matters less than the question suggests. A cookie the site marks HttpOnly is withheld from page scripts, so a script tool the agent runs cannot read it. A cookie without the flag is readable by any script on the page, including one the agent runs. The flag is the site's decision, and a team can check its own console in the browser's storage inspector. The cookie store on disk is a profile file the operating system usually encrypts, so a browser agent reaches it through the browser rather than the file.

The value matters less than the use because the agent does not need the value. Every request through the attached profile carries the cookie, and an attacker who hijacks the agent gains the same thing: requests sent as the signed-in person, the session's whole authority, without seeing the cookie's bytes. The Model Context Protocol's security guidance makes the general point for tokens: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," and "poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026). A session issued to a person and spent by an agent is a token used by a party it was not issued for, with the compromise impact its scope allows.

The same guidance says to "warn that MCP servers run with the same privileges as the client," which is the shape of the problem on a console: the agent runs with the person's privileges, and the pages those privileges open display sensitive data. The agent reconciling one invoice holds a session that can also open the card on file, the admin settings and the API key page. What Can an AI Agent See in Your GitHub Settings? walks through the equivalent on a repository settings page.

What can untrusted content do with a reused session?

Spend it. Mudryi, Chaklosh and Wojcik report "prompt injection, domain validation bypass, and credential exfiltration" among their findings on browsing agents, and show that "untrusted web content can hijack agent behavior" (Mudryi et al., 2025). A billing console is a web page, and a page an agent reads can carry instructions. If the agent holds a live session when it reads them, they run with that session's authority, and the attacker needs neither the password nor the cookie.

Rates seen elsewhere suggest the risk is not marginal. In agentic coding editors, Liu, Zhao, Lyu and colleagues report that "attack success rates can reach as high as 84% for executing malicious commands" (Liu et al., Your, 2026). The setting differs and the abstract gives no trial counts or tool versions, so the figure is a signal about the class, not a measurement of any browser agent. On the defense side, Liu, Jia, Geng and colleagues evaluated "5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks" and offer "a common benchmark for quantitatively evaluating future prompt injection attacks and defenses," an instrument for a team that wants to test its own agent (Liu et al., Formalizing, 2024).

What an exfiltration collects is set by what the session unlocks. Sonatype's package research found that "56% of the malware discovered in Q1 2025 was related to data exfiltration," up from 26% in the prior quarter (Sonatype, 2025). That figure concerns open source packages, not browser agents, and carries no credential-theft breakdown; it is cited for the direction of travel. For the billing console record, the direction is the account data the session unlocks.

How should a team scope and record a reused session?

Start with which session. Least privilege governs actions and credentials, not the content of the screen an agent reads, so an agent can satisfy it in full and still hold every record it was shown (What Is Least Exposure?). A reused session is the clearest case: the agent inherits the person's privilege whole, and the screens it opens carry whatever the person could see. Sign in with the narrowest account the task permits and sign out of everything else before the agent starts.

Withhold the administrator session. Google's Workspace guidance states that the super admin account should be used only when needed, a rule for people that applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). AWS strongly recommends not creating access keys for the root user, which closes the simplest route to durable top-level power (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). An admin session in an attached profile is the browser form of both.

Then record. 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; its pages describe the login step rather than sessions already open (Does Claude in Chrome Use Your Saved Logins and Open Sessions?); What Can Claude in Chrome Access in Your Browser? lists its reach. For the billing console record, settle in writing which account was signed in, which domains the agent could reach, what each screen showed the model, and who approved the change to the invoice.

What does a governed environment change?

A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the customer on the billing console reaches the model as ACCT_001 on every screen, with the card on file and the billing address replaced the same way each time. 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, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For the session cookie question, it changes what the session is worth to an attacker. The session still carries the person's authority, and the agent still uses it on every request, because that is what makes the task possible. What changes is what the model holds while it does so: a hijacked agent that is told to repeat the account details repeats tokens, and a request it is told to send to a destination outside the policy does not resolve the real values, because the approved destination is the only place they resolve. The record then shows which screens the model saw, as tokens, and which action a person approved, which is the written answer to the scoping questions above.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, and it does not alter which cookies the site marks HttpOnly or which sites the agent may navigate to; those stay with the site's settings and the agent's domain list. What it adds is the one control the placeholder mechanisms leave open: the content the session unlocks, on every page, before the model reads it.

Methodology and limitations

This page rests on the public documentation of Browser Use, Skyvern and 1Password for the vendor section, three research preprints on browsing agents and prompt injection, the Model Context Protocol security guidance, one vendor research release on malicious packages, 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, and the preprints for the findings their abstracts state. The statements about HttpOnly cookies and script access describe standard browser behavior and come from no vendor page.

RedactSure did not test Browser Use, Skyvern, 1Password or any browser agent hands-on against a live session. "Not described in the pages reviewed" means the pages reviewed and nothing broader; a vendor may document a session control elsewhere or add one later. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a billing console session for a customer account reused after a person signed in, and not an organization. The coding editor and package figures are cited for the class of risk and not as measurements of browser agents.

Determinations about whether a session arrangement meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a check of the organization's own console: which cookies carry the HttpOnly flag, which domains the agent may reach, and what the agent's trace shows it read, repeated after each release of the agent or the console.

What the record shows

The vendor pages answer the title question by what they cover. Browser Use documents an attached profile that preserves login sessions and cookies, and both Browser Use and Skyvern document placeholders for the password the agent types; 1Password documents injection on human approval. None describes a control on the session cookie the login sets, because using the session is the feature. The research record shows that untrusted page content can direct an agent holding that session, so the exposure is the content the session unlocks rather than the cookie's bytes. Substitution at render, before the model reads the page, is the control that limits what a spent session yields, and it is the one RedactSure's design is built around. To test this on a given product, name one agent, hand it one signed-in console, have it open one account record, and search its trace for the values that record displayed.

Frequently asked questions

Can a browser agent read my session cookies?

It uses them without reading them, which is the point of attaching an agent to a signed-in profile. Every request the agent makes through that profile carries the session cookie, so the site treats the agent as you. Where a cookie lacks the HttpOnly flag, a script tool the agent runs on the page can also read the value. Check your own console's cookies in the browser's storage inspector before deciding what an attached agent can take with it, and assume the session itself is in play either way.

Does a password manager protect the session?

It protects the login. 1Password describes credentials injected only when a human approves the access, and Browser Use and Skyvern describe placeholders for the typed password, so the model need not see the password. The session the login creates is then an ordinary cookie in the browser, and the agent uses it on every request. The password manager's job is done at the sign-in form, and the session's life, and the agent's use of it, begins there.

Which cookies can a script read?

Those the site did not mark HttpOnly. The flag is set by the site when it issues the cookie, and a cookie carrying it is withheld from page scripts by the browser. A session cookie on a well-configured console usually carries the flag, and other cookies on the same site often do not. The agent's tooling does not change the flag, so the answer depends on the console, and it can be read off the cookie list for that domain in a minute.

Does allowed_domains stop the session from being misused?

It narrows where the agent can navigate, which is a real limit on where a held session can be carried. It does not change what the pages inside the allowed domains show the model, and the billing console that is on the list still renders the card on file and the admin settings for a signed-in session. Treat the domain list as the fence around the task and the rendered content inside the fence as a separate question with its own control.

What should I sign out of before handing a profile to an agent?

Everything the task does not need, starting with any administrator or root session. Google's guidance says the super admin account should be used only when needed, and AWS recommends against access keys for the root user, and an attached profile with an admin session open is the browser equivalent of both. Sign in with the narrowest account that can complete the task, and keep the agent's profile separate from the one you use all day.

What record should a team keep of a reused session?

Which account was signed in, which domains the agent could reach, what each screen showed the model, and who approved each action that changed a record. The vendor pages describe recording controls and placeholders but not what the model read from a session's pages. A governed environment that tokenizes values before the model reads the screen produces that record as a byproduct, so the review can start from the trace rather than from anyone's memory of the run.

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 Limits What a Reused Session Shows the Model

An attached agent holds every page the session unlocks, and the controls reviewed above govern the login without deciding what the console shows the model.

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

Before: the agent reconciling one invoice reads the billing address and card on file in the clear, and an injected instruction can make it repeat them. Inside the governed environment: the model meets ACCT_001 on every screen, and the real values enter the invoice record only on the named supervisor's approval.

RedactSure is deploying now with enterprise and government customers. A browsing-agent study reports credentials exfiltrated through untrusted web content.

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

See it on your own workflow

A reused session shows the agent the billing details on every page it opens. Bring a signed-in task such as reconciling an invoice and see, with test values, each page as the model receives it. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.