How to Isolate Browser MCP Sessions from User Cookies and Saved Passwords

How a browser MCP session ends up with user credentials

A browser automation MCP server gives an agent tools such as navigate, click, type and read page content. Whatever browser those tools drive defines what the agent can see. If the browser runs against a person's real profile, the agent inherits that profile: logged-in session cookies, saved passwords, autofill entries and authenticated SaaS sessions. The agent does not need to steal anything. It simply operates inside a session that is already trusted.

Three patterns create this exposure. The first is attaching to an already running browser, where the agent joins a session the user opened and authenticated. The second is launching a browser against the default profile or a persistent user data directory that holds real state. The third is leakage through autofill or a built-in password manager, where a form the agent visits is populated with credentials the agent never requested. Check how your chosen server is configured for each pattern rather than assuming a safe default.

The risk is not theoretical. OWASP's exploit roundups describe browser agents with access to authenticated web sessions being redirected by attacker-controlled content, with user data and connected-account data exposed. One technique framed browser-agent activity as a fictional game to weaken safety boundaries. The common path is untrusted page content steering an agent that holds delegated access. OWASP also notes that MCP servers operate with delegated user permissions and chained tool calls, so one exposed capability can have an outsized effect.

Layer 1: separate the browser state from the user

Start at the environment, because runtime policy is weaker when the browser already contains everything worth stealing. OWASP's guidance for browser agents is to use separate browsing profiles and to restrict agent access to credential stores and sensitive local files by default. The steps below turn that into a build.

• 1. Use a dedicated or ephemeral profile: Launch the agent's browser against a profile directory created for the agent. Prefer a fresh profile per run, discarded afterward, so cookies do not accumulate.
• 2. Refuse attach-to-existing-session: Configure or wrap the MCP server so it cannot connect to a browser a person is using. Treat any debugging endpoint as a credential and keep it off shared interfaces.
• 3. Run the browser in a container or remote browser: A containerized or remote browser keeps the agent away from the user's desktop, home directory and OS keychain. A separate OS user gives a lighter version of the same boundary.
• 4. Disable password manager and autofill: Turn off saved-password prompts, autofill for addresses and payment data, and any extension that injects credentials. Enforce this through managed browser configuration, not user settings.
• 5. Issue scoped credentials: If the agent must sign in, give it a dedicated account with least privilege and short lifetime, never a person's account. Keep sensitive MCP servers for payment, auth and PII separate from general-purpose ones.
• 6. Restrict network and origin reach: Limit the browser's egress to approved destinations at the network layer, so a mistaken tool call cannot reach an unapproved site.

Tradeoffs between isolation options

Ephemeral profiles give the strongest default, because no session survives a run. NIST SP 800-63B-4 treats browser cookies as short-term secrets for session maintenance, not authenticators, and says bearer-style session secrets should not persist across an application restart or host reboot. That guidance addresses web applications, but applying it to agent profiles is a reasonable reading: a persistent profile that keeps cookies between runs works against it. The cost is that the agent must authenticate again each run, which is a reason to use scoped, short-lived credentials.

Containers and remote browsers add operational weight: image maintenance, resource limits and a path for retrieving results. In return, they remove the host as an exposure surface. A separate OS user is cheaper but shares the kernel and machine with other workloads. Do not rely on closing the browser to end an authenticated session, since OWASP's session guidance is that sessions need explicit invalidation. Finally, browser isolation products that sandbox web content need governance over all user web traffic to be effective and can raise privacy concerns, so decide deliberately what an agent's browsing capture will include and how long it is kept.

Layer 2: enforce policy on browser tool calls at runtime

Environment isolation limits what the browser contains. Runtime policy limits what the agent can do with it. OWASP is explicit that destination controls should be enforced outside the model, so they do not depend on the model behaving as instructed. A prompt that says do not visit unapproved sites is a request. A policy check on the navigate call is a control.

For browser MCP tools, four decisions matter. Allow calls that match the task, such as navigation to approved origins. Redact sensitive content, such as tokens or personal data, in page content returned to the model. Block credential-related actions, such as entering secrets into forms or reading storage. Escalate for human approval when an action moves data across sites, which OWASP lists as an approval point. Each decision should be made per call, with the origin, tool name and parameters in view.

Evidence is the second half of enforcement. OWASP recommends logging all MCP tool invocations with full parameters, user context and timestamps, and its MCP Top 10 advises immutable audit trails covering tool invocations, context changes and user-agent interactions. To be useful to an auditor, the record should show the policy in force, the decision taken, and who approved any escalation. Scope capture deliberately, since full page content can itself contain sensitive data.

Where Trussed fits

Trussed does not replace Layer 1. It does not build your profiles or containers, so those controls still need to be in place. It operates at Layer 2: Trussed enforces policy in the execution path on MCP tool calls, including browser tools, so decisions are enforced at runtime, not reviewed after the fact. Policy can allow, redact or block an individual call, rate limit it, or escalate it for human approval.

Each enforcement decision produces audit-ready evidence, which shows a regulated enterprise what the agent was allowed to do and what it did. That evidence is mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed is self-managed in the customer cloud, with configurable retention and data residency, which gives security teams a way to decide where captured tool-call data lives and how long it stays. Used alongside isolated browser environments, it closes the gap between a configured boundary and one you can demonstrate.