WebMCP: Risiken, wenn KI-Agenten Webseiten steuern

Webseiten bekommen eine zweite Bedienoberfläche. Mit WebMCP rufen KI-Agenten Funktionen einer Seite direkt auf, statt sich durch das Layout zu klicken. Chrome testet die Schnittstelle seit Juni 2026 im Origin Trial, inzwischen auch Edge. Shopify stellt sie auf allen Liquid-Storefronts bereit, seit dem 28.09.2026 auch im Checkout. Der Spec-Entwurf listet die Sicherheitsprobleme gleich mit, allen voran Prompt Injection über Tool-Metadaten. Für Betreiber entsteht damit ein zweiter Zugriffspfad auf ihre Anwendung, der eigene Absicherung braucht.

Was ist WebMCP? Der W3C-Entwurf im Überblick

WebMCP ist eine Browser-Schnittstelle, mit der Webseiten eigene Funktionen als Tools für KI-Agenten registrieren. Agenten rufen diese Tools strukturiert auf, statt die Oberfläche per Screenshot oder DOM-Analyse zu interpretieren. Die Spezifikation entsteht als Draft Community Group Report der W3C Web Machine Learning Community Group und ist kein verabschiedeter Standard.

Der Beitrag stützt sich auf den Entwurf vom 29.09.2026. Die API verankert sich am Dokument: document.modelContext. Websites melden dort Tools mit Name, Beschreibung und Eingabe-Schema an. Der Agent bekommt strukturierte Antworten zurück.

Unter webmcp.dev findet sich eine gleichnamige JavaScript-Bibliothek eines Einzelentwicklers. Das README verweist seit dem 12.02.2026 auf das offizielle W3C-Repository. Die eigene Implementierung gilt dort als nicht spec-konform. Wer WebMCP evaluiert, sollte ausschließlich mit dem W3C-Entwurf und der Chrome-Dokumentation arbeiten.

Die WebMCP-Bibliothek auf webmcp.dev mit blauem Verbindungs-Widget, nicht identisch mit dem W3C-Entwurf Namensvetter: die ältere Bibliothek auf webmcp.dev arbeitet mit einem Widget und lokaler Bridge. Der W3C-Entwurf funktioniert ohne Zusatzsoftware im Browser. (Screenshot: webmcp.dev, 01.09.2026)

So ruft ein Browser-Agent Webseiten-Tools auf

Der Entwurf sieht zwei Wege vor. Das begleitende Explainer-Dokument beschreibt die deklarative Variante, deren Spec-Abschnitt noch ein Platzhalter ist. Bestehende HTML-Formulare erhalten die Attribute toolname und tooldescription:

<form toolname="createSupportRequest"
  tooldescription="Submits a request for customer support.">
  <!-- bestehende Formularfelder werden zu Tool-Parametern -->
</form>

Die Exponierung ist damit ein Opt-in im Markup: Als Tool erscheint nur ein Formular mit diesen Attributen. Die imperative Variante registriert Tools per JavaScript über document.modelContext.registerTool(), inklusive Eingabe-Schema und Callback. Der Zugriff ist über die Permissions Policy tools gesteuert, deren Standard-Allowlist auf 'self' steht.

Für Betreiber heißt das: Ohne eigene Registrierung bietet eine Website Agenten keine WebMCP-Schnittstelle an. Anders bei Shopify: Liquid-Storefronts liefern seit dem 05.08.2026 zehn Standard-Tools automatisch aus, darunter Katalogsuche und Warenkorb. Seit dem 28.09.2026 kommen vier Checkout-Tools hinzu, mit complete_checkout schickt ein Agent die Bestellung nach Bestätigung durch den Käufer ab. Cloudflare bietet zudem eine Developer Preview an, die WebMCP nach Aktivierung im Dashboard per Edge-Injection ohne Änderung am Origin-Code nachrüstet.

Eine zentrale Registry fehlt. Die Chrome-Dokumentation listet dies als Einschränkung auf. Agenten müssen eine Seite direkt aufrufen, um Tools zu finden. Seit Ende August 2026 nutzt der Browser der ChatGPT-Desktop-App solche Site Tools. Dies betrifft ChatGPT Work und Codex mit GPT-5.6 Sol oder Terra. Mit GPT-5.6 Luna und in Enterprise- oder Edu-Workspaces steht die Funktion nicht zur Verfügung.

Prompt Injection: drei Angriffsvektoren im Spec-Entwurf

Abschnitt 6.3.1 des Entwurfs benennt drei Vektoren. Erstens Tool Poisoning: bösartige Anweisungen in Tool-Namen, Beschreibungen oder Parameter-Definitionen manipulieren den Agenten. Zweitens Output Injection: Rückgabewerte eines Tools enthalten Anweisungen, etwa über eingebettete Nutzerkommentare. Drittens die Tool-Implementierung selbst als Angriffsziel, weil der Tool-Pfad eine andere Validierungslogik durchlaufen kann als die Benutzeroberfläche.

Abschnitt 6.3.1 des WebMCP-Entwurfs beschreibt Prompt-Injection-Angriffe inklusive Beispiel-Attacke in der Tool-Beschreibung Der Entwurf dokumentiert den Angriff gleich mit: eine Tool-Beschreibung mit versteckter "SYSTEM INSTRUCTION" soll den Agenten kapern. (Screenshot: webmachinelearning.github.io/webmcp, Draft vom 26.08.2026)

Ein als Tool exponiertes Formular ist ein zweiter Endpunkt. Captcha-Widgets, Honeypot-Felder und clientseitige Validierung hängen am UI-Pfad und prüfen den Tool-Aufruf nicht automatisch. Rate Limiting und Validierung gehören deshalb serverseitig in den Tool-Callback.

Laut Abschnitt 6.3.2 können Agenten nicht prüfen, ob eine Tool-Beschreibung dem tatsächlichen Verhalten entspricht.

Abschnitt 6.3.3 beschreibt Silent Profiling. Eine Seite definiert überflüssige Parameter wie Alter oder Standort. Ein hilfsbereiter Agent füllt sie aus seinem seitenübergreifenden Kontext. Damit sammelt der Betreiber Daten ohne bewusste Freigabe.

Im Entwurf vom 29.09.2026 enthält Abschnitt 6.3.4 zu Same-Origin-Grenzen lediglich einen TODO-Vermerk. Das Sicherheitsmodell in diesem Bereich ist daher noch ungeschrieben.

Die Chrome-Sicherheitshinweise nennen zwei Angriffsvektoren: manipulierte Tool-Definitionen und kontaminierte Tool-Antworten. Sicherheitsgarantien im Modell selbst hält Google wegen der probabilistischen Natur von Sprachmodellen für unmöglich.

Seit 2023 betrachtet das BSI Indirect Prompt Injections als intrinsische Schwachstelle anwendungsintegrierter Sprachmodelle. Der LLM-Penetrationstest zeigt, wie sich solche Schwächen systematisch testen lassen.

Session und Audit Trail: was der Standard offenlässt

Ein Agent im Browser arbeitet innerhalb der angemeldeten Sitzung. Bitwarden weist darauf hin, dass browser-native Agenten ohne neue Anmeldung mit den bestehenden Zugriffsrechten des Nutzers agieren und Tool-Beschreibungen keine durchsetzbaren Berechtigungen sind. Ein Modell kann Anweisungen missverstehen oder manipulierter Anleitung folgen.

Für Betreiber kommt ein Nachweisproblem dazu. Ein Community-Sicherheitsdossier zur gleichnamigen Browser-Erweiterung (Stand 2025) beschreibt, dass Agenten-Aktionen in Logs nicht von Nutzer-Aktionen unterscheidbar sind und feingranulare Tool-Berechtigungen fehlen. Der W3C-Entwurf gibt der Seite nur clientseitige Signale. Das Event toolactivated meldet den Start eines Tool-Aufrufs, das Explainer-Dokument sieht für Formulare das Feld agentInvoked am Submit-Event vor. Im Server-Log landet davon nichts automatisch. Wer nachvollziehen muss, ob ein Mensch oder ein Agent eine Bestellung ausgelöst hat, muss diese Signale selbst an den Server weitergeben.

WebMCP im Browser-Vergleich: Chrome und Edge testen, Safari lehnt ab

Browser	Stand 30.09.2026	Quelle
Chrome	Origin Trial von Chrome 149 bis 156, Start im Juni 2026	Chrome-Entwicklerblog, Chrome Platform Status
Edge	Origin Trial ab Edge 150	WebMCP-Implementierungsstatus der W3C-Gruppe
Brave	experimentell im KI-Assistenten Leo	WebMCP-Implementierungsstatus der W3C-Gruppe
Safari/WebKit	Position "oppose", acht Concern-Labels	WebKit standards-positions #670
Firefox/Mozilla	Position "neutral" (seit 05.08.2026)	Mozilla standards-positions #1412

WebKit begründet die Ablehnung mit einem Grundsatzargument: Wenn Agenten eine Seite nicht bedienen können, sei das eine Lücke in der Semantik der Seite. Die Lösung gehöre in die gemeinsamen Plattform-Schichten HTML und ARIA, nicht in eine parallele Tool-Schicht für Agenten.

Das WebKit-Issue 670 trägt das Label "position: oppose" sowie acht Concern-Labels von API-Design bis Privacy Safari bleibt draußen: WebKit führt für WebMCP die offizielle Position "oppose". (Screenshot: github.com/WebKit/standards-positions, Issue #670, 01.09.2026)

Webseite absichern: fünf Prüfpunkte vor dem WebMCP-Einsatz

Fünf Punkte entscheiden darüber, ob ein Tool-Rollout vertretbar ist:

Das Tool-Inventar klein halten: nur Funktionen exponieren, die ein Agent legitim braucht. Schreibende Tools wie Formular-Submits wiegen schwerer als lesende.
Rate Limiting und Eingabe-Validierung serverseitig in den Tool-Callback ziehen. Kontrollen, die am UI-Pfad hängen, prüfen den Agenten-Aufruf nicht.
Jedes Feld im Eingabe-Schema streichen, das der Anwendungsfall nicht zwingend braucht. Das begrenzt Silent Profiling und die Datenschutz-Angriffsfläche.
Nutzergenerierte Inhalte in Rückgabewerten kennzeichnen. Der Entwurf sieht dafür die Annotation untrustedContentHint vor.
Agenten-Aufrufe im Server-Log kenntlich machen, etwa über getrennte Endpunkte oder einen Request-Marker, der aus toolactivated oder agentInvoked gesetzt wird.

In einem Penetrationstest für Web-Applikationen gehören solche Zusatzpfade in den Prüfumfang. Für Systeme, die selbst Agenten einsetzen, existiert mit der Sicherheitsanalyse für KI-Agenten ein eigenes Prüfformat.

Einordnung

WebMCP zielt auf eine reale Schwäche: Ohne strukturierte Schnittstelle muss ein Agent die Oberfläche einer Seite interpretieren, um sie zu bedienen. Hinter dem Entwurf stehen Google und Microsoft, Shopify und Cloudflare liefern erste Implementierungen. Bei Shopify reicht die Schnittstelle inzwischen bis zum Absenden der Bestellung.

Im Entwurf bleibt der Sicherheitsteil unvollständig. Der Same-Origin-Abschnitt enthält weiterhin einen TODO-Vermerk.

Betreiber behandeln WebMCP deshalb am besten wie jede neue API: mit Bedrohungsmodell und serverseitiger Validierung. Die Sicherheitsrisiken autonomer KI-Agenten erhalten mit der Standardisierung einen definierten Weg in die eigene Anwendung. Ein Formular-Attribut, das man nebenbei setzt, ist WebMCP nicht.

Wie WebMCP die Angriffsfläche verändert: KI-Agenten bedienen Webseiten direkt