So arbeitet ein KI-Agent in deinem eingeloggten Browser: Extension, CDP-Relay oder Cloud-Browser

Ein großer Teil der Arbeit, die ein Unternehmen im Browser erledigt, hat keine brauchbare API: der Bulk-Editor im Ad Manager, die CMS-Administrationsoberfläche, das Lieferantenportal, die Bank. Wenn ein Agent diese Arbeit machen soll, braucht er einen Browser, in dem du eingeloggt bist. Dafür gibt es drei Wege. Sie sind nicht gleichwertig.

1. Cloud-Browser

Ein Headless-Chrome auf dem Server von jemand anderem. Browserbase, Firecrawl, Manus und die meisten „Computer Use“-Demos laufen so.

Reichweite: Alles, was öffentlich ist. Für deine Accounts startet er ausgeloggt. Du gibst also entweder Zugangsdaten in die Maschine eines Anbieters ein, synchronisierst Cookies dorthin oder durchläufst jedes Mal einen Login mit 2FA. Manche Anbieter behalten die Session nach dem ersten Login.

Was abfließt: Deine Session liegt auf deren Infrastruktur. Egal, was deren Retention-Policy sagt: Dort liegt das Cookie.

Stoppt bei: allem, was Rechenzentrums-IPs erkennt, allem, was dein Gerät will (Passkeys, Hardware-2FA), und jeder Seite, deren Nutzungsbedingungen Automatisierung von einer unbekannten Maschine verbieten.

Gut für Scraping, Recherche und parallele Jobs ohne persönlichen Login. Für „antworte auf die drei Support-Tickets in meinem Zendesk“ funktioniert es nur, wenn deine Zendesk-Session auf deren Server liegt.

2. CDP-Relay zu deinem lokalen Chrome

Das Chrome DevTools Protocol ist die Schnittstelle, die Chrome zum Debuggen anbietet. Starte Chrome mit --remote-debugging-port, leite diesen Socket an einen Server weiter, und ein entfernter Agent steuert diese Chrome-Instanz. So funktionieren Playwright, Puppeteer und die meisten „Verbinde dich mit meinem Browser“-Tools.

Ein Stolperstein, über den viele fallen: Seit Chrome 136 werden die Debugging-Flags für das Standard-Profilverzeichnis ignoriert. --remote-debugging-port auf deinem normalen Chrome öffnet also gar keinen Port. Du musst ein separates --user-data-dir übergeben, und das startet ohne deine Logins. Um an deine echten Sessions zu kommen, musst du das Profil dorthin kopieren oder stattdessen über eine Extension gehen.

Reichweite: Mit angehängtem Profil alles, was du erreichen kannst. Dieselben Cookies, dieselben Extensions, dasselbe Gerät für Passkeys.

Was abfließt: Das Relay sieht jede Seite, jedes DOM, jeden Tastendruck, den es sendet. Wer den Relay-Endpunkt hat, hat deinen Browser. Das Token in dieser URL gewährt Vollzugriff auf die Session und muss auch so behandelt werden.

Stoppt, wenn: Chrome nicht läuft. Rohes CDP auf dem Debugging-Port ist außerdem alles oder nichts: Das Protokoll kennt kein „nur dieser Tab“ und kein „lesen, aber nicht tippen“, und Network.getAllCookies liefert das ganze Cookie-Jar. Jede Eingrenzung muss also obendrauf gebaut werden.

Mächtig, und die richtige Antwort, wenn der Agent schon auf deiner Maschine läuft. Riskant, wenn der Agent auf der Maschine eines Anbieters läuft und das Relay übers Internet geht.

3. Browser-Extension

Code, der in deinem Chrome läuft, mit den Berechtigungen, die das Extension-Manifest deklariert. Der Agent schickt Intents; die Extension führt sie lokal aus.

Reichweite: Was der Code der Extension durchlässt, auf den Tabs, die sie anfassen darf, und was ihre Manifest-Berechtigungen erlauben. Eine Extension, die cookies anfordert, kann Cookies lesen; eine mit debugger bekommt dieselbe CDP-Oberfläche wie ein Relay, begrenzt auf die Tabs, an die sie sich anhängt. Sie läuft in deinem Benutzerkontext, auf deinem Gerät. Logins und gerätegebundene 2FA stehen also zur Verfügung, wenn die Extension den Zugriff darauf ermöglicht.

Was abfließt: Seiteninhalt geht dorthin, wohin die Extension ihn schickt. Eine gut gebaute schickt den Accessibility-Tree oder einen Screenshot des Arbeits-Tabs, nicht deinen ganzen Browser. Der Umfang ist prüfbar: Er steht im Manifest und im Berechtigungsdialog von Chrome.

Hat dieselben Grenzen wie ein CDP-Relay. Chrome muss laufen, es passiert also nichts, solange dein Laptop zu ist. Chrome blockiert Extensions außerdem auf browserinternen Seiten und im Web Store.

Enger als rohes CDP, wenn sie so gebaut ist. Das ist der Vorteil, und es ist die Entscheidung des Extension-Autors, nicht die des Transports.

So macht es TODO for AI

Die Chrome-Extension ist eine Mischung aus 2 und 3, und es lohnt sich, genau zu sagen, welche Teile was sind.

• Befehle im CDP-Format, über die Extension. Der Agent spricht eine CDP-Teilmenge über einen WebSocket zu unserer API, und die Extension führt sie aus. Es gibt zwei Modi, und der Unterschied zählt: Der Standard-Shim-Modus unterstützt eine feste Liste von Methoden auf Seitenebene (DOM, Accessibility, Input, Runtime.evaluate, Screenshots), indem er eine Engine in die Seite injiziert, ohne Debugger-Banner und ohne Domains auf Browser-Ebene. Der Debugger-Modus leitet Befehle an die debugger-API von Chrome weiter, für originalgetreues CDP-Verhalten, Banner inklusive, und dann ist die erreichbare Oberfläche CDP selbst.
• Nur angehängte Tabs. Du klickst im Extension-Popup bei einem Tab auf „Anhängen“. Der Agent kann diese Tabs steuern und alle neuen Tabs, die er selbst öffnet. Ein Befehl an einen nicht angehängten Tab wird in beiden Modi abgelehnt. Debugger-Modus plus die ausdrückliche Einstellung „allow-unattached“ hebt das auf, und dann kann ein Agent jeden Tab über seine ID ansprechen. Chrome-interne Seiten und der Web Store lassen sich gar nicht anhängen.
• Cookies: keine Cookie-API der Extension, aber lies das nicht als Grenze. Die Extension fordert die cookies-Berechtigung nicht an. Im Shim-Modus liest der Agent, was ein Skript auf der angehängten Seite lesen könnte, document.cookie inklusive. Im Debugger-Modus geht CDP unverändert an Chrome, und die Network-Domain reicht weiter als ein Tab: Network.getAllCookies liest alle Cookies des Browsers. Die Grenze ist der Modus, den du wählst, und die Berechtigung, die du dem Agenten gibst, nicht die fehlende cookies-Berechtigung.
• Seiteninhalt geht über die Leitung. Snapshots, DOM und Screenshots angehängter Tabs gehen an die API, damit der Agent sie sehen kann. Das ist die potenzielle Datenabflussfläche. Die Liste der angehängten Tabs begrenzt sie, außer du schaltest allow-unattached im Debugger-Modus ein, dann kann ein Agent jeden Tab über seine ID ansprechen.
• Berechtigungen pro Agent und ein Stopp-Button. Browserzugriff ist eine Berechtigung, die du pro Agent auf erlauben, erst fragen oder blockieren festlegst, und der Standard für einen neuen Agenten ist erlauben. „Erst fragen“ fordert vor jedem Tool-Aufruf eine Bestätigung an, nicht jede daraus resultierende Aktion oder Auswirkung. Die Shell ist ein separates Tool, das ebenfalls einen Browser erreichen kann. Beschränke daher bei Bedarf sowohl den Browserzugriff als auch die Shell. Jeder Run lässt sich mitten in der Aufgabe stoppen; der Tab bleibt, wo er war.
• Cloud-Browser für den Rest. Recherche, die keinen Login braucht, läuft in einem Cloud-Browser pro Account. Dein Chrome bleibt also frei, und dein Laptop kann zu sein.

Was es nicht kann: laufen, während Chrome geschlossen ist. Es gibt keine Blockliste pro Site und keinen Nur-Lesen-Modus; die Liste der angehängten Tabs, der Modus und die Berechtigung pro Agent sind die Stellschrauben. Wenn eine Site nie erreichbar sein darf, lass sie nicht angehängt.

Welcher Weg wann, in einer Tabelle

Die letzte Spalte ist unsere Extension, nicht Extensions im Allgemeinen; eine andere Extension kann andere Entscheidungen treffen.

	Cloud-Browser	CDP-Relay	TODO for AI Extension
Nutzt deine bestehenden Logins	Erst, wenn du sie übergibst	Ja, mit angehängtem Profil	Ja
Passkeys, Hardware-2FA	Nein	Ja, du sitzt am Gerät	Ja, du sitzt am Gerät
Was über die Leitung geht	Die ganze Session	Alles im Browser	Seiteninhalt angehängter Tabs
Scope-Kontrolle	n/a	Alles oder nichts	Angehängte Tabs, Shim- vs. Debugger-Modus, Berechtigung pro Agent
Läuft bei geschlossenem Laptop	Ja	Nein	Nein, Chrome muss laufen
Sperren wegen Rechenzentrums-IPs	Oft	Nein	Nein

Wenn die Aufgabe dich braucht, nimm die Extension. Wenn sie niemanden braucht, nimm den Cloud-Browser. Ein Relay ist für den Fall, dass der Agent schon auf deiner Maschine läuft und du jedem Hop vertraust. Was das für eine To-do-Liste heißt, die Aufgaben tatsächlich erledigt, steht im To-do-Post.