Compute- & Browser-Use-Agenten: Wenn die KI klickt, zahlen wir (manchmal doppelt)

AI 27. Mai 2026 Marc Lettau-Poelchen 5 min Lesedauer

ki-agentenbrowser-usecompute-useapissecuritykosten

Compute- & Browser-Use: Was ist das eigentlich?

Compute-Use heißt: Ein Agent bedient (mehr oder weniger) deinen Rechner – klickt Buttons, tippt in Felder, lädt Dateien herunter, schaltet zwischen Apps um.

Browser-Use ist die Web-Variante davon: Der Agent steuert einen Browser wie ein Mensch. Nur ohne Müdigkeit – und mit der charmanten Neigung, immer dann zu stolpern, wenn ein Cookie-Banner „nur kurz“ im Weg steht.

Warum das gerade so beliebt ist:

Kein API-Zugang nötig: Wenn es eine UI gibt, kann man sie automatisieren.
Schneller Prototyping-Effekt: „Mach das Gleiche wie ich – nur 100×“ klingt nach Produktivität.
Umgehen von API-Limits / fehlender Doku: Wenn die API nicht öffentlich ist, geht man eben über die Oberfläche.

Und ja: Das fühlt sich manchmal so an, als wären APIs plötzlich optional. Spoiler: Sind sie nicht.

Wo es weh tut: Gefahren & Bedenken (inkl. „hoher Token use?!“)

1) Security: (Indirect) Prompt Injection – der Agent liest mit, und leider auch zu gut

Ein Browser-Agent konsumiert fremde Inhalte: Webseiten, Mails, Dokumente. Genau dort sitzt eine der größten Gefahren: (Indirect) Prompt Injection.

Das ist nicht „der User promptet falsch“, sondern: Eine Seite enthält versteckte oder geschickt formulierte Anweisungen, die der Agent als Teil seiner Aufgabe interpretiert. Ergebnis: Der Agent kann dazu gebracht werden, Dinge zu tun, die du nie wolltest – etwa auf Phishing-Elemente zu reagieren, Inhalte zu exfiltrieren oder riskante Downloads auszuführen.^[1]

Das strukturelle Problem: Für den Agenten ist vieles einfach „Text/Content“. Die Trennlinie zwischen Daten und Anweisung ist in der Praxis schwer zu erzwingen.

2) Datenschutz & Vertraulichkeit: Der Agent sieht halt alles (und manchmal sehen andere mit)

Compute-/Browser-Use ist bequem, weil der Agent sehr viel Kontext „sehen“ kann: Bildschirminhalte, Formulareingaben, Session-Informationen, Downloads.

In einem sauberen Setup bleibt das lokal und minimal. In vielen realen Setups existieren jedoch Logs, Telemetrie, Debug-Screenshots oder Remote-Ausführungen. Damit wird aus „Agent hilft“ schnell „Agent ist ein sehr neugieriger Praktikant mit permanentem Notizblock“.^[1]

3) Governance & Compliance: Der Agent ist kein Mitarbeiter – benimmt sich aber wie einer

In Unternehmen eskaliert Browser-/Compute-Use oft über Berechtigungen:

Der Agent bekommt Zugriff auf Mail, Drive, CRM, Ticketsystem… weil er „endlich mal helfen soll“.
Damit wird er effektiv zum nicht-menschlichen Insider.
Und jeder unklare Auftrag wird zum Risiko: „Räum mal auf“ ist für Menschen Kontext, für Agenten ein Abenteuer.

Berichte über Agenten-Sicherheitsvorfälle betonen genau diese Governance-Lücke: zu viel Reichweite, zu wenig Eingrenzung, zu wenig Auditierbarkeit.^[2]

4) Robustheit: UIs ändern sich. Gerne freitags.

Browser-Use wirkt wie „API ohne API“. Der Preis ist Fragilität:

Button-Text ändert sich
Layout wird umgebaut
A/B-Test würfelt das DOM
Cookie-Banner, Captchas, Login-Flows wechseln

Eine API ist (idealerweise) ein Vertrag. Eine UI ist… ein laufendes Experiment.

5) Kosten & Performance: „Hoher Token use?!“ – ja, aus mehreren Gründen

UI-Automation ist oft schrittintensiv. Und jeder Schritt erzeugt Kontext:

großer State (DOM/Accessibility Tree, Tool-Outputs, ggf. Screenshots)
viele Mikro-Aktionen (scrollen, finden, klicken, warten, verifizieren)
Retries (Element nicht klickbar → nochmal; Seite neu geladen → nochmal)

Ein paar konkret beschriebene Mechanismen aus der Praxis:

Tool-/Schema-Overhead: Bei MCP-basierten Browser-Tools kann allein das Bereitstellen/Laden von Tool-Definitionen signifikant Tokens kosten – bevor der Agent überhaupt produktiv wird.^[3]
Output-Tokens treiben Latenz: Browser Use beschreibt, dass Output-Tokens in ihrer Messung deutlich mehr Latenz erzeugen als Input-Tokens, weshalb sie Aktionen extrem knapp halten.^[4]
Screenshots sind teuer: Das Verarbeiten von Screenshots/Visual Context erhöht den Aufwand; deshalb wird in performanten Setups „nur wenn nötig“ gescreenshotet.^[4]

Heißt nicht, dass Browser-Use immer unbezahlbar ist. Aber: Ein sauberer API-Call gewinnt fast immer in Effizienz, wenn er verfügbar ist.

Überleitung: Und genau deshalb schaut man wieder Richtung API (auch wenn sie „nicht öffentlich“ ist)

Wenn dein Ziel verlässliche Automatisierung ist – wiederholbar, testbar, skalierbar – ist eine API (selbst eine interne) oft die nüchtern bessere Option:

Billiger: 1 Request statt 30 UI-Aktionen
Schneller: kein Rendern, weniger Kontext
Stabiler: weniger UI-Drift
Besser testbar: Requests sind reproduzierbar
Besser kontrollierbar: Rate Limits, Error Codes, Observability

Und jetzt kommt der Punkt, den viele nur ungern laut sagen: Viele Web-Apps sprechen intern natürlich bereits mit einer API. Wenn die nicht dokumentiert ist, ist es oft effizienter, diese Schnittstelle zu verstehen, als eine KI durch ein UI-Labyrinth klicken zu lassen, das sich beim nächsten Deploy neu dekoriert.

(Kurzer Spaßbremsen-Hinweis: Reverse Engineering und automatisierter Zugriff können gegen Nutzungsbedingungen verstoßen; zusätzlich können Datenschutz- und Sicherheitsanforderungen gelten. Technik ist nicht automatisch Erlaubnis.)

Fazit: Sind APIs wirklich tot?

Nein. APIs sind nicht tot – sie sind nur weniger demo-tauglich als ein Agent, der „wie ein Mensch“ klickt.

Compute-/Browser-Use-Agenten sind super für:

Ad-hoc-Aufgaben
einmalige Workflows
Situationen ohne API-Zugang
„Human-in-the-loop“-Automationen (mit Freigaben für kritische Aktionen)

Aber sobald du Stabilität, Kostenkontrolle, Sicherheit und Skalierung brauchst, werden APIs wieder das, was sie immer waren:

Das langweilig zuverlässige Rückgrat.

Oder anders: Agenten sind die beeindruckenden Alleskönner, die jede UI bedienen können. APIs sind die unterschriebenen Verträge, die man braucht, wenn’s ernst wird.