Agentengesteuerter Handel braucht eine Identitätsebene: Visa TAP, Google AP2 und Mastercard Agent Pay

Wichtige Erkenntnisse

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2) und Mastercard Agent Pay machen alle agentengesteuerte Käufe sicherer, lösen aber unterschiedliche Teile des Vertrauensproblems.
• TAP hilft Händlern, genehmigte Agenten zu erkennen und die unterzeichnete Kaufabsicht zu überprüfen. AP2 erstellt Nachweise darüber, was ein Nutzer autorisiert hat. Agent Pay kombiniert registrierte Agenten, tokenisierte Zahlungsdaten, Zustimmung und Netzwerksichtbarkeit.
• Keiner dieser Mechanismen macht es überflüssig, die Identität der Person oder des Unternehmens nachzuweisen, Risiken zu prüfen, jurisdiktionsspezifische Kontrollen durchzusetzen und einen Audit-Trail zu führen.
• Didit ist eine neutrale Infrastruktur für Identität und Betrug, kein Kartennetzwerk oder Zahlungsunternehmen. Der gehostete Model Context Protocol (MCP)-Server stellt 115 Tools in 11 Kategorien bereit, während die Representational State Transfer (REST) Application Programming Interface (API) eingebettete Produktionsabläufe unterstützt.
• Ein vollständiges KYC-Paket (Know Your Customer) kostet 0,33 $, jedes Konto beinhaltet 500 kostenlose Verifizierungen pro Monat, und der MCP-Server selbst ist kostenlos.

Agentengesteuerter Handel beginnt, wenn ein künstlicher Intelligenz (KI)-Agent mehr als nur ein Produkt empfiehlt. Er vergleicht Angebote, stellt einen Warenkorb zusammen, wählt eine Zahlungsmethode und kann einen Kauf innerhalb der von einer Person oder einem Unternehmen festgelegten Grenzen abschließen. Diese Verschiebung wirft mehrere Vertrauensfragen gleichzeitig auf: Welcher Agent hat die Anfrage gestellt? Wer hat sie autorisiert? Wer ist die Person oder juristische Entität dahinter? Ist die Transaktion zulässig? Und welche Beweise werden existieren, wenn der Kauf angefochten wird?

Die aufkommenden Zahlungsstandards beantworten wichtige Teile dieser Abfolge. Sie beantworten nicht alle denselben Teil und sollten nicht als austauschbar behandelt werden. Für Entwickler ist die nützliche Frage nicht, welche Marke „gewinnen“ wird. Es ist vielmehr, welche Kontrollen unter jeder glaubwürdigen Architektur weiterhin notwendig sind.

Drei Standards, drei Vertrauensgrenzen

Visa TAP: Kann der Händler diesen Agenten erkennen und ihm vertrauen?

Das Visa Trusted Agent Protocol ist händlerorientiert. Seine Hauptaufgabe besteht darin, einem Händler zu helfen, einen genehmigten Handelsagenten von einem gewöhnlichen Crawler, einem missbräuchlichen Bot oder einer unbekannten Automatisierung zu unterscheiden. Ein Agent signiert eine Anfrage mit zeitlich begrenzten, zweckgebundenen Anmeldeinformationen. Der Händler oder sein Schutzanbieter überprüft die Signatur und kann entscheiden, ob er das Browsen, den Checkout oder eine engere Aktion zulässt.

TAP beschreibt drei miteinander verbundene Signale: eine Agenten-Erkennungssignatur, eine verknüpfte und signierte Verbraucher- oder Geräteidentität und einen verknüpften und signierten Zahlungscontainer. Dies ist eine nützliche Trennung. Die Agenten-Erkennung stellt fest, welcher genehmigte Agent anwesend ist; die signierte Absicht stellt fest, welche Art von Interaktion angefordert wird; das Verbrauchersignal kann einem Händler helfen, einen bestehenden Kunden zu erkennen.

Dieses Verbrauchersignal ist nicht automatisch gleichbedeutend mit einer neuen Identitätsprüfung. Das Visa-Modell umfasst eine Identitätsanbieterrolle vorgelagert, aber ein Händler benötigt dennoch eine Richtlinie für einen neuen oder risikoreichen Kunden: welche Nachweise geprüft wurden, wie stark die Zusicherung ist, ob KYC erforderlich ist und wann eine erneute Überprüfung notwendig ist. TAP kann vertrauenswürdige Identitätsinformationen übermitteln, ohne jede jurisdiktionelle Onboarding-Entscheidung vorzuschreiben.

Google AP2: Was hat der Nutzer dem Agenten erlaubt zu kaufen?

Das Google Agent Payments Protocol konzentriert sich auf Autorisierung und Nachweis. Es verwendet signierte Mandate, um die Nutzerabsicht, den Inhalt des Warenkorbs und die Zahlung zu verbinden. Ein offenes Mandat kann einem Agenten eine begrenzte Diskretion einräumen, z. B. Händlerbeschränkungen oder Ausgabenlimits. Ein geschlossenes Mandat bindet die Genehmigung an einen bestimmten Warenkorb und Betrag. Quittungen vervollständigen die Beweiskette.

AP2 unterscheidet zwischen Abläufen mit und ohne menschliche Anwesenheit. Wenn die Person anwesend ist, kann sie einen geschlossenen Checkout und ein Zahlungsauftrag direkt genehmigen. Wenn sie abwesend ist, agiert der Agent innerhalb zuvor genehmigter Beschränkungen und signiert die endgültigen geschlossenen Mandate. Ein Händler oder Anmeldeinformationsanbieter kann die Person dennoch wieder in den Prozess einbeziehen, wenn eine Beschränkung nicht gelöst werden kann.

Dieses Design beantwortet „Hat diese Person diese Aktion unter diesen Bedingungen autorisiert?“ direkter als „Wie wurde diese Person ursprünglich verifiziert?“. Das AP2-Autorisierungsframework geht davon aus, dass die relevanten Registrierungs- und Benutzeranmeldeinformationen existieren. Ein Entwickler benötigt daher immer noch einen Identitätsprüfungs- und Anmeldeinformations-Lebenszyklusprozess, bevor diese Mandate eine aussagekräftige Zusicherung tragen können.

Mastercard Agent Pay: Kann das Netzwerk eine agentengesteuerte Zahlung erkennen und steuern?

Mastercard Agent Pay basiert auf der Zahlungstokenisierung. Das Akzeptanzrahmenwerk von Mastercard registriert und verifiziert Agenten, weist eine eindeutige Agentenidentität zu und verwendet Agentic Tokens, sodass Transaktionen nachvollziehbar sind und Zahlungsdaten geschützt bleiben. Die händlerseitige Erkennung kann mit bestehender Checkout-Infrastruktur zusammenarbeiten, während tiefere Integrationen einen reicheren Datenaustausch unterstützen.

Das Modell betont auch die Zustimmung des Verbrauchers, die Authentifizierung und die Möglichkeit für Emittenten, Acquirer und Händler, zu erkennen, dass ein Agent beteiligt war. Dies macht die Agentenaktivität innerhalb eines vertrauten Kartennetzwerk-Risikomodells sichtbar, anstatt die Automatisierung von einer gewöhnlichen Card-not-present-Anfrage nicht unterscheidbar zu machen.

Agent Pay ist am stärksten bei der Sicherheit von Zahlungsdaten, der Agentensichtbarkeit und den Netzwerkkontrollen. Es entbindet einen Händler nicht von der Verpflichtung zu entscheiden, wann Identitätsprüfung, Know Your Business (KYB), Anti-Geldwäsche (AML)-Screening, Altersprüfungen oder eine erweiterte Überprüfung anwendbar sind. Diese Entscheidungen hängen vom Produkt, Kunden, der Transaktion und der Gerichtsbarkeit ab – nicht nur vom Zahlungssystem.

Wo sich die Standards überschneiden – und wo Identität immer noch passt

Alle drei Ansätze versuchen, den delegierten Handel nachvollziehbar zu machen. Ein Händler sollte erkennen können, dass Automatisierung beteiligt ist, überprüfen können, dass der Agent vertrauenswürdig ist, die Aktion mit der Benutzerabsicht verknüpfen, den Kauf einschränken und Beweise aufbewahren können. Ihre Schwerpunkte unterscheiden sich:

• TAP: Agentenerkennung und signierte Absicht an der Händlergrenze, mit optionalen verknüpften Verbraucher- und Zahlungssignalen.
• AP2: Kryptografische Autorisierungsartefakte, die die Benutzerabsicht an Checkout- und Zahlungsergebnisse binden.
• Agent Pay: Registrierte Agenten, tokenisierte Zahlungsdaten, Zustimmung, Authentifizierung und Sichtbarkeit über das Kartennetzwerk hinweg.

Die Identitätsprüfung erfolgt vor und neben diesen Kontrollen. Eine signierte Autorisierung ist nur dann wertvoll, wenn die Anmeldeinformationen der richtigen Person gehören. Ein genehmigter Agent kann immer noch von einem synthetischen, gestohlenen, sanktionierten, minderjährigen oder anderweitig unzulässigen Konto angewiesen werden. Ein Token kann Zahlungsdaten schützen, ohne festzustellen, dass ein Marktplatzverkäufer oder Geschäftsbegünstigter die erforderliche Due Diligence bestanden hat.

Agentenidentität beantwortet „Welche Software hat gehandelt?“ Autorisierung beantwortet „Was durfte sie tun?“ Identitätsprüfung beantwortet „Wer steckt dahinter?“ Betrugs- und Compliance-Kontrollen beantworten „Soll diese Aktion durchgeführt werden?“

Was Entwickler unabhängig davon, welcher Ansatz gewinnt, aufbauen müssen

• Registrierung und Prüfung. Überprüfen Sie die Person oder das Unternehmen, bevor Sie eine wiederverwendbare Berechtigung oder delegierte Ausgabenbefugnis erteilen. Wenden Sie KYC-, KYB-, Liveness-, Dokumenten-, Datenbank- oder biometrische Prüfungen entsprechend dem Risiko an.
• Anmeldeinformationsbindung. Binden Sie das verifizierte Subjekt an ein Konto, Gerät, Passkey, Wallet oder andere Anmeldeinformationen, die am agentengesteuerten Ablauf teilnehmen können.
• Bereichsspezifische Autorisierung. Erfassen Sie Limits wie Händler, Kategorie, Betrag, Häufigkeit, Ablaufdatum und ob ein Mensch zur Genehmigung zurückkehren muss.
• Laufzeit-Risikoentscheidungen. Überprüfen Sie die Person, das Unternehmen, die Wallet und die Transaktion im Moment der Aktion. Know Your Transaction (KYT)-Kontrollen und AML-Prüfungen bleiben relevant, auch wenn die Absicht signiert ist.
• Widerruf und Wiederherstellung. Beenden Sie die delegierte Befugnis, wenn Anmeldeinformationen kompromittiert werden, der Benutzer seine Zustimmung widerruft oder sich das Risiko ändert.
• Revisionsfähigkeit. Bewahren Sie das Verifizierungsergebnis, das Autorisierungsartefakt, die Agentenidentität, die Transaktionsentscheidung, Zeitstempel und spätere Überprüfungsaktionen als separate Beweismittel auf.

Dieses geschichtete Design ist bewusst standardneutral. Ein Team kann TAP am Händlerrand, AP2-Mandate in einem Agenten-Workflow, Agent Pay für die Kartenabrechnung oder eine Kombination davon übernehmen. Die Identitäts- und Betrugsentscheidung bleibt portabel, da sie nicht in ein einziges Zahlungsnetzwerk eingebettet ist.

Wie Didit die Identitätshälfte heute abdeckt

Didit bietet Infrastruktur für Identität und Betrug, die von über 2.000 Unternehmen in Produktion genutzt wird. Dieselben Funktionen sind über einen gehosteten MCP-Server für agentengesteuerte Operationen und eine REST-API für anwendungsgesteuerte Abläufe verfügbar. Für einen breiteren Architekturüberblick siehe wie ein MCP-Server die Identitätsprüfung handhabt und wie MCP Identitäts- und Betrugsprüfungen für KI-Agenten verbindet.

Der gehostete MCP-Endpunkt ist https://mcp.didit.me/mcp. Er verwendet das Streamable Hypertext Transfer Protocol (HTTP) mit Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE) und Dynamic Client Registration. Ein Benutzer meldet sich über die Didit Business Console an und gewährt bereichsspezifischen Zugriff; der gehostete MCP-Endpunkt verwendet keine API-Schlüssel-Authentifizierung.

Nach der Autorisierung kann ein Agent 115 Tools in 11 Kategorien aufrufen. Eine praktische Verifizierungssequenz kann verwenden:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Diese Tools können eine Verifizierungssitzung erstellen, die ausgewählten Prüfungen durchführen und eine strukturierte Entscheidung abrufen. Andere reale Tools umfassen didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select und didit_transaction_screen_wallet. Schreibvorgänge mit hoher Konsequenz unterliegen weiterhin den Berechtigungen und dem Bestätigungsverhalten des verbundenen Benutzers.

Die REST-API deckt den Anwendungspfad ab: Erstellen Sie Sitzungen von Ihrem Backend aus, leiten Sie Benutzer durch gehostete oder eingebettete Verifizierungen, nutzen Sie Webhooks und speichern Sie Entscheidungen in Ihrem eigenen System. REST-Server-zu-Server-Anfragen verwenden einen x-api-key-Header; dies ist getrennt von der OAuth-authentifizierten gehosteten MCP-Verbindung. Lesen Sie die MCP-Übersicht, den Authentifizierungsleitfaden und die Tool-Referenz für Implementierungsdetails.

Die Preisgestaltung ist unabhängig vom agentengesteuerten Zahlungsstandard. Der MCP-Server ist kostenlos. Ein vollständiges KYC-Paket – ID-Verifizierung, passive Liveness, Face Match und IP-Analyse – kostet 0,33 $, und jedes Konto beinhaltet 500 kostenlose Verifizierungen pro Monat.

Ein standardneutraler Implementierungspfad

Beginnen Sie damit, die für jede Aktion erforderliche Sicherheit zu definieren, nicht indem Sie ein Netzwerklogo auswählen. Das Surfen mit geringem Risiko erfordert möglicherweise nur die Agentenerkennung. Die Kontoerstellung erfordert möglicherweise eine verifizierte Identität. Ein regulierter Kauf erfordert möglicherweise KYC oder KYB plus AML-Screening. Eine Krypto-Überweisung erfordert möglicherweise zusätzlich ein Wallet-Screening. Höhere Beträge oder ein geändertes Risiko können den Menschen in den Prozess zurückführen.

Verbinden Sie dann das Zahlungsartefakt mit der Identitätsentscheidung mithilfe stabiler interner Kennungen. Halten Sie die Agentensignatur, die Benutzerautorisierung, den Verifizierungsnachweis und das Zahlungsergebnis getrennt, damit jedes unabhängig widerrufen, überprüft und aktualisiert werden kann, wenn sich die Standards weiterentwickeln.

Erkunden Sie die Didit MCP-Entwicklerseite oder prüfen Sie das öffentliche, permissiv lizenzierte GitHub-Repository. Claude-Benutzer können den Didit-Konnektor hinzufügen und sich über OAuth anmelden.

Die dauerhafte Architektur ist geschichtet: Zahlungsstandards beweisen die Agentenbeteiligung und Autorisierung; Identitäts- und Betrugsinfrastruktur beweist, wer beteiligt ist und ob die Aktion akzeptabel ist. Diese Aufteilung ermöglicht es Entwicklern, die heutigen Standards zu unterstützen, ohne Vertrauen in einen einzigen fest zu codieren.