Googles UCP hängt vier Header an jede Kaufanfrage. Drei davon existieren für den Streit danach

Am 11. Januar 2026 veröffentlichte Google das Universal Commerce Protocol – einen Open-Source-Standard, der KI-Agenten das Einkaufen ermöglicht, gemeinsam entwickelt mit Shopify und unterstützt von mehr als 20 Partnern, darunter Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa und Zalando.

Die Berichterstattung danach handelte vom Einkaufen. Agenten, die für Sie stöbern, Agenten, die für Sie bezahlen, das Ende des Warenkorbs und so weiter.

Dann liest man die Spezifikation, und das Einkaufen erweist sich als das Uninteressanteste darin. Was UCP mit ungewöhnlicher Sorgfalt standardisiert, ist nicht der Kauf. Es ist der Nachweis, dass der Kauf so stattgefunden hat, wie beide Seiten es behaupten.

Kurzfassung:

• Jede zustandsverändernde UCP-Anfrage trägt vier Header, und drei davon – request-signature, idempotency-key, request-id – tun für die Transaktion selbst nichts. Sie existieren, damit später jemand beweisen kann, was verlangt wurde, dass es genau einmal verlangt wurde und wo man es wiederfindet.
• Nichtabstreitbarkeit ist ein benanntes Feature. In der optionalen AP2-Mandate-Erweiterung (dev.ucp.shopping.ap2_mandate) signiert das Unternehmen die Kaufbedingungen kryptografisch, während die Plattform kryptografische Mandate liefert, die die Zustimmung des Nutzers belegen. Der erklärte Zweck laut Spezifikation: das Risiko von Manipulation und Streitfällen "erheblich zu senken".
• Die Zahl der Unterstützer ist keine Zahl der Integrationen. "Über 20 globale Partner" ist Googles Formulierung, und sie beschreibt Zustimmung. Zum Redaktionsschluss fanden wir keine Primärquelle, die eine Zahl produktiv laufender UCP-Händler nennt.

Der Header-Satz stammt aus Googles eigenem Walkthrough vom Erscheinungstag. Quellen am Ende.

Was UCP ist, in den wenigsten Worten, die noch stimmen

Vor dem Argument die nachprüfbaren Fakten. Sie stammen aus der auf ucp.dev veröffentlichten Spezifikation und aus Googles Entwicklerblog, beide abgerufen am 5. September 2026.

Zwei Zeilen dieser Tabelle lohnen eine Pause, weil die meisten Beiträge beide überspringen.

Erstens die Transportzeile. UCP ist keine MCP-Sache und keine REST-Sache. Dieselben deklarierten Daten werden über REST, MCP, A2A und ein eingebettetes Binding angeboten, und das Unternehmen wählt aus. Das ist eine bewusste Weigerung, darauf zu wetten, welche Agenten-Infrastruktur sich durchsetzt.

Zweitens die datumsbasierte Versionierung. 2026-04-08 ist keine semantische Version, sondern ein Tag. Die Spezifikation begründet das mit chronologischer Ordnung und eindeutigem Vergleich – praktisch bedeutet es aber, dass jede ausgehandelte Sitzung das Datum der Regeln mitprotokolliert, unter denen sie geführt wurde. Eine Archivierungsentscheidung im Gewand einer Versionierungsentscheidung, und sie gibt den Ton für den Rest des Dokuments vor.

Der Flaschenhals, gegen den es gebaut wurde

Googles Rahmung ist ein N×N-Problem. Jedes Unternehmen, das in einer konversationellen Oberfläche auftauchen will, muss für jede einzelne eine maßgeschneiderte Anbindung bauen; jede Oberfläche muss jedes Unternehmen separat onboarden; am Ende liefert niemand.

Shopifys Engineering-Beitrag, am selben Tag von Distinguished Engineer Ilya Grigorik veröffentlicht, nähert sich demselben Problem von unten. Nach über 20 Jahren, Milliarden von Transaktionen und Millionen von Händlern lautet die Lehre: Handel verweigert die Normalisierung. "Zahlungsoptionen und -regeln unterscheiden sich nach Eigenschaften von Warenkorb, Käufer und Markt; Rabatte haben Staffelungs- und Kombinationsregeln, die es mit dem Steuerrecht aufnehmen; Fulfillment-Optionen explodieren in ausufernden Permutationen." Und dann der Satz, den man behalten sollte: "Diese Komplexität ist kein Fehler, sie ist eine emergente Eigenschaft vielfältiger Händler."

Diese eine Zeile erklärt die gesamte Architektur. Wenn man akzeptiert, dass Händler unauflösbar verschieden sind, kann man das Verhalten nicht standardisieren. Standardisieren lässt sich nur, wie ein Händler sein Verhalten deklariert – und wie ein Agent herausfindet, wem er gerade zugestimmt hat.

Die Struktur, die ein Unternehmen unter /.well-known/ucp veröffentlicht. Quelle: UCP-Spezifikation 2026-04-08, Overview.

Die Discovery passiert, bevor das Gespräch beginnt

Hier der Ablauf, wie ihn Spezifikation und Googles Walkthrough beschreiben. Es lohnt sich, ihn wörtlich nachzuvollziehen, denn die Reihenfolge ist das Argument.

1. Das Unternehmen veröffentlicht ein Profil unter /.well-known/ucp. Es deklariert eine Protokollversion, einen oder mehrere Services (dev.ucp.shopping), die darin enthaltenen Capabilities, Transporte und Endpunkte, die verfügbaren Payment Handler und – das wird später wichtig – seine öffentlichen signing_keys.
2. Der Agent nennt sein eigenes Profil bei jeder Anfrage über einen UCP-Agent-Header in RFC-8941-Dictionary-Syntax: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". Beim MCP-Transport reist dieselbe Angabe in einem meta-Objekt mit.
3. Das Unternehmen berechnet die Schnittmenge. Von den eigenen Capabilities bleiben die, die auch die Plattform deklariert; für jede übrig gebliebene wird die höchste Version gewählt, die in beiden Arrays vorkommt. Gibt es keine gemeinsame Version, fällt die Capability komplett heraus.
4. Verwaiste Erweiterungen werden entfernt. Eine Erweiterung mit extends: "dev.ucp.shopping.checkout" verschwindet, wenn Checkout nicht überlebt hat. Der Schritt wiederholt sich, bis nichts mehr wegfällt, womit auch transitive Ketten abgedeckt sind.
5. Das Unternehmen wählt aus. UCP nutzt eine Server-selects-Architektur: Der Händler, nicht der Agent, entscheidet, was für die Sitzung aktiv ist, und spiegelt die aktive Capability-Registry in der Antwort zurück.

Die Benennung ist nicht Konvention, sondern Governance. Jede Capability heißt {umgekehrte-domain}.{service}.{capability} – dev.ucp.shopping.checkout für die Standardvariante, com.example.payments.installments für die eigene eines Händlers. Ein Händler kann eine Capability erfinden, die sonst niemand hat, ohne zu fragen und ohne mit jemandem zu kollidieren, weil die umgekehrte Domain die Autorität ist.

Auch das Scheitern hat eine eigene Taxonomie, und die Aufteilung ist aufschlussreich. Die Spezifikation trennt Discovery-Fehler (Transportfehler: invalid_profile_url liefert 400, profile_unreachable liefert 424, profile_malformed liefert 422) von Verhandlungsfehlern, die geschäftliche Ergebnisse sind und als ganz normales 200 mit capabilities_incompatible im Body zurückkommen. "Ich konnte dich nicht erreichen" und "wir haben nichts gemeinsam" sind verschiedene Ereignisse, und UCP weigert sich, sie zu einem einzigen 400 zu verschmelzen.

Vier Header reisen auf jeder zustandsverändernden Anfrage mit

Sehen wir uns einen echten Aufruf an. Dies ist Googles eigenes Beispiel vom Erscheinungstag: das Anlegen einer Checkout-Session bei einem Beispiel-Blumenladen.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Vier Header. Fragt man nach dem Zweck jedes einzelnen, fällt ein Muster heraus.

Drei der vier sind nicht für die Transaktion da. Sie sind für die Auseinandersetzung über die Transaktion da.

Das ist kein Zufallsprodukt guter API-Hygiene. Idempotency Keys und Request-IDs sind im Zahlungsverkehr gängige Praxis, ja – aber die Spezifikation geht deutlich weiter, und je weiter sie geht, desto klarer wird die Absicht.

Nichtabstreitbarkeit ist ein Designziel, kein Compliance-Nachgedanke

UCP nennt vier Authentifizierungsmechanismen, die ein Unternehmen akzeptieren kann: API-Keys, OAuth 2.0, mTLS und HTTP Message Signatures nach RFC 9421. Drei davon sind gewöhnlich. Der vierte tut etwas Bestimmtes.

Bei Message Signatures veröffentlichen beide Seiten ihre öffentlichen Schlüssel im signing_keys-Array genau desselben Profildokuments, das auch ihre Capabilities deklariert. Ein Prüfer holt die keyid aus dem Signature-Input-Header, gleicht sie mit einer kid im veröffentlichten Schlüsselsatz des Signierers ab und prüft die Signatur. Kein geteiltes Geheimnis, keine Registrierung, kein Konto. Die Spezifikation nennt das Ergebnis permissionless Onboarding: "Jede Plattform mit einem auffindbaren Profil kann ohne vorherige Registrierung mit jedem Unternehmen interagieren."

Die offensichtliche Lücke schließt das Identity Binding. Unabhängig vom Mechanismus müssen Prüfer bestätigen, dass der authentifizierte Prinzipal tatsächlich befugt ist, für das im UCP-Agent genannte Profil zu handeln, und die Anfrage ablehnen, wenn beides auseinanderfällt. Man kann sich nicht als sich selbst authentifizieren und dann behaupten, der Agent eines anderen zu sein.

Und Webhooks vom Unternehmen zur Plattform müssen signiert sein. Nicht sollten – müssen. Lebenszyklus-Updates zu Versand, Zustellung und Retouren sind die einzige Stelle im Protokoll, an der die Anforderung absolut ist, weil es die Nachrichten sind, die eintreffen, nachdem das Geld geflossen ist, und die niemand in Echtzeit beobachtet.

Quelle: UCP-Spezifikation 2026-04-08, Abschnitte Identity & Authentication und Transaction Integrity.

Und dann die Spitze der Leiter. Für autonome Agenten und Transaktionen mit hohem Wert definiert UCP eine optionale Erweiterung, dev.ucp.shopping.ap2_mandate. Wenn beide Seiten sie aushandeln, gilt:

• Das Unternehmen liefert eine kryptografische Signatur auf die Kaufbedingungen, und
• die Plattform liefert kryptografische Mandate, die die Zustimmung des Nutzers belegen.

Der Agent signiert die Mandatsobjekte mit dem privaten Schlüssel des Nutzers auf einer nicht-agentischen Oberfläche – der Mensch autorisiert also auf einem Bildschirm, den er kontrolliert, und nicht innerhalb der Agentenschleife, die gleich sein Geld ausgibt. Die Zweckbestimmung der Spezifikation lohnt das wörtliche Zitat, denn sie ist kein Sicherheitsfloskel-Satz: Das Verfahren "liefert starke, durchgängige kryptografische Zusicherungen über Transaktionsdetails und die Zustimmung der Beteiligten und senkt das Risiko von Manipulation und Streitfällen erheblich".

Der Punkt: Ein Protokoll, das Agenten nur einkaufen lassen soll, bräuchte nichts davon. Signierte Bedingungen auf Händlerseite und signierte Mandate auf Nutzerseite sind keine Features des Kaufens. Sie sind Features des Streitens über den Kauf, sechs Wochen später, vor jemandem, der entscheiden muss, wer recht hatte.

Wo die Erzählung den Belegen davonläuft

Drei Dinge werden über UCP wiederholt, die die Primärquellen so nicht hergeben.

"20+ Partner" ist eine Zahl von Unterstützern. Googles Formulierung lautet, UCP sei "von mehr als 20 Partnern gemeinsam entwickelt und unterstützt" worden. Unterstützung ist eine öffentliche Absichtserklärung. Sie ist keine ausgelieferte Integration und schon gar kein produktiv laufender Händler. Wir haben nach einer Primärquelle mit der Zahl der über UCP transaktierenden Händler gesucht und keine gefunden.

"Offener Standard" und "Googles Standard" stimmen beide, und die Spannung ist real. Die Spezifikation ist Open Source, das GitHub-Repository nimmt Pull Requests an, und die Namenskonvention lässt bewusst jeden seinen eigenen Namensraum beanspruchen. Zugleich hat Google die erste Referenzimplementierung gebaut, und um an dieser teilzunehmen, braucht ein Unternehmen ein aktives Google-Merchant-Center-Konto mit checkout-fähigen Produkten. Neutrales Protokoll, kontrollierter erster Schauplatz.

UCP entfernt den Händler nicht. Das wird oft genug verdreht, um es klar zu sagen: Unter UCP behält das Unternehmen seine eigene Geschäftslogik und bleibt Merchant of Record. Shopifys Embedded Checkout Protocol macht dieselbe Zusage aus der anderen Richtung – wird ein Mensch im Ablauf gebraucht, lädt der Agent eine continue_url, und der echte Checkout des Händlers rendert über einen JSON-RPC-2.0-Kanal innerhalb der Agentenoberfläche, während der Händler die Transaktion abschließt. Der Agent ist eine Oberfläche, kein Ersatz.

Vier Dinge, die wir nicht verifizieren konnten – so gekennzeichnet

Die zum Abrufzeitpunkt auf ucp.dev veröffentlichte Spezifikation trägt die Version 2026-04-08, und ihre Liste der Standard-Capabilities – Cart, Checkout, Identity Linking, Order – unterscheidet sich vom Walkthrough vom 11. Januar, dessen Beispiele auf Version 2026-01-11 laufen und Checkout, Discount und Fulfillment zeigen. Zwischen diesen Daten kam etwas hinzu. Wir fanden kein primäres Änderungsprotokoll, das den Zeitpunkt benennt, und keine datierte Release Note für die Zwischenversionen, und berichten deshalb die Differenz statt eines Release-Ereignisses.

Wir fanden weder bei Google noch bei Shopify noch bei einem der unterstützenden Partner eine veröffentlichte Zahl produktiv laufender UCP-Händler. Das Fehlen einer Zahl ist kein Beleg für eine kleine Zahl, aber es ist der Grund, warum wir keine drucken.

Google gibt an, die erste Referenzimplementierung gebaut zu haben, die Käufe im AI Mode der Suche und in der Gemini-App antreibt. Verfügbarkeit, Regionen und Umfang dieses Rollouts haben wir nicht unabhängig überprüft.

Ob UCP der Standard für agentischen Handel wird, ist zum Redaktionsschluss nicht wissbar, und jeder Beitrag, der etwas anderes behauptet, rät. Die ehrliche Lesart ist enger: Eine Spezifikation existiert, sie ist öffentlich, sie ist beim Thema Nachweis ungewöhnlich sorgfältig, und mehrere sehr große Unternehmen haben die Ankündigung mitgezeichnet.

Die unsignierte Hälfte

Treten wir vom Handel zurück, denn der interessante Teil verallgemeinert sich.

UCP beschreibt eine Welt, in der eine Maschine in Ihrem Namen handelt und jeder Schritt dieses Handelns etwas hinterlässt: wer gefragt hat, signiert; welche Bedingungen, signiert; wie oft, per Schlüssel; in welcher Reihenfolge, korreliert. Sechs Wochen später, wenn die Belastung bestritten wird, gibt es ein Artefakt. Niemand muss sich erinnern.

Und nun überlegen Sie, woher die Befugnis für diese Handlungen eigentlich stammt. Ein Agent kauft 400 Einheiten, weil eine Beschaffungsentscheidung gefallen ist. Ein Vertrag verlängert sich, weil jemand einer Klausel zugestimmt hat. Ein Scope ändert sich, weil zwei Leute am Donnerstag darüber gesprochen haben und einer davon Ja gesagt hat.

Diese Gespräche sind die unsignierte Hälfte desselben Workflows. Die Maschinenhälfte wird mit kryptografischen Quittungen gebaut und mit einer Spezifikation, die Streitfälle als erstklassiges Szenario behandelt. Die menschliche Hälfte besteht in den meisten Organisationen aus der Erinnerung des einen, der abweichenden Erinnerung des anderen und einer Zusammenfassung, die aus beidem geschrieben wurde.

Die Asymmetrie wird schlimmer werden, bevor sie besser wird, denn die Maschinenhälfte verbessert sich im Takt einer Spezifikation und die menschliche Hälfte überhaupt nicht. Und der Fehlermodus ist konkret: Es geht nicht darum, dass Menschen lügen. Es geht darum, dass ein abgeleitetes Artefakt – eine Zusammenfassung, ein Protokoll, eine Aufgabenliste – zum Dokument selbst wird, sobald das verschwunden ist, woraus es abgeleitet wurde. Zusammenfassungen sind konstruktionsbedingt verlustbehaftet. Genau das macht sie nützlich. Und genau das macht sie zu einer schlechten Primärquelle – nach dem Verwerfen des Originals lässt sich eine verlustbehaftete Zusammenfassung von einer korrekten nicht mehr unterscheiden.

Die Autoren von UCP haben das auf Protokollebene verstanden und aufgeschrieben: Bewahre das signierte Original, leite daraus ab, was du willst, und sorge dafür, dass die Ableitung jederzeit gegen etwas geprüft werden kann, das sich nicht bewegt hat. Das ist eine Disziplin, keine Technologie – und sie gilt für eine Stunde sprechender Menschen genauso wie für ein POST /checkout-sessions.

Fazit: Agentischer Handel ist ein Belegstandard im Einkaufskostüm

Das Universal Commerce Protocol wird üblicherweise als Weg beschrieben, wie KI-Agenten Dinge kaufen. Von vorn bis hinten gelesen, ist es besser als Versuch beschrieben, eine Frage zu beantworten, der jede Form von Agentik gleich ständig begegnen wird: Wenn eine Maschine für mich gehandelt hat – was genau lässt sich darüber beweisen, wem ich zugestimmt habe?

UCPs Antwort ist eine gute: Deklariere deine Fähigkeiten öffentlich, signiere die Bedingungen, signiere die Zustimmung, verschlüssele den Retry mit einem Key, korreliere den Aufruf, und signiere den Webhook, der hinterher meldet, was passiert ist. Ob das Protokoll gewinnt, ist offen. Die Frage, um die es gebaut ist, verschwindet nicht, egal wer gewinnt.

Bleibt eine Frage, mit der man sitzen sollte. Ihre Agenten werden bald bessere Aufzeichnungen darüber haben, wem sie zugestimmt haben, als Sie darüber haben, wem Sie zugestimmt haben. Wohin führt das?

---

Wo Telli.sh hineinpasst: Wir bauen die unsignierte Hälfte. Telli.sh nimmt das Gespräch auf, trennt die Sprecher, übersetzt live über 15 Sprachen hinweg und bewahrt die Originalaufnahme und das vollständige Transkript neben jeder erzeugten Zusammenfassung auf – damit das abgeleitete Artefakt nie das einzige Artefakt wird. Telli.sh implementiert UCP nicht und behauptet das auch nicht; wir bearbeiten das andere Ende desselben Problems: Die Entscheidungen, die agentisches Handeln autorisieren, fallen meist mündlich und werden nirgends aufbewahrt.

Ihr nächstes Entscheidungsmeeting aufzeichnen

Quellen

• Universal Commerce Protocol Specification, Overview, Version 2026-04-08 — Modell aus Services, Capabilities und Extensions, Namenskonvention, datumsbasierte Versionierung, Schnittmengen-Algorithmus, Fehlercodes für Verhandlung und Signatur, Standard-Capabilities (Cart, Checkout, Identity Linking, Order), Transporte, UCP-Agent-Header und RFC-8941-Syntax, Authentifizierungsmechanismen und permissionless Onboarding, Key Discovery über signing_keys, Identity Binding, verpflichtende Webhook-Signatur sowie der Abschnitt Transaction Integrity and Non-Repudiation; abgerufen am 5. September 2026
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)", 11. Januar 2026 — Partnerliste und die Zahl von über 20 Unterstützern, AP2-/A2A-/MCP-Kompatibilität, die N×N-Rahmung, das /.well-known/ucp-Manifest, der fünfstufige Walkthrough und der Header-Satz von POST /checkout-sessions, Merchant of Record und die eingebettete Option, Googles Referenzimplementierung in AI Mode und Gemini sowie die Merchant-Center-Voraussetzung; abgerufen am 5. September 2026
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol", 11. Januar 2026 — die Rahmung mit 20+ Jahren, Milliarden Transaktionen und Millionen Händlern, das Argument "kein Fehler, sondern eine emergente Eigenschaft", die vier Designprinzipien und die Übergabe per Embedded Checkout Protocol über JSON-RPC 2.0 via continue_url; abgerufen am 5. September 2026
• Agent Payments Protocol (AP2) — das Zahlungsprotokoll, zu dem UCP Kompatibilität erklärt
• Universal Commerce Protocol auf GitHub — das in beiden Ankündigungen genannte Open-Source-Repository
• Unsere Lesart von GPT-6 Astra und dem, was die Aufnahmeebene weiterhin entscheidet — dasselbe Argument von der Modellseite: Die Qualität des Schließens ist durch das gedeckelt, was den Datensatz erzeugt hat, über den geschlossen wird