KI

KI-Zahlungen: Eine gültige Freigabe schützt nicht vor der falschen Auswahl

KI-Agenten sollen Angebote vergleichen und Zahlungen vorbereiten. Eine neue Sicherheitsanalyse zeigt, weshalb dafür zwei Kontrollen nötig sind: über den Kauf selbst und über die Daten, die anschließend freigegeben werden.

Von Wolfgang

17. Sep. 20264 Min. Lesezeit

KI-Zahlungen: Eine gültige Freigabe schützt nicht vor der falschen Auswahl

KI-Agenten sollen Angebote vergleichen und Zahlungen vorbereiten. Eine neue Sicherheitsanalyse zeigt, weshalb dafür zwei Kontrollen nötig sind: über den Kauf selbst und über die Daten, die anschließend freigegeben werden.

Ein Einkaufsagent kann einen Auftrag korrekt bezahlen und trotzdem das falsche Angebot ausgesucht haben. Für Nutzer ist beides Teil desselben Einkaufs. Technisch liegen dazwischen jedoch mehrere Schritte, die unterschiedlich abgesichert werden müssen. Genau diese Trennung wird wichtig, sobald KI-Assistenten mehr übernehmen als die Suche.

Die Bereitschaft dazu ist durchaus vorhanden. In einer am 16. September veröffentlichten Experian-Befragung von Forrester Consulting fühlten sich 54 Prozent der Befragten damit wohl, dass ein KI-Agent in ihrem Namen einen Kredit beantragt. Befragt wurden im Juli 6.247 digital erfahrene, kreditaktive Menschen in 13 Märkten. Das ist keine Quote für die deutsche Gesamtbevölkerung und kein Nachweis tatsächlicher Nutzung. Ein Kreditantrag ist zudem etwas anderes als eine Zahlung. Die Umfrage zeigt aber, weshalb der Umfang delegierter Entscheidungen genauer betrachtet werden muss.

Die Freigabe bindet einen konkreten Auftrag

Ein Ansatz dafür ist das offene Agent Payments Protocol, kurz AP2. Seine Spezifikation in Version 0.2 unterscheidet zwei miteinander verknüpfte Freigaben: Ein Checkout-Mandat beschreibt den Kauf, ein Payment-Mandat die zugehörige Zahlung. Digitale Signaturen machen prüfbar, ob diese Daten seit ihrer Unterzeichnung verändert wurden und mit welchem Schlüssel sie unterschrieben sind.

Damit wird eine wichtige Grenze gezogen. Ein Agent soll einen freigegebenen Warenkorb nicht nachträglich gegen einen anderen austauschen können. Die Prüfungen müssen laut Spezifikation durch festgelegten Programmcode erfolgen. Das Sprachmodell soll also nicht selbst darüber befinden, ob seine Zahlung die Regeln einhält.

Wie der Agent zuvor aus einem Nutzerwunsch die passenden Auftragsdaten ermittelt, liegt dagegen außerhalb dieses Protokollumfangs. Die Daten können unverändert geblieben sein, obwohl schon ihre Auswahl problematisch war.

Vier Schritte vom Angebot über Auswahl und Freigabe zur Zahlung; Inhalte können vor der Freigabe beeinflussen, Signaturen sichern die anschließende Datenbindung.
KI-generierte schematische Darstellung: Auswahl und Zahlungsfreigabe sind unterschiedliche Kontrollaufgaben. Die Grafik ist keine Darstellung eines konkreten Bankprodukts.

Der Fehler kann vor der Unterschrift entstehen

Eine am 24. August veröffentlichte Sicherheitsanalyse von AP2 v0.2 untersucht diese Übergänge. Die Autoren beschreiben unter anderem, wie manipulierte Inhalte die Zusammenstellung eines Auftrags beeinflussen können. Ein weiteres Risiko entsteht, wenn die angezeigte Zusammenfassung nicht den strukturierten Feldern entspricht, die tatsächlich unterschrieben werden. Eine erfolgreiche Signaturprüfung allein würde diesen Unterschied nicht erklären.

Die Arbeit ist ein Preprint. Weil nach Angaben der Autoren keine vollständige öffentliche AP2-Implementierung verfügbar war, verwendeten sie ein eigenes Testsystem für ihre Angriffsdemos. Daraus folgt kein Nachweis einer ausgenutzten Lücke bei einer bestimmten Bank oder eines verbreiteten Schadens bei Käufern. Der Befund betrifft die Gestaltung und Umsetzung solcher Systeme.

Ein vereinfachtes, hypothetisches Beispiel verdeutlicht den Unterschied: Ein Nutzer sucht einen bestimmten Kopfhörer innerhalb seines Budgets. Der Agent wählt ein ähnlich benanntes Modell ohne die gewünschte Funktion. Wird genau dieser Warenkorb angezeigt, freigegeben und unverändert bezahlt, kann die Zahlung technisch korrekt sein. Die Auswahl erfüllt den Wunsch trotzdem nicht. Eine Signatur bewertet keine Produkteigenschaften.

Schutzmaßnahmen müssen außerhalb des Chats greifen

Das Protokoll ignoriert solche Risiken keineswegs. Die offiziellen Sicherheitsüberlegungen zu AP2 beziehen manipulierte Agenten ausdrücklich ein. Sie beschreiben auch den Fall, dass eingeschleuste Anweisungen einen Einkaufsagenten zu schlechten Kaufentscheidungen bewegen. Vorgesehen sind unter anderem die Bindung der Zahlung an den Checkout sowie die Prüfung erlaubter Empfänger und Beträge.

Diese Begrenzungen haben einen konkreten Nutzen: Eine schlechte Auswahl soll nicht automatisch unbegrenzte finanzielle Handlungsmöglichkeiten eröffnen. Ihre Wirkung hängt allerdings davon ab, welche Grenzen genehmigt wurden und ob die beteiligten Systeme sie tatsächlich durchsetzen. Ein großzügiges Budget korrigiert keine missverstandene Produkteigenschaft.

Für die Gestaltung solcher Dienste folgt daraus eine zweifache Aufgabe. Die Oberfläche muss verständlich zeigen, welcher konkrete Kauf freigegeben wird. Die anschließende technische Prüfung muss genau an diese Daten gebunden sein. Bei vorab erteilten Befugnissen wird zusätzlich wichtig, welche Entscheidungen offenbleiben und wann der Nutzer erneut beteiligt wird.

Der Fortschritt liegt damit in einer nachvollziehbaren Arbeitsteilung: Die KI unterstützt die Auswahl, der Nutzer kann den Auftrag beurteilen, und Programmcode begrenzt seine Ausführung. Ob ein Dienst diese Verbindung zuverlässig herstellt, lässt sich an seiner tatsächlichen Umsetzung prüfen. Das Etikett „signierte Zahlung“ beantwortet nur einen Teil davon.

Quellen

Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft.