DEV Community

Edison Flores
Edison Flores

Posted on

Visa hat ein Trusted-Agent-Protokoll. Mastercard hat Verifiable Intent. Hier ist die Schicht, die dir keiner von beiden gibt (auf Deutsch)

#ai #security #agents #de

Kurzfassung auf Deutsch. Die vollständige englische Version —inklusive der Revocation-Diskussion, die Alex Shev in den Kommentaren eröffnet hat— ist die kanonische.

Warum auf Deutsch

Es gibt kaum etwas, was die deutsche Ingenieurskultur präziser zusammenfasst als „Vertrauen ist gut, Kontrolle ist besser". Genau darum geht es hier: Visas und Mastercards neue Agent-Protokolle leisten Exzellentes — aber Kontrolle bedeutet, dass ein Fremder den Verifizierer selbst prüfen kann. Diese Kurzfassung erklärt, was die Netzwerke veröffentlicht haben, was sie nicht liefern, und was du heute selbst mit öffentlichen URLs nachprüfen kannst.

Was gerade passiert ist

2026 haben die Zahlungsnetze aufgehört, über „Agent Commerce" abstrakt zu reden — und begonnen, Spezifikationen zu veröffentlichen:

  • Visa hat das Trusted Agent Protocol (TAP) veröffentlicht: offenes Repo mit Spec und vollständiger Referenzimplementierung (Agent-Registry, Merchant-Backend, Merchant-Frontend, ein live Agent). Jede Agent-Anfrage trägt eine kryptografische Signatur mit Zeitstempel, eindeutiger Session-ID, Key-Identifier und Algorithmus — gebunden an die Domain des Händlers und die konkrete Operation, ohne Replay-Möglichkeit.
  • Mastercard hat Verifiable Intent (VI) gestartet: der Händler validiert die signierte Intent-Credential in Echtzeit innerhalb des Autorisierungsflusses, bevor Geld bewegt wird.
  • Drumherum: x402 (Coinbase → Linux Foundation) und AP2 (Google + Visa + Mastercard + PayPal + ~60 Partner).

Wenn die Firmen, die den Großteil des Weltgeldes bewegen, gleichzeitig dieselbe Schicht bauen, ist das kein Trend — das ist Validierung. Agent-Trust-Infrastruktur ist inzwischen lasttragend.

Die Lücke, die niemand schließt

Was ein Dritter mit diesen Protokollen nicht kann:

  1. Den Verifizierer auditieren. Woher weißt du, dass die Instanz, die sagt „dieser Agent ist vertrauenswürdig", nicht korrumpiert, gepatcht ist oder Antworten auswendig lernt? Bei einem Netzprotokoll vertraut man dem Urteil, weil man dem Netz vertraut. Zirkulär.
  2. Das Credential reproduzieren. Kann ein Außenstehender das Artefakt aus öffentlichen Bytes rekonstruieren und dasselbe Ergebnis erhalten — Bit für Bit?
  3. Unveränderliche Beweise finden. Wo ist das append-only, von Dritten gehostete Protokoll, das belegt, was wann veröffentlicht wurde — und das selbst der Herausgeber nicht umschreiben kann?

Der Unterschied in einer Zeile: TAP und VI geben einem Agenten die Erlaubnis, innerhalb eines Netzwerks zu transagieren. Eine ATC gibt jedem Beweise, die außerhalb jedes Netzwerks verifizierbar sind — offline, ohne Mitgliedschaft, ohne API-Key.

Die Analogie: die Netzwerke stellen den Führerschein aus. Wir veröffentlichen die Gerichtsakten — von jedem Fremden überprüfbar, versiegelt in einem öffentlichen Log, den niemand editieren kann. Der Handel braucht beides.

Die drei Lehren, die wir übernommen haben

  1. Von Visa: Freshness muss beidseitig sein und aus den Bytes abgeleitet werden. Unser Referenz-Runner erzwingt ein beidseitiges Gültigkeitsfenster — issued_at <= NOW < expires_at. Eine in der Zukunft datierte Karte (unser Vektor premature-atc, ausgestellt 2030-01-01) scheitert exakt wie eine abgelaufene. Und der Check leitet sich aus den Karten-Bytes ab, nicht aus Sidecar-Metadaten — ein lügender oder gelöschter Sidecar kann das Urteil nicht kippen.
  2. Von Mastercard: Verifizierung gehört in den Fluss — unsere läuft offline. Eine ATC verifiziert sich offline in Millisekunden: ein Ed25519-Check gegen gepinnte Trust-Anchors, null Netzwerkaufrufe, null API-Keys, null Mitgliedschaft. Verifizierung im Fluss, ohne dem Fluss um Erlaubnis zu bitten.
  3. Von beiden: eine Registry — aber append-only und außerhalb unserer Kontrolle. Jedes Release unserer Conformance-Suite ist gegengezeichnet und in Rekor, das öffentliche Sigstore-Transparenz-Log, verankert. Eintrag #3 (logIndex 2764479676) trägt die Digests der kompletten v1.3.3-Suite. Versuchten wir, die Geschichte still umzuschreiben, würde das Log uns widersprechen.

Die Belege (alles von Fremden verifizierbar, live URLs)

Der Bug, der v1.3.3 motiviert hat, wurde von einem Fremden gefunden, der unsere eigenen Tools gegen uns laufen ließ. Das ist keine Peinlichkeit — das ist das Produkt bei der Arbeit.

Ehrliches Fazit

Die Giganten werden die Permission-Schicht des Agent-Commerce gewinnen — dafür sind Netzwerke da. Was wir bauen, ist das Stück, das Netzwerke strukturell nicht verkaufen: Beweise, die kein Vertrauen in den Verkäufer verlangen. Wenn ein Unternehmen fragt „wer auditiert die Auditoren?", kann die Antwort nicht „die Auditoren" sein. Sie muss lauten: jeder kann — und hier sind die Befehle.

Sie haben die Schicht validiert. Wir heben die Belege auf.

— AliceLabs / MarketNow · marketnow.site · UTA auf GitHub

Top comments (0)