Dev.to Security 🔐 Cybersecurity 👁 0 📖 6 min read

How an AI agent works in your logged-in browser: extension vs CDP relay vs cloud browser

Plenty of the work a business does in a browser has no usable API: the ad manager's bulk editor, the CMS admin, the supplier portal, the bank. If an agent is going to do that work, it needs a browser that is logged in as

Plenty of the work a business does in a browser has no usable API: the ad manager's bulk editor, the CMS admin, the supplier portal, the bank. If an agent is going to do that work, it needs a browser that is logged in as you. There are three ways to get one. They are not equivalent.

1. Cloud browser

A headless Chrome on someone else's server. Browserbase, Firecrawl, Manus and most "computer use" demos run this way.

Reach: anything public. For your accounts it starts logged out, so you either paste credentials into a vendor's machine, sync cookies to it, or run a login flow with 2FA each time. Some vendors persist the session after the first login.

Leaks: your session lives on their infrastructure. Whatever their retention policy says, that is where the cookie is.

Stops at: anything that fingerprints a datacenter IP, anything that wants your device (passkeys, hardware 2FA), and any site whose terms forbid automation from an unknown machine.

Good for scraping, research and parallel jobs with no personal login. For "reply to the three support tickets in my Zendesk" it works only once your Zendesk session lives on their server.

2. CDP relay to your local Chrome

Chrome DevTools Protocol is the wire Chrome exposes for debugging. Start Chrome with --remote-debugging-port, forward that socket to a server, and a remote agent drives that Chrome. This is how Playwright, Puppeteer and most "connect to my browser" tools work.

One catch people hit: since Chrome 136 the debugging flags are ignored for the default profile directory, so --remote-debugging-port alone gives you a fresh profile with none of your logins. Getting your real sessions means copying the profile to a --user-data-dir you pass explicitly, or going through an extension instead.

Reach: with your profile attached, everything you can reach. Same cookies, same extensions, same device for passkeys.

Leaks: the relay sees every page, every DOM, every keystroke it sends. Whoever holds the relay endpoint holds your browser. The token in that URL is a full-session credential and has to be treated like one.

Stops at: Chrome not running. Raw CDP on the debugging port is also all-or-nothing: the protocol has no "this tab only" or "read but do not type", and Network.getAllCookies returns the whole jar, so any scoping has to be built on top of it.

Powerful, and the right answer when the agent already runs on your machine. Risky when the agent runs on a vendor's machine and the relay goes across the internet.

3. Browser extension

Code that runs inside your Chrome with the permissions the extension manifest declares. The agent sends intents; the extension executes them locally.

Reach: whatever the extension's code lets through, on the tabs it is allowed to touch, and whatever its manifest permissions allow. An extension that requests cookies can read cookies; one that requests debugger gets the same CDP surface as a relay, scoped to the tabs it attaches to. It runs as you, on your device, so logins and device-bound 2FA are available if the extension exposes them.

Leaks: page content goes wherever the extension sends it. A well-built one sends the accessibility tree or a screenshot of the working tab, not your whole browser. The scope is inspectable: it is in the manifest and in the Chrome permissions dialog.

Stops at: the same place a CDP relay does. Chrome has to be running, so nothing happens while your laptop is closed. Chrome also blocks extensions on browser-internal pages and the Web Store.

Narrower than raw CDP if it is built that way. That is the feature, and it is the extension author's choice, not the transport's.

How TODO for AI does it

The Chrome extension is a hybrid of 2 and 3, and it is worth being precise about which parts are which.

  • CDP-shaped commands, through the extension. The agent speaks a CDP subset over a WebSocket to our API, and the extension executes it. Two modes, and the difference matters: the default shim mode serves a fixed list of page-level methods (DOM, Accessibility, Input, Runtime.evaluate, screenshots) by injecting an engine into the page, with no debugger banner and no browser-level domains; debugger mode forwards commands to Chrome's debugger API for full fidelity, banner included, and then the reachable surface is CDP itself.
  • Attached tabs only. You click "attach" on a tab in the extension popup. The agent can control those tabs and any new tab it opens itself. A command aimed at an unattached tab is refused in both modes. Debugger mode plus the explicit allow-unattached setting lifts that, and then an agent that names a tab id can reach any tab. Chrome internal pages and the Web Store cannot be attached at all.
  • Cookies: no extension cookie API, but do not read that as a boundary. The extension does not request the cookies permission. In shim mode the agent reads what a script on the attached page could read, document.cookie included. In debugger mode CDP goes to Chrome as-is, and the Network domain is broader than one tab: Network.getAllCookies is a whole-browser read. The boundary is the mode you pick and the permission you give the agent, not the missing cookies permission.
  • Page content crosses the wire. Snapshots, DOM and screenshots of attached tabs go to the API so the agent can see them. That is the leak surface. The attach list bounds it, unless you turn on allow-unattached in debugger mode, which lets an agent name any tab.
  • Agent-level permissions and a stop button. Browser access is a capability you set per agent to allow, ask-first or block, and the default for a new agent is allow. Ask-first gates each tool call, not each outcome, and the shell is a separate tool that can also reach a browser, so gate both if that matters. Any run can be halted mid-task; the tab stays where it was.
  • Cloud browser for the rest. Research that needs no login runs in a per-account cloud browser, so your Chrome is free and your laptop can be closed.

What it does not do: run while Chrome is closed. There is no per-site block list and no read-only mode; the attach list, the mode, and the per-agent permission are the scope controls. If a site must never be reachable, do not leave it attached.

Which one, in one table

The last column is our extension, not extensions in general; another extension can make different choices.

Cloud browser CDP relay TODO for AI extension
Uses your existing logins Only after you hand them over Yes, with your profile attached Yes
Passkeys, hardware 2FA No Yes, you are at the device Yes, you are at the device
What crosses the wire The whole session Everything in the browser Page content of attached tabs
Scope control n/a All or nothing Attached tabs, shim vs debugger mode, per-agent permission
Runs while laptop closed Yes No No, Chrome has to be running
Datacenter IP blocks Often No No

If the task needs you, use the extension. If it needs nobody, use the cloud browser. A relay is for when the agent is already on your machine and you trust every hop. What this means for a to-do list that actually closes items is in the to-do post.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.