WebMCP und Agentic Web: Was Website-Betreiber jetzt entscheiden müssen

Cloudflare hat am 6. August 2026 eine Beobachtung veröffentlicht, die den Umbau zum Agentic Web genauer beschreibt als jede Roadmap. Ein grosser Teil des Traffics von Bots, die sich an die Regeln halten, besteht aus dem erneuten Abruf von Seiten, die sich seit dem letzten Crawl nicht verändert haben. Milliarden Requests, für die auf beiden Seiten jemand Rechenzeit bezahlt, ohne dass ein Ergebnis entsteht. Das ist die Signatur eines Webs, das für Menschen gebaut wurde und inzwischen von etwas anderem besucht wird.

Für Website-Betreiber läuft das auf eine Entscheidung hinaus, die kein Standard für sie trifft: welche Agenten sie überhaupt zulassen, welche sie begrenzen oder blockieren und welche sie abrechnen. WebMCP macht diese Entscheidung akut, weil es Seiten erstmals erlaubt, eigene Funktionen direkt als aufrufbare Werkzeuge für Agenten zu registrieren, statt auf geratene Klicks in der Seitenstruktur zu hoffen. Wer diese Schnittstelle öffnet, öffnet gleichzeitig eine Abrechnungs- und Haftungsfrage.

Agentic Web bezeichnet den Zustand, der daraus folgt: eine Schicht, in der Software im Auftrag zahlender Menschen Ressourcen entdeckt, liest, aufruft und bezahlt. Drei Fragen entscheiden darüber, ob diese Schicht funktioniert. Wie findet ein Agent überhaupt heraus, was es gibt? Wie weist er nach, in wessen Auftrag er handelt? Und wie ruft er eine Website auf, ohne auf Knöpfe zu klicken?

Für jede dieser Fragen liegt inzwischen ein Artefakt auf dem Tisch. Für die Auffindbarkeit die offene Spezifikation Agentic Resource Discovery, kurz ARD, veröffentlicht am 17. Juni 2026 von einer Koalition aus elf Unternehmen. Für den Nachweis der Vollmacht ein Internet-Draft von Soohong Daniel Park (Samsung) und Imran Siddique (Opaque) in Version -03 vom 28. August 2026. Das Dokument ist eine Einzeleinreichung ohne Arbeitsgruppe und ohne formalen Status bei der Internet Engineering Task Force. Es läuft am 1. März 2027 ab, wenn es niemand weiterträgt, bleibt aber die präziseste vorliegende Problembeschreibung. Für den Aufruf ohne Klick schliesslich WebMCP, eine JavaScript-Schnittstelle, die das Werkzeugmodell des Model Context Protocol auf Webseiten überträgt. Keines der drei Artefakte ist ein verabschiedeter Standard.

Meine These: Das agentische Web tauscht Websites nicht gegen Programmierschnittstellen, es verschiebt die Knappheit. Auffindbarkeit, überprüfbare Delegation, kontrollierbare Aktionen und bezahlbare Nutzung werden knapper als Seitenaufruf und Werbeklick. Zwei Prüfungen klären den Ausgangspunkt. Lässt sich aus dem eigenen Log rekonstruieren, wer eine Agentenaktion beauftragt hat, mit welchem Delegationsumfang und welchem Ausgabelimit? Und unterscheidet die eigene Bot-Policy zwischen einem Scraper und einem nachweislich im Kundenauftrag delegierten Agenten? Warum gerade diese zwei Fragen tragen, ergibt sich aus den Spezifikationen, die derzeit entstehen.

Discovery entscheidet, was im Agentic Web überhaupt existiert

ARD beruht auf zwei Bausteinen. Eine Organisation publiziert unter ihrer Domain einen Katalog als ai-catalog.json an einem well-known Pfad, den Software ohne Absprache findet. Die Domain-Kontrolle belegt die Herkunft des Katalogs; kryptografische Authentizität entsteht über Trust-Manifeste und Signaturen. Registries, also Verzeichnisdienste, crawlen und indexieren diese Kataloge. Ein Katalog kann MCP-Server, Agent-Cards für die Kommunikation zwischen Agenten, klassische Programmierschnittstellen und weitere Kataloge enthalten. Danach verbindet sich der Agent direkt über das native Protokoll der Ressource.

Das ist bewusst schmal geschnitten und dadurch belastbar. Die Spezifikation steht unter Apache 2.0, baut auf dem AI-Catalog-Datenmodell einer Linux-Foundation-Arbeitsgruppe auf und liegt in Version 0.91 vor. Das Modell ist ausdrücklich föderiert: Jede Organisation kann eine eigene Registry betreiben, ein zentraler Katalog ist nicht vorgesehen. Die kommerzielle Anschlussstelle steht trotzdem im selben Ankündigungstext. Die Agent Registry in Googles Gemini Enterprise Agent Platform vergibt global eindeutige Namen, erzwingt Regeln dafür, wohin ein Agent hinausrufen darf, und nagelt Werkzeuge auf geprüfte Versionen fest. Native ARD-Unterstützung dort ist für die kommenden Monate angekündigt, also noch nicht ausgeliefert. Darin liegt die Spannung: Eine föderierte Spezifikation nützt wenig, wenn die reale Registry-Nutzung am Ende bei einem einzigen Anbieter landet.

Der Internet-Draft beschreibt dieselbe Aufgabe strenger. Discovery soll föderiert funktionieren, ohne eine zwingend zentrale Registry (REQ-DISC-3). Ergebnisse sollen Endpunkt, Protokollversion, Fähigkeits-Identifikatoren, Autorisierungsmetadaten, Zahlungsunterstützung und Vertrauensmaterial ausdrücken können (REQ-DISC-4), und die Metadaten brauchen einen Mechanismus für Echtheit und Integrität (REQ-DISC-5). Zwei Anforderungen sind für Betreiber unbequemer als der Rest: Ranking- und Reputationsinformationen dürfen ausdrücklich nicht als Identitäts- oder Autorisierungsnachweis gelten (REQ-CAP-4), und intent-basierte Suche soll Offenlegung minimieren, weil schon die Anfrage sensible Ziele verrät (REQ-CAP-5).

Delegation ist die eigentliche Lücke

Ein Beispiel macht das Problem greifbar. Eine Kundin beauftragt ihren Assistenten, ein Hotel zu buchen. Der Assistent beauftragt einen spezialisierten Reise-Agenten, der wiederum den Buchungsdienst des Hotels beauftragt. Beim Hotel kommt eine gültige, kryptografisch einwandfreie Anfrage an. Offen bleibt: Wer haftet, wenn zweimal gebucht wird? Durfte der Assistent überhaupt weiterdelegieren? Und wo endet das Budget?

Genau hier setzt die Problemstellung des Internet-Drafts an, die sich wie das Protokoll einer Fehleranalyse nach einem Zwischenfall liest. Ein Server kann einen TLS-Peer authentisieren, also die Gegenstelle einer verschlüsselten Verbindung, und ein OAuth-Token validieren, ein Zugangstoken, wie es beim Anmelden über Google oder Microsoft ausgestellt wird, ohne zu wissen, welcher Agent gerade handelt, welcher Mensch oder welche Organisation die Handlung delegiert hat, ob Weiterdelegation erlaubt war und ob die Transaktion noch innerhalb eines Ausgabelimits liegt. Diese vier Fragen entscheiden im agentischen Web über Haftung.

Der Entwurf zieht daraus harte Trennlinien. Agentenidentität muss von der Identität des vertretenen Menschen oder der Organisation unterscheidbar sein (REQ-AUTH-1). Mehrstufige Delegation soll Auftraggeber und autorisierte Zwischenschritte nachprüfbar erhalten (REQ-AUTH-3), Zeit-, Wert- und Kontextgrenzen ausdrücken und Weiterdelegation regeln (REQ-AUTH-4). Ein Resource Server muss die geltende Befugnis bestimmen können, ohne unbestätigten Angaben eines vermittelnden Agenten zu glauben (REQ-AUTH-5).

Die schärfste Zeile steht im Abschnitt zu Identität und Vertrauen: Vertrauensentscheidungen dürfen nicht allein aus erfolgreicher Authentisierung abgeleitet werden (REQ-ID-4). Dazu passt die Definition von Intent im Begriffsteil, wonach eine erklärte Absicht für sich genommen kein Autorisierungssignal ist. Das Architekturprinzip Separation of Concerns verbietet, Identität, Autorisierung, Delegation, Intent, Zahlung und Audit stillschweigend zu vermischen.

Wer Agenten im Unternehmen eingeführt hat, kennt diese Disziplin aus der Berechtigungsarbeit vor dem ersten produktiven Workflow. Neu ist der Massstab über fremde Verwaltungsdomänen hinweg. Für Betreiber in der Schweiz und der EU kommt eine Ebene dazu, sobald ein Agent im Auftrag eines Nutzers Personendaten bearbeitet. Artikel 6 des revidierten Schweizer Datenschutzgesetzes verlangt Rechtmässigkeit, Treu und Glauben, Verhältnismässigkeit und Zweckbindung; Artikel 5 der Datenschutz-Grundverordnung nennt dieselben Grundsätze und ergänzt die Rechenschaftspflicht. Wie diese Pflichten auf mehrstufige Agentenketten durchschlagen, ist noch nicht geklärt. Die technische Konsequenz deckt sich mit REQ-AUTH-3 und REQ-AUTH-4: Wer Auftraggeber und Reichweite der Vollmacht nicht zeigen kann, kann auch Zweckdeckung und Verhältnismässigkeit nicht belegen. Genau daran scheitert der Versuch, eine Agenten-Transaktion aus dem Log zu ziehen und Auftraggeber, Delegationsumfang und Ausgabelimit zu rekonstruieren.

WebMCP gibt der Seite eine zweite Fläche

WebMCP ist eine JavaScript-Schnittstelle, mit der eine Seite ihre Funktionalität als Werkzeuge registriert, inklusive Beschreibung und strukturiertem Schema. Sie übernimmt das Werkzeugmodell von MCP, schreibt aber kein Transportformat zwischen Browser und Agent vor. Ein Browser kann die registrierten Werkzeuge deshalb auch über proprietäres Function Calling oder ein anderes Verfahren bereitstellen. Da die Werkzeuge in der Seite laufen, nutzen sie die bestehende Session und den Zustand des Nutzers weiter. Der Entwurf zielt auf Abläufe, in denen Mensch und Agent in derselben Oberfläche arbeiten.

Das gängige Bild vom Verschwinden der Website ist verfrüht. WebMCP liegt als Entwurf einer W3C Community Group ausserhalb des Standards-Tracks vor. Chrome hat die Schnittstelle laut Entwicklerankündigung vom 9. Juni 2026 ab Chrome 149 in einen Origin Trial gegeben, ein zeitlich begrenztes Testprogramm. Die Richtung ist erkennbar: Eine Seite bekommt eine zweite, versionierte Fläche mit einem Werkzeugvertrag statt geratener Klicks in der vom Browser gelesenen Seitenstruktur.

Den Rahmen dafür liefert der MCP-Spezifikationsstand 2026-07-28. Er hat den Protokollkern zustandslos gemacht, Sessions und Handshake gestrichen, ein formales Extensions-Framework eingeführt und die Autorisierung gehärtet, unter anderem mit Prüfung des ausstellenden Dienstes nach RFC 9207 und mit Client ID Metadata Documents als künftigem Standardpfad für die Client-Registrierung. Mehrstufige Delegation und Bezahlung definiert das Dokument weiterhin nicht. Wer MCP als vollständigen Stack verkauft, überdehnt es.

Wie teuer die alte Fläche im Maschinenbetrieb ist, zeigt ToolPro, ein System aus einem an der ICML 2026 angenommenen und damit begutachteten Paper von Mugeng Liu und Kollegen an der Peking University. Die Autoren argumentieren, dass statische Endpunkte lange Arbeitsabläufe mit Schleifen, Bedingungen und Wiederholungen schlecht abbilden, und kodieren die Absicht eines Agenten stattdessen als ausführbares Werkzeugprogramm mit expliziten Effekt-Typen und WebAssembly-Sandboxing, einem Format, in dem fremder Code isoliert läuft. Gemessen an realen Abläufen über MCP-artige Dienste sinkt die Ende-zu-Ende-Latenz um bis zu 53,4 Prozent und der clientseitige Traffic um bis zu 96,1 Prozent. Das bleibt eine Forschungsimplementierung ohne Produktionserfahrung, aber sie benennt die Betriebsfrage präzise: Sobald ein Werkzeug Zustand ändert, wird die Garantie, dass ein Aufruf genau einmal wirkt, auch wenn er zweimal ankommt, zur Pflicht.

Der Klick verschwindet, die Rechnung bleibt

Cloudflare ordnet das agentische Internet in vier Begriffe: lesbar, auffindbar, aufrufbar, bezahlbar. Die Anbieterarchitektur mit klarem Eigeninteresse beschreibt das Finanzierungsproblem trotzdem präzise. Werbung und Sitzplatzlizenzen greifen schlecht, wenn der Nutzer ein Programm ist. Cloudflare skizziert deshalb Bruchteile eines Cents pro Abruf, Lizenzierung zur Lesezeit, Authentisierung, Wallets und x402. Im selben Text stehen zwei Sätze, die man zusammen lesen sollte: Cloudflare sei eine Option und nicht der ganze Stack, und Cloudflare sitze absichtlich in der Mitte von all dem.

Die Werbeindustrie antwortet mit den Agentic Advertising Management Protocols des IAB Tech Lab. Eine Ausführungsschicht beansprucht 80 Prozent weniger Latenz in Anzeigenauktionen. Daneben stehen Protokolle für agentische Werbung und eine seit Anfang März 2026 offene Registry für Identität, Verifikation und Offenlegung. Bestehende Standards wie OpenRTB schaffen Anschlussfähigkeit, belegen aber noch keine Verbreitung.

Die sichtbarste wirtschaftliche Ausprägung dieser Schicht läuft derzeit unter Agentic Commerce: Assistenten wählen Produkte, füllen Warenkörbe und lösen Zahlungen aus. Für Händler verschiebt das die Optimierungsfläche von Produktseite und Checkout auf Katalogdaten, Werkzeugverträge und Abrechnungsbelege. Ohne nachprüfbare Delegation bleibt eine eingegangene Bestellung im Streitfall eine Behauptung.

x402 scheitert an der Bindung von Zahlung, Ressource und Zustand

x402 belebt den lange ungenutzten HTTP-Statuscode 402 wieder, mit dem ein Server signalisiert, dass eine Ressource Geld kostet. Eine systematische Sicherheitsanalyse beziffert in ihrer Fassung vom 22. Juni 2026 den Stand mit 130 Millionen Transaktionen seit Beginn und mit Einbettungen bei Google Cloud, Cloudflare und Stripe. Diese Zahl ist kumulativ. Dieselbe Arbeit hält fest, dass das monatliche Volumen Ende 2025 seinen Höhepunkt erreichte und seither zurückgeht. Als Momentum-Beleg taugt sie damit nicht, als Beleg für Verankerung in grossen Stacks schon.

Der Sicherheitsbefund wiegt schwerer. Die Autoren zeigen, dass die Verbindung synchroner HTTP-Anfragen mit asynchroner Blockchain-Finalität Zustandssynchronisation zum Problem macht, und ordnen Verstösse gegen fünf Invarianten der verantwortlichen Schicht zu: Protokoll, SDK oder Deployment. Sie beschreiben vier Fehlerklassen: Substitution über Ressourcengrenzen hinweg, ein Wettrennen bei doppelter Abrechnung, Überziehung der Freigabe und Verweigerung der Abrechnung. Gegen offizielle SDKs und ein Produktivdeployment erreichen diese Fälle Ressourcenverluste von bis zu 100 Prozent, und das Wettrennen bei doppelter Abrechnung wurde durch spätere Berichte Dritter unabhängig bestätigt. Für Bezahlung pro Token beweisen sie zusätzlich eine strukturelle Grenze, weil eine rein ausgabebasierte Bepreisung nicht gleichzeitig fair und gegen aufgeblähte verborgene Denk-Token abgesichert sein kann. Ihre vorgeschlagene Verteidigung senkt die Reasoning-Kosten pro Aufruf um 47 Prozent und dreht den Angreifervorteil von 8,7-fach auf 0,9-fach bei 2,8 Prozent Overhead. Alle Befunde wurden offengelegt; das Papier bleibt ein Preprint.

Die dazu passenden Anforderungen stehen wieder im Internet-Draft. Ein Zahlungsnachweis soll so an die Anfrage gebunden sein, dass er nicht für eine andere Ressource oder einen anderen Betrag wiederverwendet werden kann (REQ-PAY-2), maschinenlesbare Belege sollen sich mit Autorisierungs- und Audit-Daten korrelieren lassen (REQ-PAY-4), und ein Auftraggeber muss Ausgaben nach Betrag, Wertklasse, Empfänger, Zeit und Transaktionstyp begrenzen können (REQ-PAY-1). Dass HTTP 402 nach Jahrzehnten Dornröschenschlaf als Muster wieder auftaucht, ist die eigentliche Nachricht an alle, die den Agentenverkehr bisher als reines Traffic-Thema behandelt haben.

Die falschen Betreiberannahmen

Erste Annahme: Maschinenlesbarkeit erzeugt Vertrauen. Das Symptom zeigt sich spät, wenn Katalog und Werkzeuge stehen, der Agentenverkehr steigt und trotzdem niemand sagen kann, in wessen Auftrag eine Aktion lief. Die Ursache ist die Vermischung von Authentisierung und Handlungsbefugnis, die der Internet-Draft ausdrücklich untersagt. Geprüft wird das über die eingangs genannte Rekonstruktion aus dem eigenen Log. Misslingt sie, gehört kein zustandsändernder Endpunkt in den Katalog.

Zweite Annahme: Bots blocken schützt den Umsatz. Ein Preprint zur normativen Infrastruktur des agentischen Webs, Stand 15. Juli 2026, argumentiert, dass veraltete Gesetze, Nutzungsbedingungen und informelle Praktiken es Plattformen erlauben, Agentenzugriff zu blockieren oder zu verschlechtern, häufig unbemerkt, und dass zwischen schädlichen Bots und Agenten mit ausdrücklich delegierter Nutzerbefugnis kaum unterschieden wird. Die Autoren stellen dem eine Trias entgegen: Delegation, also dass ein zugangsberechtigter Nutzer diesen Zugang auch über einen von ihm autorisierten Agenten ausüben darf; Transparenz, also dass Agenten Identität und Zweck offenlegen und Plattformen ihre Zugriffsregeln; und verhältnismässige Beschränkung, also dass eine Plattform nur konkrete Schäden abwehrt und dabei das mildeste verfügbare Mittel wählt. Eine Spezifikation kann dafür Kriterien, Metadaten und Nachweise abbilden, aber die rechtliche Prüfung im Einzelfall nicht ersetzen. Das schliesst an die zuvor genannten Grundsätze des DSG und der DSGVO an.

Eine pauschale Blockade aller Agenten trifft ungeprüft auch Nutzer, die einen legitimen Auftrag delegiert haben; eine pauschale Öffnung verzichtet auf jede Kontrolle. Welche Variante im Einzelfall haltbar ist, hängt an Zweck, Risiko und Dokumentation. Eine Policy, die den Unterschied gar nicht kennt, kann diese Abwägung nicht belegen. Das Symptom sind Beschwerden von Kunden, deren Assistent im Bestellprozess scheitert. Die zweite Prüfung ist eine einzige Frage an die eigene Bot-Policy: Gibt es darin überhaupt eine Klasse für einen nachweislich delegierten Nutzeragenten, oder wird jeder Agent wie ein gewöhnlicher Scraper behandelt? Falls nicht, sind Policy-Klassen die dringendere Arbeit als schärfere Rate-Limits.

Dritte Annahme: Die Zahlungsschicht klärt Attribution. Die x402-Analyse zeigt das Gegenteil, weil doppelte Abrechnung und Freigabe-Überziehung genau dort entstehen, wo Bezahlung, Ressource und Zustand auseinanderlaufen. Das Symptom sind Belege, die nicht zu ausgelieferten Ressourcen passen. Der Test besteht darin, eine Abrechnung gegen eine andere Ressource desselben Preises erneut einzureichen. Wer diesen Fall nicht sauber abweist, braucht Idempotenz, also die Garantie, dass eine zweimal gesendete Anweisung nur einmal wirkt, bevor er über Preismodelle nachdenkt. Sonst zahlt bei der Rezeptseite am Ende jemand doppelt für dasselbe Rezept.

Wer definiert, welcher Agent legitim ist

Der Internet-Draft verlangt eine Architektur ohne zwingende globale Registry, einzelnen Identitätsanbieter oder Zahlungsdienst. Die reale Anbieterlandschaft zieht in die Gegenrichtung: Google besetzt Discovery, Cloudflare Zugang und Monetarisierung, das IAB Tech Lab die Verifikation der Werbekette.

Cloudflare formuliert die Gabelung selbst und benennt beide Enden: Entweder besitzt eine Handvoll Stacks Discovery, Identität und Zahlungen, oder es entstehen neutrale Schienen aus offen implementierbaren Standards. Beide Beschreibungen stammen von einem Unternehmen, das diese Schienen verkauft. Genau deshalb ist REQ-CAP-4 die interessanteste Zeile im ganzen Entwurf. Ranking soll kein Autorisierungsnachweis sein, doch wer die Registry betreibt, bestimmt Ranking, und Ranking entscheidet, welche Fähigkeit überhaupt aufgerufen wird. Das ist das alte Suchmaschinenproblem, diesmal ohne einen Menschen, der weiterscrollen könnte. Die akademische Synthese von Yang und Kollegen zum agentischen Web (Juli 2025) ordnet diese Dynamik als eigene Ökonomie ein und spricht von einer Agent Attention Economy; als Taxonomie ist das nützlich, als Adoptionsbeleg taugt es nicht.

Was Betreiber jetzt entscheiden müssen

Der Internet-Draft verlangt korrelierbare Audit-Belege zu Agent, Auftraggeber, Autorisierung, Zeitstempel, Policy-Grenzen, Ergebnis und Zahlung (REQ-AUD-1). Solche Ketten werden zu Beweismitteln bei Streitfällen und Rückbuchungen. Gewöhnliche Access-Logs mit kurzer Aufbewahrung reichen dafür nicht.

Auch die Messlogik ändert sich. Seitenaufrufe verlieren an Aussagekraft, während aufrufbarer Verkehr eigene Kennzahlen braucht. Cloudflare bietet dafür Agent Engine Optimization an. Wer Messung und Bot-Policy beim selben Anbieter bündelt, sollte diese Abhängigkeit bewusst bepreisen.

Die Reihenfolge bleibt überschaubar und folgt der eingangs skizzierten Entscheidung zwischen zulassen, begrenzen und abrechnen. Ein lesender Katalog liefert zunächst Daten über reale Agentennachfrage, ohne etwas freizugeben. Danach folgen eine eigene Policy-Klasse für delegierte Nutzeragenten sowie klar modellierte Rechte und Widerruf, also die Begrenzung. Ein zustandsändernder oder abrechnungspflichtiger Endpunkt kommt erst danach und nur mit Audit-Beleg. Eine Pflichtarchitektur auf Basis eines Entwurfs wäre dagegen eine Wette auf unreife Schichten.

Wer heute eine belastbare Antwort auf die Frage hat, wer bezahlt hat und in wessen Auftrag, ist auf das agentische Web besser vorbereitet als jemand, der bereits vier Protokolle implementiert hat.