Visa baut hier nicht die EinkaufskI, sondern die Straße darunter. Trusted Agent Protocol ist Plumbing: kryptografische Agenten-Identität, signierte HTTP-Nachrichten, deklarierte Fähigkeiten und Absichten. Das verhindert keine Halluzinationen, aber macht aus „anonymem Bot“ einen adressierbaren Akteur mit Rolle und Haftung. Für Händler heißt das: weniger False Positives in der Bot-Abwehr und klarere Policies. Für Nutzer: im Idealfall granularer Zugriff statt „hier ist meine Kreditkarte, viel Spaß“.

Wichtig: Vertrauen ist ein Protokollproblem, Urteilsvermögen ein Produktproblem. TAP löst Ersteres. Zweiteres braucht harte Leitplanken. Sonst hat man nur einen sehr schnellen Klickbot.

Mindestanforderungen, bevor so ein Agent einkaufen darf:
– Capabilities by design: Nur lesen, nur Warenkorb, nur Vorautorisieren, nur unter Betrag X, nur Händler-Whitelist.
– Intent-Challenge: Agent signiert Angebot/Preis/Versand, Abschluss erst nach kurzer Nutzerfreigabe oder ab Betragsgrenze.
– Replay- und Missbrauchsschutz: Nonce, Timestamps, rotierende Schlüssel, mTLS optional, sofortige Key-Revocation.
– Budget- und Zeitfenster: pro Tag/Monat, pro Händler, „Gültig bis“-Order, kein Checkout außerhalb definierter Slots.
– Datenminimierung: getrennte Schlüssel pro Händler, keine unnötigen Kundenmerkmale im Agenten-Token.
– Verifikation der Entscheidung: deterministische Checks (SKU, Specs, Gesamtpreis) vor Zahlung, LLM nur für Suche/Parsing.
– Haftungsmodell: delegierte Signatur ohne Verzicht auf Chargeback-Rechte; klare Logs für Streitfälle.

Warum nicht einfach Idealo+If-Else? Weil echte Szenarien mehrstufig sind: Verfügbarkeit, Varianten, Gutscheine, Lieferzeit, Rückgabebedingungen. Das lässt sich automatisieren – mit deterministischen Prüfern im Loop. Die „KI“ ist dann Planer, nicht Richter.

Fazit: Gute Grundlage, wenn der Agent einen Führerschein bekommt: begrenzte Vollmachten, Telemetrie, Notbremse. Ohne das bleibt „Web Bot Auth“ nur der höfliche Händedruck, bevor der Bot denselben Quatsch schneller kauft.

▣