The Browser Is Becoming an Agent Operating System: What Ego Lite Reveals About Shared Human-AI Workspaces

The web browser was initially designed for a single human user. It includes one cursor, one active tab, one browsing history, one set of cookies, and one individual controlling its actions. However, with the emergence of AI agents, this one-human assumption is no longer valid. These agents require significant computational resources, such as researching multiple companies, comparing various dashboards, submitting data across different applications, and waiting for independent pages to finish.

When an AI agent shares the human's visible tabs, it disrupts the user's workflow by stealing focus and interfering with ongoing tasks. If the agent launches a separate clean browser instance, it loses the authenticated sessions and useful extensions that make the web functional. Additionally, if an agent operates by driving pages through minute command-by-command loops, it spends more time managing the browser environment than accomplishing the actual task at hand.

Ego Lite, a rapidly growing GitHub project, offers a novel solution to this problem. Instead of treating the browser as a single user environment, it suggests that the browser should become a shared runtime for both humans and AI agents. Each agent gets its isolated "Space" within the same browser environment. The human can continue browsing while the agents work independently in parallel.

A semantic snapshot allows models to understand the page, and a JavaScript capability layer enables agents to combine several operations into a single program. While the implementation of Ego Lite is interesting, the underlying concept holds broader implications. By treating the browser as an operating system for delegated actions, tabs transform into processes, and Spaces act as workspaces.

Cookies serve as credentials, and navigation becomes state management. Confirmation of actions translates to access control. This article delves into this architecture and the associated risks. Browser automation has faced an identity crisis, with three prevalent approaches. The first is a testing browser, which starts clean, executes deterministic scripts, and discards any state changes.

This approach is ideal for continuous integration (CI) processes but inadequate for personal daily tasks since it lacks the user's existing accounts and context. The second method involves attaching an automation framework to a regular browser. This allows the automation to access authenticated sessions but often competes with the user for resources like tabs, focus, downloads, and navigation.

The third option is an AI browser equipped with a built-in assistant. While the integration can be seamless, the browser ultimately dictates which agent the user must employ. Ego Lite proposes a fourth category: a daily-use browser with multiple isolated task Spaces and the flexibility for the user to choose their preferred agent for each task.

This approach addresses several challenges that testing automation typically overlooks, such as session inheritance, task ownership, parallel execution, credentials management, human intervention capabilities, long-running state preservation, and visible accountability. A "Space" in Ego Lite is more than just a collection of tabs.

While tabs define the visible work area, a Space must also act as an execution and isolation boundary. Conceptually, a Space may encompass various elements: an agent identifier, the human user's identity, an optional delegated agent, a collection of tabs, a dedicated storage partition, security permissions, task progress tracking, an action log for review, and a cancellation mechanism to halt ongoing tasks.

Referring to this system as a "workspace" is convenient, but treating it as a security boundary demands more precise definitions. The browser solution solves login challenges while simultaneously introducing credential risks. When performing web tasks, automation often encounters authentication issues. A fresh automation profile lacks cookies, passkeys, extensions, client certificates, device trust, and remembered organization-specific settings.

Migrating or inheriting Chrome data could make an agent operational immediately, allowing it to access services the user commonly uses without automating every login process. However, this convenience in session management also raises credential delegation concerns. A cookie might authorize access to various services, including email, cloud storage, billing portals, production dashboards, or private messages.

Granting an agent a browser with these cookies is equivalent to granting the agent actual account access. Consequently, the security model must differentiate between a page being visible to the agent, an automatic cookie attachment to a request, the readability of raw cookie values by model-generated code, browser password storage accessibility, user-confirmed actions utilizing existing sessions, and the background extraction of credentials for other uses.

These capabilities vary significantly and necessitate distinct security measures. Instead of an all-or-nothing approach to storage inheritance, a safer Space model should employ origin-scoped inheritance. For instance, a StorageGrant can specify the scope of storage access: type StorageGrant = { origin : string ; cookies : none | session | all ; localStorage : boolean ; indexedDB : boolean ; expiresAt : number ; rawCredentialRead : false ; }; The createTaskSpace function can then create a new isolated Space for a given task, assigning specific storage grants based on the task requirements.

This approach allows the agent to use authenticated requests for approved sites without receiving a complete browser profile. Additionally, storage grants can have expiration dates, preventing unauthorized access to sensitive data. Raw credential APIs should remain inaccessible, even when the browser itself can attach cookies, reinforcing the principle of capability security.

Isolation goes beyond just cookies. Although isolating two Spaces with separate tab lists may appear effective, they can still interfere with each other through shared state. Potential shared resources include cookies, cache, service workers, IndexedDB databases, extension storage, downloads, clipboard data, browser permissions, HTTP authentication tokens, client certificates, password manager credentials, WebRTC device grants, notification permissions, and local file handles.

Isolation mechanisms must address these shared resources comprehensively. Moreover, there are side effects to consider. One Space may infer that another Space has visited a particular resource through shared cache data. A service worker registered in one context might control navigation in another context. A browser extension operating in one Space could potentially see and manipulate tabs across all Spaces.

Addressing these shared resources and side effects is crucial for ensuring a secure and reliable multi-agent browser environment.