Amazon gegen Metas Shopping-Agenten Muse: Warum die Grenze bei der Hoheit über die Session liegt, nicht bei der Identität des Agenten

Meine Agenten steuern ein echtes Chrome auf meinem Desktop. Es ist in Arbeits- und Kundenkonten eingeloggt, und wenn ein Agent dort eine Seite öffnet, sieht die Website auf der anderen Seite meinen Browser, meine Cookies, meine Session. Nichts im Traffic verrät, dass ein Agent am Steuer sitzt. Der Agent weist sich genau so aus wie ich, wenn ich selbst surfe.

Das ist der unbequeme Ausgangspunkt für die Nachricht der letzten Woche: Amazon hat Metas Muse ausgesperrt, und einer der Vorwürfe lautete, dass Muse sich beim Browsen nicht zu erkennen gibt. Meine Agenten tun das auch nicht. Nach Amazons eigenem Maßstab betreibe ich Muse zu Hause.

Was genau hat Amazon an Metas Agenten Muse beanstandet?

Amazon nannte gegenüber GeekWire drei Punkte, wie The Register am 21. September berichtete: Meta habe Amazon nicht mitgeteilt, dass es Muse auf die Seite schicken wolle, und keine Genehmigung eingeholt; Muse gebe sich beim Browsen nicht zu erkennen; und Muse scheine Kundenzugangsdaten abzugreifen und zu speichern, mit Zugriff auf Kontodaten wie die Bestellhistorie. Wer Amazon über Muse aufruft, bekommt eine Fehlerseite, laut der der Zugriff durch einen nicht autorisierten AI-Agenten gegen Amazons Nutzungsbedingungen verstößt. Metas Antwort betraf nur die Zugangsdaten: Sie lägen in einem sicheren Speicher und würden zur Authentifizierung verwendet, ohne dem Modell offengelegt zu werden.

Muse ist am 8. September gestartet und stand, als TechCrunch am 25. nachsah, seit dem 18. beziehungsweise 19. auf Platz eins in beiden US-App-Stores. Amazon hat bereits Shopping-Agenten von Google und OpenAI blockiert und Perplexity wegen Comet verklagt. Amazon betreibt außerdem einen eigenen Agenten, Buy for Me, der auf den Websites anderer Händler einkauft, sich zu erkennen gibt und diesen Händlern ein Opt-out lässt. The Register beziffert Amazons Werbeumsatz im letzten Jahr auf über 68 Milliarden Dollar, Geld, das davon abhängt, dass Menschen Amazons Seiten ansehen.

Zwei mögliche Grenzen liegen also auf dem Tisch. Der Agent sagt, wer er ist. Oder die Zugangsdaten verlassen nie die Kontrolle des Nutzers. Die erste ist für mich überhaupt keine Sicherheitsgrenze, und die zweite ist an der falschen Stelle gezogen.

Schützt es den Nutzer, wenn sich ein AI-Shopping-Agent zu erkennen gibt?

Es schützt die Möglichkeit der Website, zu entscheiden, und das ist etwas anderes. Das Urteil sagt es ausdrücklich. Als der Ninth Circuit im August über Amazons Klage gegen Perplexity entschied, beschrieb er den Kern des Streits so:

At the core of the dispute was Perplexity’s decision not
to use a “user-agent string,” a mechanism “that would
communicate that the user has activated an AI agent.” That
user-agent string would allow Amazon to block the
Assistant’s access to the Amazon store.

Die Identifikation, die Amazon wollte, hatte eine erklärte Aufgabe, und diese Aufgabe war das Blockieren. Buy for Me zeigt denselben Mechanismus von der anderen Seite: Der Agent gibt sich zu erkennen, damit andere Händler ihn ablehnen können. Das ist das Vetorecht, das genau wie vorgesehen funktioniert, angeboten von dem Unternehmen, das dasselbe Vetorecht an der eigenen Tür haben will.

Ein einfacher User-Agent-String ist außerdem nur eine Behauptung, die ein Client über sich selbst aufstellt. Die ernsthafte Variante ist deshalb kryptografisch. RFC 9421 definiert HTTP Message Signatures, und ein Entwurf einer IETF-Arbeitsgruppe, Web Bot Auth, nutzt sie, damit ein automatisierter Client seine Anfragen mit einem Schlüssel signieren kann, den sein Betreiber veröffentlicht. Ein Server kann dann prüfen, dass eine Anfrage wirklich vom Inhaber dieses Schlüssels stammt. Was der Server mit dieser Tatsache anfängt, ist eine eigene Entscheidung, und das Protokoll überlässt sie der Website. Die naheliegenden Optionen: zulassen, blockieren oder Geld verlangen. Eine verifizierte Identität macht einen Agenten haftbar und abrechenbar. Sie sagt nichts darüber, was der Agent dem Nutzer antut, in dessen Session er sitzt.

Das Recht weist in dieselbe Richtung, zumindest vorerst. Dasselbe Urteil stellte fest, dass auf Grundlage des vorliegenden Sachverhalts im Sinne des US-Anti-Hacking-Gesetzes und seines kalifornischen Gegenstücks der Nutzer und nicht Perplexity auf Amazons Computer „zugreift“, weil Perplexitys Server nie mit denen von Amazon in Berührung kommen und der Agent über den eigenen Browser des Nutzers arbeitet. Es ging um eine Berufung gegen eine einstweilige Verfügung; die Verfügung wurde aufgehoben und der Fall zurückverwiesen, und das Gericht stellte ausdrücklich klar, dass andere Fakten dazu, wie viel Kontrolle der Anbieter hat, zu einem anderen Ergebnis führen könnten. Amazon beantragte eine Neuverhandlung vor dem vollbesetzten Gericht (en banc); am 10. September lehnte das Gericht den Antrag ab, ohne dass auch nur ein Richter eine Abstimmung darüber verlangte. In einer Fußnote ergänzte der Richtersenat, sein Urteil beeinträchtige nicht Amazons Möglichkeit, den Zugang zu Amazon.com über private Nutzungsbedingungen für seine Nutzer zu regeln. Meine Lesart, und es ist nur eine Lesart: Der Streit verlagert sich auf diese Bedingungen, dieselben Conditions of Use, die Muse-Nutzer jetzt auf der Fehlerseite zitiert sehen.

Ist „das Modell sieht das Passwort nie“ die Grenze für AI-Agenten?

Es ist die richtige Art von Grenze an der falschen Stelle. Metas Behauptung ist eng gefasst: Der Passwort-String liegt in einem sicheren Speicher und wird zur Authentifizierung verwendet, ohne durch das Modell zu laufen. Schön. Aber sobald die Session offen ist, kann der Agent alles erreichen, was das Konto anzeigt: Bestellhistorie, Adressen, gespeicherte Zahlungsdaten, in welcher Form auch immer die Website sie darstellt. Wie viel davon tatsächlich beim Modell landet, hängt von der Implementierung ab. Das Passwort war immer nur der Schlüssel zur Session.

Das habe ich von meinen eigenen Agenten gelernt, und nicht im Browser. Agenten, die ich betreibe, haben Kunden-Mails in Ordner pro Kunde einsortiert, und die Filterung war so locker, dass der Thread eines Kunden im Ordner eines anderen landen konnte. Ich habe es bemerkt und auf strikte Labels pro Kunde plus Namensvalidierung umgestellt. Für den Fehler mussten keine Zugangsdaten durchsickern. Der Agent war schon drin, ganz legitim, und das Risiko war, wie weit er von dort aus reichen konnte. Ich habe schon argumentiert, dass was ein Tool erreichen kann und was es tatsächlich anfasst zwei getrennte Fakten sind, und das hier ist dieselbe Trennung eine Ebene höher: Eine Session gewährt Reichweite, und niemand fragt erneut, was der Agent damit macht.

Der ehrliche Test für jeden Agenten, der eine Session hält, ist also, ob der Nutzer sehen kann, was der Agent darin tut, und ob er ihm den Zugriff wieder entziehen kann. Keine der beiden Firmenstellungnahmen beantwortet das für Muse. Meta hat beschrieben, wie das Passwort aufbewahrt wird; Amazon hat beschrieben, was es befürchtet. Keiner hat gesagt, was ein Muse-Nutzer einsehen oder widerrufen kann.

Warum ist ein persönlicher Browser-Agent nicht dasselbe wie Metas Muse?

Am Netzwerkrand ist er womöglich nicht zu unterscheiden, und genau darum geht es: Was einen ehrlichen Agenten von einem nachlässigen trennt, steckt nicht in dem, was er angibt. Der Unterschied ist die Hoheit über die Session, und die ist nur so gut wie die Kontrollen dahinter.

Meine sind absichtlich langweilig. Das Browserprofil enthält Arbeits- und Kundenkonten und nichts Persönliches: keine Bank, keine private Mail. Die Session selbst ist also eingegrenzt, bevor ein Agent sie anfasst. Ein Agent öffnet seinen eigenen neuen Tab und navigiert nie in einem, den ich schon offen habe, weil ein offener Tab von mir eine laufende Kunden-Session ist und der Schaden durch eine Übernahme lautlos wäre. Massensuchen laufen nie über dieses Profil, sondern über eine separate API, sonst wird das Konto markiert. Wo es einen echten API-Key gibt, nutzt der Agent den Key statt des Browsers, und manche Keys sind per Richtlinie auf Lesezugriff beschränkt, auch wo sie schreiben könnten. Der Agent tippt nie ein Passwort ein. Stößt er auf eine Login-Seite, hält er an und fragt mich.

Ehrlich gesagt sind das meistens Regeln, keine erzwungene Isolation: Ein neuer Tab im selben Profil erreicht trotzdem jedes Konto in diesem Profil, und ein Lesezugriff, den nur eine Richtlinie vorgibt, ist kein Lesezugriff, den die Zugangsdaten technisch erzwingen. Was ich habe, sind Ort und Widerruf. Die Sessions gehören mir: von mir geöffnet, auf meinem Rechner, und ich kann jede davon einsehen und beenden. Ein gehosteter Agent kann denselben Test mit anderen Mitteln bestehen: ein Log dessen, was er in der Session getan hat, das der Nutzer lesen kann, ein Umfang, den der Nutzer festlegt, ein Widerruf, der tatsächlich funktioniert. Mein Desktop ist ein Weg, den Test zu bestehen, nicht der Test selbst.

Das heißt auch: Diese Grenze kann keine Website ziehen. Amazon kann die Hoheit über die Session von seiner Seite der Verbindung aus nicht sehen. Ziehen müssen sie die Nutzer und die Leute, die Agenten bauen. Die Grenze der Website liegt woanders.

Schützt Amazon mit der Sperre von Muse die Nutzer oder sein Werbegeschäft?

Beides. Der Umgang eines Dritten mit Zugangsdaten ist ein echtes Risiko, und das ist der wahre Teil, mit dem Amazon den anderen Teil rechtfertigt. Wenn dein Umsatz von der Aufmerksamkeit auf der Seite lebt, gesponserte Plätze und Werbeauktionen eingeschlossen, dann ist ein Agent, der die Seite liest und die Werbung überspringt, kein Besucher. Er ist ein Konkurrent, der in deiner Kassenschlange steht.

Meine eigene Website ist das Gegenteil einer Mauer, und ich tue nicht so, als wäre das ein Prinzip, gegen das Amazon verstößt. Die robots.txt sagt Ja zu Training, Suche und AI-Input; es gibt Skill-Dateien und einen API-Katalog, damit ein Agent nicht raten muss. Zum Teil habe ich das gebaut, um bei einem Agent-Readiness-Scanner gut abzuschneiden, das gebe ich zu. Vor allem kostet es mich nichts. Die Website verkauft nichts und schaltet keine Werbung, also ist jeder Agent, der sie liest, Reichweite, und ein Mensch, der über einen Assistenten zu mir findet, ist immer noch ein Leser. Das ist die Ökonomie einer Website, deren Seiten nichts zu schützen haben.

Was sollten Website-Betreiber mit dem Traffic von AI-Agenten tun?

Veröffentliche eine Richtlinie und lass Agenten deine öffentlichen Seiten lesen, solange die Seite selbst nicht dein Produkt ist. Sag in maschinenlesbarer Form, was sie dürfen und wo deine API ist. Zieh die Mauern bei den Aktionen hoch: Checkout, Kontoänderungen, alles, was das Geld des Nutzers ausgibt. Private Daten brauchen eigene Zugriffskontrollen, ob nun Geld fließt oder nicht, und genau das ist die ganze Lehre aus diesem Mail-Ordner. Öffentliche Seiten lesen zu lassen kostet wenig; Geldausgeben und Datenpreisgabe nicht. Es ist dieselbe Regel, an die ich meine eigenen Agenten halte: Das Gate, das hält, richtet sich danach, was eine Aktion erreichen kann.

Nach dieser Regel ist Amazons Position genau dort am stärksten, wo Muse Geld ausgibt und das Konto anfasst, und am schwächsten bei der Mauer, die Amazon vor alles andere stellt. Gegen ein Gate am Checkout ließe sich schwer argumentieren. Die Fehlerseite, die Muse-Nutzer bekommen, steht vor dem ganzen Laden.

Und wenn dein Geschäft das Werbeinventar auf der Seite ist, sag das neben den Sicherheitsgründen. Verlang Geld für den Zugang, so wie Pay-per-Crawl-Modelle anfangen, jede Crawler-Anfrage zu bepreisen. Dafür muss sich der Agent mit Signatur zu erkennen geben, und das ist in Ordnung. Genau dafür ist Identifikation da: für Berechtigung und Abrechnung. Eine Sicherheitseigenschaft war sie nie.

Amazon kann einen sorgfältigen Agenten nicht von einem nachlässigen unterscheiden, und ein angegebener Name würde daran nichts ändern. Was die beiden unterscheidet, liegt auf meiner Seite der Verbindung, wo Amazon nicht hinsehen kann, und genau dort muss auch der Nutzer hinsehen.