--- title: "The Agent in the Browser" slug: "chapter-15-the-agent-in-the-browser" kind: "chapter" order: 16 label: "Chapter 15" chapter: 15 part: "The Client Layer" partLabel: "Part IV" partNumber: 4 epigraph: "Most AI browser extensions send your screen to someone else's server. Ours sends your question to your own platform." summary: "The browser is where most knowledge work now happens, and it is where the AI industry has placed its most invasive products: extensions that read every page, send it to a vendor's server, and bill …" words: 1120 topics: - "What the side panel is" - "Reading the page" - "Acting on the page" - "The refusals and the approvals" - "The trust boundary" - "What the demo proves" --- The browser is where most knowledge work now happens, and it is where the AI industry has placed its most invasive products: extensions that read every page, send it to a vendor's server, and bill per seat for the privilege. A sovereign platform has to be in the browser too, because that is where the people are. This chapter describes how it can be there without any of the invasion, using the platform's own Chrome extension as the worked example. ## What the side panel is The extension opens a side panel next to whatever page is open. The panel is the platform's chat and nothing else: the same agents the person uses on the web and the desktop, with the same memory, the same model and the same connectors. It has no settings of its own and no second sign-in; it uses the browser's identity API to complete the hand-off from Chapter 14, and from then on every request carries the person's own session token. The extension itself is small. The published version is a few hundred kilobytes, built from source that lives in the platform's open repository, and published to the Chrome Web Store automatically whenever its version number changes. An institution can install it from the store, pointed at the platform's hosted service, or build it against its own deployment with one configuration value, which is what an on-premise or air-gapped institution does. ## Reading the page The first thing the panel does is feed the text of the active tab to the agent as context. A person on a vendor's documentation page can ask what a paragraph means. A person on an internal portal can ask the agent to summarize a case. The page content goes to the person's own platform, through their own session, to the model their administrator chose, and nowhere else. The second thing is more capable. When the person turns on the agent's browsing mode, the extension's background process reads the page as a structured list: every interactive element, numbered, across every frame and every open component, with what is on screen listed first. For models that can read images, it also takes a picture of the visible tab with the numbers drawn on, so the model can see what the list describes. That representation is what lets the agent act. ## Acting on the page Given a goal, the agent runs a loop: read the page, decide one action, perform it, read again, until the goal is met. The actions are the ones a person has: click, double-click, type, select, scroll, open a URL, go back, wait. They are delivered as real input events through the browser's debugging interface, so pages that ignore scripted input, menus that open on a press, editors that need a real keystroke, behave as they would for a human. The browser shows its standard notice that the tab is being driven for exactly as long as the run lasts. A run has limits. It stops after a fixed number of steps or when its token budget is spent, says which, and offers to continue. A stop control ends it at any time. Closing the panel ends it. Every action is narrated in the chat as it happens, so the person watches the agent work rather than discovering afterwards what it did. The demonstration our team published shows the whole pattern in one scene: a colleague opens LinkedIn, opens the panel, and the LinkedIn agent she built on the platform drafts her post and publishes it. The agent knew her voice because its memory is hers; it knew the page because the panel read it; it could post because the browsing mode gave it real clicks; and nothing about the exchange touched any server but her own organization's. ## The refusals and the approvals An agent that can act on any page needs rules that do not depend on the model's judgement, and the extension has two kinds. Hard refusals. The agent never types into a password field or a payment field, in any mode, and never reads such a field's contents back. This is enforced in the page, by the field's own type, not by asking the model to be careful. Only ordinary web pages can be driven at all; browser-internal pages are out of reach by construction. Approval modes. An administrator or the person chooses between automatic operation, where the agent acts without asking, and an ask-first mode that raises an approve-or-deny card before any submit, send, payment or delete. The card is the same one the desktop application uses for the same purpose, so the behaviour is consistent across surfaces. These are the properties a CISO should look for in any browser agent. The question is not whether the model is well-behaved. It is what the system refuses to do regardless of the model, and whether a human can be placed in the loop at the moments that matter. ## The trust boundary The reason this chapter belongs in a book on sovereignty is the boundary around the data. Model calls go from the extension to the person's own platform, through the platform's standard model interface, with the person's own session. The platform applies the routing policy from Chapter 6, including data classification, so a page from a restricted system can be confined to a local model. The page content is never sent to a third party by the extension; the only server it talks to is the institution's platform, and the manifest's security policy names those hosts and no others. Compare that with the common design, where the extension is the vendor's product, the page goes to the vendor's server, the model is the vendor's, and the person is a seat on an invoice. The two designs look identical from the outside. They differ in every property a CIO is responsible for. ## What the demo proves A browser agent is the most demonstrable thing a sovereign platform ships and the easiest to explain: the agent reads the page you are on and acts on it, with model calls on your own session and nothing else leaving the browser. That sentence is the product's whole argument. It also proves the client-layer claims from the last two chapters in a way a slide cannot. The same agent, memory and model as the web application: one backend. No password form, no secret in the extension: the identity hand-off works in the hardest client. One build against the hosted service, another against an internal host: the same code on every deployment tier. A CIO who watches the panel work on an internal page, under their own deployment, has seen the architecture, not a description of it.