Browser Agent Sessions: Keep Workspaces and Accounts Separate

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

A browser agent inherits the authority of the account signed into its browser profile. That makes profile reuse and cleanup important security boundaries. Consider a service that processes browser tasks for several business customers. A successful task for one customer should not leave cookies, downloads, or account state available to the next customer’s agent. Session isolation testing observes these concrete artifacts using synthetic accounts and controlled applications rather than collecting real session credentials.

Define the boundary before testing

Map browser profiles, worker reuse, authentication storage, downloads, screenshots, clipboard access where applicable, and task artifacts. Define the intended separation by user, tenant, job, and environment. Use two test accounts with visually distinct workspaces and harmless files. Ask how the service handles account switching, logout, worker crashes, and sessions that remain valid at the provider. Agree whether a user-supplied browser profile is supported and what that means for the assessment boundary. The profile policy should match the product’s actual operating model.

Run a bounded assessment

Run an authorized task in the first test account, then complete the documented cleanup and assign a task to the second account. Inspect the active account, available downloads, permitted history surfaces, and task artifacts through approved tools. Repeat after a controlled worker restart and a cancelled task. Confirm logout behavior with the identity owner. Do not export cookies or attempt to access real customer applications. A synthetic file and account label are enough to reveal whether state crosses the intended job boundary.

Keep evidence an engineer can use

Collect job and profile identifiers, active test account, lifecycle events, cleanup outcome, and access to the marked artifacts. Record whether a failure concerns authentication state, downloaded content, or stored screenshots because the remediation may differ. Do not include session values in the report. If cleanup relies on a managed browser provider, distinguish observed behavior from its documented guarantees. A new tab is not evidence of a fresh profile, and a visually empty browser window does not prove that authentication storage has been removed.

Interpret the result and retest

Retest allowed login and cleanup after any worker-pool or profile-storage change. Check that a crash recovery path does not reassign an existing authenticated profile to a different tenant. OWASP’s session-management guidance provides the general reference; browser automation adds its own lifecycle and artifact questions. A passing test covers the inspected platform configuration and providers. It does not establish that every external website terminates sessions immediately or that browser isolation alone constrains what an authorized account can do.

Assessment scope and next steps

This is a proposed defensive assessment workflow, not a finding about a particular product. Use a staging environment, synthetic records, approved test identities, and an agreed stop condition. Record the model, connector, policy, and application versions so a later result can be compared with the same configuration. Unavailable evidence should remain an explicit coverage gap.

Primary reference: OWASP security guidance. The scenarios and acceptance criteria here are editorial recommendations for adapting that background to an authorized assessment.

For a scoped review of these boundaries, explore FailSafe AI security testing and agentic penetration testing. Agree the specific tools, identities, evidence, and exclusions before purchasing an assessment.