Amazon sperrt Metas KI-Agenten aus. Der Konflikt zeigt: Ohne Agent Identity und Auffindbarkeit funktioniert das agentische Web nicht.
Am 21. September 2026 hat Amazon Metas neuen KI-Agenten Muse von seiner Plattform ausgesperrt, keine zwei Wochen nach dessen Start. Amazons Begründung gegenüber GeekWire: Meta hat Amazon vorab nicht informiert. Muse hat sich beim Browsen nicht als Agent zu erkennen gegeben. Für Zugriffe auf Kundenkonten oder Transaktionen gab es keine Autorisierung. Auf den ersten Blick ist das ein Streit zweier Plattformen. Bei genauerem Hinsehen ist es der erste große öffentliche Konflikt um Agent Identity. Gemeint ist ein überprüfbarer Nachweis, wer einen KI-Agenten betreibt und in wessen Auftrag er handelt.
Es ist wohl kein Zufall, dass ausgerechnet Meta und Amazon als Erste aneinandergeraten. Beide sind Monolithen des menschenzentrierten Webs. Nun konkurrieren sie implizit darum, wem Kundenbeziehung und Schnittstelle gehören, und damit auch die Daten und die Wertschöpfung einer Transaktion. Wenn ein Agent zur Schnittstelle zwischen Mensch und Unternehmen wird: Wem gehört dann die Beziehung?
Aus meiner Perspektive steckt darunter eine noch grundlegendere Frage. Sie verbindet zwei Themen, die wir hier im Blog bereits aufgegriffen haben: warum wir auf MCP setzen und warum KI-Agenten Identitäten brauchen.
Agenten, die sich wie Menschen verhalten, stoßen an Grenzen
Muse hat getan, was viele Agenten heute tun: eine Website so bedienen, wie es ein Mensch tun würde. Seiten laden, Formulare ausfüllen, Buttons klicken. Das funktioniert, bis jemand fragt, wer da eigentlich klickt.
Genau diese Frage finde ich an der Debatte am spannendsten: Müssen Agenten überhaupt wie Menschen agieren? Oder wird es selbst zur Grenze, Agenten rund um menschliche Oberflächen und menschliche Kommunikationsformen zu entwerfen? Daraus folgt eine strategische Frage: Für wen bauen wir die Infrastruktur und die Produkte des AI-nativen Internets eigentlich, für Menschen oder für Maschinen?
Ein Launch aus dem September zeigt, wohin die Reise gehen kann. TypeSafe AI hat mit Jev ein Modell vorgestellt, das Entscheidungen statt Text liefert. Statt Fließtext für Menschen erzeugt Jev typisierte Entscheidungen mit kalibrierter Konfidenz, die Software direkt weiterverarbeiten kann. Vielleicht besteht die nächste Entwicklungsstufe also nicht aus Agenten, die das menschliche Web immer besser bedienen. Sondern aus einer parallelen Schicht von Infrastruktur und Intelligenz, die von Grund auf für die Kommunikation zwischen Maschinen gebaut ist.
Warum wir mit MCP den ersten Schritt gemacht haben
Für uns ist diese Überlegung nicht theoretisch. Als wir im August den IONOS MCP Server für Domain, DNS, SSL, Hosting und Server gestartet haben, stand genau diese Entscheidung dahinter: Ein KI-Assistent soll eine Domain nicht registrieren, indem er sich durch das Kundencenter klickt. Er soll eine Schnittstelle nutzen, die für ihn gebaut ist. Aus vier Klickstrecken wird ein Satz – und aus einer Oberfläche für Menschen ein Zugang für Maschinen.
Dabei haben wir uns bewusst für Schreibzugriffe entschieden und diese an explizite Autorisierung, Protokollierung und eng begrenzte Token-Scopes geknüpft, also genau festgelegte Berechtigungen für jeden Zugang. Rückblickend war das bereits eine Antwort auf die Frage, an der Muse gescheitert ist: Ein Agent, der handelt, muss sich gegenüber dem System ausweisen, auf das er zugreift.
MCP löst damit ein wichtiges Problem: wie ein Agent mit einem Dienst spricht. Zwei andere Fragen beantwortet das Protokoll nicht. Wie findet ein Agent den richtigen Dienst oder einen anderen Agenten? Und woran erkennt das Gegenüber, wer hinter einem Agenten steht?
Discoverability und Agent Identity: die zwei offenen Fragen
Heute finden Agenten Dienste über fest hinterlegte URLs, proprietäre Verzeichnisse oder manuelle Konfiguration. Und ob hinter einem Agenten ein vertrauenswürdiger Betreiber steht, kann das Gegenüber meist gar nicht prüfen. Amazon hat Muse nicht gesperrt, weil der Agent unauffindbar war, sondern weil er sich nicht ausgewiesen hat. Discoverability und Agent Identity gehören deshalb zusammen: Ein Agent muss auffindbar sein, und das Gegenüber muss wissen, mit wem es spricht.
Vier Initiativen, ein gemeinsamer Nenner
Aktuell prägen vier große Initiativen die Diskussion. Sie ähneln sich in einem entscheidenden Punkt: Alle bauen auf DNS, das Domain Name System, als Fundament auf und nutzen die Domain als Anker für Vertrauen. Ihre Schwerpunkte unterscheiden sich jedoch deutlich:
| Initiative | Schwerpunkt | Ansatz |
|---|---|---|
| DNS-AID | Auffindbarkeit | Agenten werden als SVCB-Einträge im DNS veröffentlicht, abgesichert über DNSSEC. Projekt der Linux Foundation, IETF-Entwurf. |
| DNSid / Known | Verantwortlichkeit | Kombiniert DNS, Public-Key-Infrastruktur und ein unveränderliches Ledger. Von Identity Digital ausgegründet, beraten u. a. von Vint Cerf. |
| Groundmark | Betreiber-Nachweis | Agenten signieren Anfragen, unabhängige Stellen bestätigen Fakten über den Betreiber. Prüfbar ohne vorherige Beziehung, zwei IETF-Entwürfe. |
| Agent Name Service (ANS) | Benennung und Zertifikate | Knüpft Agent-Identitäten über X.509-Zertifikate an Domainnamen, IETF-Entwurf. |
Ergänzung oder Wettbewerb? Die Antwort ist noch offen
Auf den ersten Blick konkurrieren diese Ansätze miteinander. Bei genauerem Hinsehen decken sie unterschiedliche Teile derselben Frage ab: Wie finde ich einen Agenten, wer betreibt ihn, und was darf er? Einige Initiativen verstehen sich ausdrücklich als ergänzende Bausteine, nicht als Ersatz für die anderen.
Welcher Ansatz sich am Ende durchsetzt, ob mehrere nebeneinander bestehen oder ob sie zu einem gemeinsamen Stack zusammenwachsen, ist heute noch nicht entschieden. Die Arbeit bei der IETF läuft, und die Unterstützer der einzelnen Initiativen überschneiden sich teilweise. Sicher ist bislang nur eines: Die Antwort wird auf DNS aufbauen.
Warum die Antwort auf Agent Identity im DNS liegt
Dass alle vier Initiativen auf DNS setzen, ist kein Zufall. Diese Entwicklung haben wir im Juni in unserem Artikel zu den KI-Trends für Domains 2026 bereits beschrieben. Die Domain wird zum organisatorischen Anker für Agent Identity, DNSSEC zur Vertrauenskette. Registrare betreiben bereits die Infrastruktur, die Benennung, Auflösung und Verifikation verbindet.
Der Fall Muse zeigt, warum das wirtschaftlich relevant ist. Hätte Muse eine verifizierbare, an Metas Domain gebundene Identität mitgebracht, hätte Amazon mehr Optionen gehabt als Sperren oder Zulassen. Amazon hätte den Zugriff einschränken, Bedingungen setzen oder sogar ein Preismodell für Agenten-Traffic anbieten können. Agent Identity macht aus einer binären Blockade eine Verhandlung. Sie ist damit die Voraussetzung für Geschäftsmodelle zwischen Agenten: Wer zahlt, wer haftet, wer darf was?
Was das für uns bei IONOS bedeutet
Weil die Standardfrage offen ist, legen wir uns bei IONOS bewusst noch nicht auf eine einzelne Initiative fest. Stattdessen bereiten wir die Grundlage vor, auf der alle vier aufbauen. Wir denken das agentische Web dabei in drei Schichten:
- Zugang: Agenten brauchen maschinennative Schnittstellen statt Oberflächen für Menschen. Mit dem IONOS MCP Server haben wir diese Schicht für unsere Kernprodukte bereits gebaut.
- Fundament: DNSSEC und die Unterstützung für SVCB-Einträge betreiben wir heute schon auf unserer DNS-Plattform. Damit erfüllen wir die technischen Voraussetzungen, auf die die Initiativen zurückgreifen, unabhängig davon, welche sich durchsetzt.
- Auffindbarkeit und Identität: Hier beobachten wir die Standardisierung bei der IETF und in den Projekten selbst sehr genau. Wir wollen dann handeln, wenn klar ist, ob ein Standard dominiert oder mehrere sich ergänzen, und nicht vorher auf das falsche Pferd setzen.
Eine europäische Perspektive bringen wir dabei bewusst mit ein. Wenn Agent Identity zur Vertrauensinfrastruktur des Internets wird, ist entscheidend, wo die zugehörigen Daten liegen und welchen Regeln sie unterliegen.
Das Internet bekommt eine zweite Zielgruppe
Der Streit zwischen Amazon und Meta wird nicht der letzte seiner Art bleiben. Er markiert den Moment, in dem sichtbar wird, dass das Web nicht mehr nur für Menschen gebaut wird. Agenten brauchen eigene Zugänge, eigene Wege, einander zu finden, und eine Agent Identity, die jedes Gegenüber prüfen kann. Die Bausteine dafür existieren größtenteils bereits im DNS.
Bleibt die Frage, die uns bei IONOS gerade am meisten beschäftigt: Bauen wir das nächste Internet für Menschen, die Agenten nutzen, oder für Agenten, die im Auftrag von Menschen handeln?