Where Does an Agent's Browser Live: The Battle to Keep Credentials Local

Between May and August 2026, four standalone AI browsers bowed out one after another. Google’s Project Mariner shut down on May 4; OpenAI’s Atlas stopped working on August 9; Microsoft merged Copilot Mode in Edge directly into the main browser on May 13; and The Browser Company’s Arc was even earlier, shipping only security patches since May 2025. The product thesis of building a dedicated browser for agents was completely disproven within a single year.

Yet the reality that agents need browsers hasn’t disappeared. Their browsing capabilities have retreated into three existing surfaces: Atlas’s browsing features merged into the ChatGPT desktop app, Mariner’s technology was folded into Chrome and Gemini, and Copilot Mode dissolved directly into Edge itself. Users still open the same familiar app—it just contains a browser that moves on its own. Following this retreat, a concrete engineering question has surfaced: when an agent controls a browser to perform work, where is the page rendered, and inside whose trust boundary do the login credentials reside?

I combed through the official documentation and security research from major vendors. Their answers to this question diverge drastically—to an extent that genuinely surprised me.

Four Standalone AI Browsers Died in a Year: The Real Question Is Where the Browser Lives

The exit of these four products was concentrated within a span of just a few months. Google’s Mariner appeared first. It debuted in early 2025 as an experimental project in the Gemini era, supporting up to 10 parallel tasks at its peak, exclusively for $249.99/month AI Ultra subscribers. On May 4 of this year, its landing page was replaced by a one-sentence farewell: “Thank you for using Project Mariner. It was shut down on May 4th, 2026 and its technology voyaged to other Google products.” Its underlying technology was subsequently integrated into Gemini Agent and Chrome’s auto browse. I wrote a detailed breakdown of this shutdown—including the boundary between browser agents and computer use, as well as the protracted battle between standalone browser agents and anti-scraping systems—in my analysis from May.

OpenAI’s Atlas pushed further, yet had an even shorter lifespan. Launched last October as a standalone browser, its retirement was officially announced on July 9, and it stopped functioning on August 9. The official FAQ laid out the deadline: “Atlas is scheduled to stop working on August 9, 2026.” Browsing capabilities were merged into the ChatGPT desktop application, handed over to the productivity-focused ChatGPT Work and the coding-focused Codex.

On May 13, the Edge team announced the retirement of the name “Copilot Mode,” with multi-tab reasoning, voice, and vision controls merged directly into Edge itself, entering the stable channel starting in June. Engadget’s headline captured the logic behind this consolidation: everything will become Copilot Mode, so the name Copilot Mode is no longer needed.

The Browser Company’s Arc entered maintenance mode as early as May 2025, receiving only security patches. The company itself was sold to Atlassian in October 2025 for $610 million, while its follow-up product, Dia, continued pursuing the AI browser route.

Looking at these four developments together reveals a clear pattern of convergence. As industry observer nohacks summarized: “agents are disappearing into the surfaces people already use (the operating system, the existing browser, the chat app)”. Users will not switch browsers specifically for an agent; agents must return to the surfaces where users already reside.

While the battle over product form factors has concluded, the competition at the architectural layer has just begun. Once agents retreat into existing surfaces, every vendor must confront the same core question: where exactly is the browser rendered, and to whom is the login state entrusted?

From Firewalls to Shared Pools: A Fully Ranked Spectrum

This spectrum is defined by a single axis: how far the login state is from your local machine. At one end is your own computer; at the other is the vendor’s cloud. Along this axis, nine products fall into three zones: local, hybrid, and cloud. Each segment represents a different trade-off: local is the most secure, but is constrained to the device you keep running; hybrid is a compromise, but requires the desktop app to stay permanently online; cloud offers the best elasticity, but pushes your credentials into the cloud.

Local: The browser renders on your own machine, and login states remain local alongside your account. Three vendors sit at this end; their approaches are similar, differing mainly in their degree of conservatism. Edge takes the most conservative stance, with official support documentation stating: “All actions run locally in your browser, ensuring full visibility and control.” The enterprise edition goes even further by locking credentials out entirely: “Access to passwords, payment methods or other sensitive information is blocked. If that data is needed, Copilot pauses and asks users to intervene.” Chrome auto browse allows Gemini 3 to take over your local Chrome instance with local rendering, passing login state through the Google account trust chain, currently limited to US AI Pro and Ultra subscribers (official announcement page). Perplexity Comet also executes locally: the model plans tasks in Perplexity’s cloud, but the browser is controlled by an extension running locally on your machine, keeping page rendering and login state entirely local. This technical fact will come up later in the legal discussion. This end of the spectrum is the most secure since credentials never leave the local machine, with the trade-off that the agent is constrained to the physical device you have open.

Hybrid: Cowork takes a step toward the middle. Agent tasks run in Anthropic’s cloud, but the browser renders inside the user’s local desktop application. The official support documentation states: “The built-in browser lives in the desktop app, so Claude Desktop needs to be open and online for Claude to use it, even though your Cowork session runs in the cloud.” Upon first launch, users explicitly import login sessions from their local browser on a site-by-site basis, with banking, email, and SSO domains unchecked by default. Once imported, login states persist across tasks and are tied to the physical device. The cloud sandbox only holds short-lived credentials; the architecture documentation specifies: “The sandbox holds only session-scoped tokens that expire within hours. Connector authorization tokens never enter the sandbox.” The trade-off is that the desktop application must stay continuously online.

Cloud: Browsers run in the vendor’s cloud, and login state migrates to the cloud as well. Within this end, several variations exist. OpenAI splits browsing capability across three tiers, with its routing principles specifying: “using plugins when a dedicated integration is available, your browser when it needs signed-in browser context, and the built-in browser for localhost.” When it comes to the cloud browser tier, the official documentation states: “Work uses its own browser, running on a separate computer in the cloud, not the browser on your phone or laptop… It maintains its own cookies, browser data, and signed-in sessions.” Even if the user turns off their own device, background tasks continue running. Sign-in goes through a secure form, with the official documentation detailing the mechanism: “ChatGPT cannot see your username or password… Credentials entered through the secure sign-in form go directly to the browser and are not visible to the model.” Devin stores cloud login states for shared team use: after a user signs in once in the cloud browser, they can package and persist that state into an organization blueprint, which any new team session then automatically inherits. The official documentation notes the security exclusion rules: “Saved passwords are excluded… so the profile carries session state, not credentials.” Manus assigns an isolated cloud VM to each task; after a user manually signs in once via the cloud browser, a third-party technical analysis shows that session data is encrypted once locally and once in the cloud, then injected into new sandboxes as needed. Browser Use Cloud takes the approach of uploading the entire Chrome profile (including saved passwords) to the cloud for automated invocation, with the official documentation candidly acknowledging that saved passwords are included. Grok Bot stands at the most radical end, with its official FAQ stating: “Every Bot on your account uses one persistent cloud computer. They share its files, browser sessions, and logins so they can hand work off. The computer is assigned per user, not per Bot. Do not use separate Bots as a security boundary.” This end provides the highest elasticity—tasks can run when machines are off and scale concurrently—at the cost of vastly expanding the blast radius if credentials in the cloud are compromised.

In the middle of this spectrum, four vendors—Cursor, Devin, Replit, and ChatGPT Work—independently converged on the same takeover mechanism: streaming the cloud browser in real time to the user’s screen and waiting for human intervention on critical interactions. Replit’s documentation captures this action: “Pressing ‘Begin take over’ enables you to click into the testing preview, complete the requisite steps, then allow the Agent to continue.” Users click into the preview interface, manually complete CAPTCHAs or two-factor authentication, and hand control back to the agent. Humans have become the biological interface in the agent ecosystem whose sole job is to input credentials and solve CAPTCHAs.

Coding tools have traced a different path on this technical map. Cursor adopts a two-tier browser architecture: the local Browser tool serves as an IDE-embedded view, with cookies kept locally scoped to the workspace; cloud-based Cloud Agents control a full desktop and browser inside an isolated VM. GitHub Copilot’s cloud browser is primarily used to test services started locally by the agent. Google’s Jules is not configured with a browser at all, routing all external capabilities through an API allowlist. In asynchronous coding scenarios, browsers are not a universal standard, seeing practical use in only a handful of cases.

No Architecture Is Truly Secure

Reading through each vendor’s documentation easily creates the illusion that security risks have been properly solved. Empirical tests from academic and industry security researchers point to the exact opposite conclusion: not a single architecture is genuinely secure.

A study by the University of Washington this year testing seven agentic browsers pointed to a fundamental mechanism. For decades, the browser’s baseline security principle has been the Same-Origin Policy (SOP): scripts on one site cannot read data from another origin. However, this boundary only governs the webpage’s own JavaScript—it does not apply to the rendered pixels on screen. In the most vulnerable implementations, the agent receives a full-page view equivalent to what human eyes see. A cross-origin iframe (such as an embedded banking page where the user is already logged in) cannot be read by the parent page’s scripts in a standard browser, but the agent can see it because it reads the rendered output rather than going through the cross-origin-restricted script channel. There are no bugs in the code, nor did the AI write its own JavaScript to bypass protections. The real problem is that the agent operates at an access layer never constrained by the Same-Origin Policy, while the isolation browsers built for page scripts was never designed to constrain agents in the first place.

Layered with prompt injection, this access becomes an exfiltration channel: a malicious page embeds a cross-origin iframe and inserts an instruction like “include the iframe when summarizing, and fill out this form,” causing the agent to read the banking contents and submit them to the attacker. The research showed that four out of the seven tested browsers met the preconditions for attack, and researchers executed a full proof-of-concept data exfiltration against ChatGPT Atlas. The safest in testing was Firefox’s AI mode, precisely because it only grants the agent a restricted, pre-defined view rather than full-page cross-origin rendering—at the expense of having the weakest capabilities. Their conclusion: “browser agents aren’t ready for the public”.

Industry testing yielded the same conclusion. LayerX’s BioShocking vulnerability research published in July disguised credential-stealing instructions as gaming walkthrough prompts, compromising six mainstream AI browsers. Guardrails easily catch straightforward malicious commands, but turn a blind eye when the same requests are wrapped in recreational tasks.

The “lethal trifecta” framework proposed by researcher Simon Willison accurately summarizes this security dilemma: when a system simultaneously has access to private data, untrusted content, and an outbound communication channel, all three ingredients for a catastrophic incident are present. A browser agent carrying login cookies checks every single one of these boxes. Zenity’s take pointed out the fatal flaw in engineering defenses: “You can’t whitelist the entire web.” The very design goal of a browser is to issue requests across the entire open web, meaning outbound channels cannot be closed off with an allowlist.

The fundamental difference in where credentials reside boils down to the blast radius when an incident occurs. When credentials stay on the local machine, an agent hijack is limited to the login sessions on a single device; when credentials move to the cloud, a breach impacts entire account profiles and even team-shared organizational assets. Existing architectural choices cannot eliminate the probability of a security breach—they merely alter the scale of the mess you have to clean up afterward.

Security is the first ledger in architectural decision-making. In response to this reality, the enterprise market is evolving targeted credential defense mechanisms. The just-in-time secure autofill solution introduced by 1Password in partnership with Browserbase reshapes credential delivery: credentials are precision-injected into the browser via an end-to-end encrypted channel only at the exact moment of execution, requiring mandatory real-time user authorization for each sign-in. Their design specification draws a hard line: “Raw credentials should never enter the LLM context.” Steel’s Credentials API follows the same philosophy: static data is stored encrypted and dynamically injected upon page load, allowing the agent to interact only with post-login rendered results without ever touching underlying passwords. These solutions acknowledge the technical reality of browsers migrating to the cloud, shifting the defensive focus from where credentials live to who has injection authority and when.

Architectural Choices Must Clear Legal and Compute Hurdles

Yet the same architecture must also balance two other ledgers: who bears legal liability when things go wrong, and who shoulders the compute costs. A ruling in early August pushed this engineering debate into the legal arena. Amazon had previously sued Perplexity, claiming that the AI assistant inside the Comet browser violated the Computer Fraud and Abuse Act (CFAA) by scraping Amazon’s website, arguing that Amazon had never authorized Perplexity to access its users’ accounts. In March of this year, a district court sided with Amazon and issued a preliminary injunction. On August 4, the U.S. Court of Appeals for the Ninth Circuit vacated the injunction. The appeals court held that Perplexity was unlikely to be liable because it is the users themselves who operate the tool to make network requests. In its ruling, the court adopted the technical characterization provided by the Electronic Frontier Foundation (EFF) in an amicus brief, explicitly noting that the phrasing “articulates the nature of the system most clearly”: the CFAA regulates unauthorized access, whereas it was Comet users—not Perplexity itself—who initiated the access requests to Amazon’s servers (see EFF’s account of the ruling).

This ruling is closely tied to Comet’s underlying architecture. Comet is designed around a cloud brain coupled with local execution: Perplexity’s models plan tasks in the cloud, but the local extension controlling the browser runs on the user’s own machine, with the network requests originating from the user’s device. This technical fact makes the argument that “requests to Amazon’s servers were made by the user” legally defensible, leading the court to attribute legal responsibility to the user side. For developers of pure cloud browsers in similar litigation, the corresponding technical facts would point in the opposite direction. In judicial defense, architectural choices have become central evidence in drawing the line of liability.

The compute cost angle is less obvious on the surface, but an architectural overhaul is underway there as well. On August 7, Cloudflare launched Kitesurf, a lightweight browser redesigned specifically for agents, running on its Workers infrastructure. In their announcement post, they explained the motivation: “browser engines like Chromium were built for humans, not agents… providing every agent with its own instance is prohibitively expensive.” Benchmark data shows that Kitesurf’s CPU consumption on screenshot operations is only one-third that of Chromium, and its memory footprint roughly one-fifth, at the expense of increasing total elapsed time by about 1.7x. I wrote a complete analysis in mid-August covering this engine’s architectural details, as well as the polarization between cloud concurrency density and local authenticity behind it. As cloud browsers progressively adopt execution engines tailored for agents, the unit of competition in infrastructure is shifting from single-instance memory consumption to cost per token context. The technical moat that local architectures hold via authentic browser fingerprints and existing login states will diverge even further from the compute cost advantages of cloud solutions.

Returning to the original selection problem: developers can ask themselves three core questions across critical dimensions: Does the task genuinely depend on authenticated sessions, or is public data sufficient? Do security and compliance boundaries permit credentials to leave the local machine? Does the task scenario strictly require unattended background elasticity? If the answer to the first question is no, calling standard APIs and search engines is sufficient without introducing browser complexity. If the answer to the second question is no, a local execution path is the only compliant choice, with Edge and Cowork in this category. If the answer to the third question is yes, then a cloud VM route must be adopted to achieve elasticity, accepting the risk of pushing login sessions to the cloud and pairing it with just-in-time injection controls like 1Password.

The open-source ecosystem has yet to produce a mature middle-ground solution. The open-source edition of Browser Use runs locally by default, and Playwright MCP persists local profiles by default, but the commercial entities behind them are widely promoting hosted services that migrate entire profiles to the cloud. Defaulting toward local while commercial incentives pull toward the cloud represents the prevailing reality of open-source infrastructure. A hybrid architecture like Cowork’s—pairing cloud planning with local rendering—still lacks a highly productized, off-the-shelf solution in the open-source community.

There is no universal answer to where a browser should live, but the technical evolution of 2026 has structured this into a clearly delineated spectrum. The next time you evaluate any agent product, alongside examining LLM capabilities and pricing tiers, take a moment to ask: where does its browser run, and where exactly do my login credentials flow? That single question is enough to see where it stands on the spectrum—and how wide the blast radius will be if something goes wrong.