LLM-Agent löst 14-fache Kreditkartenabbuchung nach Netzwerk-Timeout aus

14-fache Abbuchung nach Netzwerk-Timeout

Ein Patient zahlte an einem Check-in-Kiosk einer ambulanten Notaufnahme eine Zuzahlung von 75 US-Dollar per Kreditkarte. Genau in diesem Moment verursachte eine Netzwerk-Partition zwischen dem Revenue-Cycle-Management-Gateway des Krankenhauses und dem Zahlungsabwickler einen HTTP-504-Gateway-Timeout. Die Kreditkarte war zu diesem Zeitpunkt bereits upstream autorisiert, doch das Bestätigungspaket ging verloren, bevor es über die Transportschicht zurückkam. In einer autonomen Agentenarchitektur mit einem LLM-gesteuerten Planungsloop – etwa ReAct, LangGraph oder AutoGen – bewertet der Agent die Fehlermeldung und startet automatisch Wiederholungsversuche. Das Sprachmodell versteht jedoch nicht, dass ein API-Aufruf eine Live-Abbuchung vom Bankkonto eines Menschen darstellt. Es besitzt kein internes Modell der doppelten Buchführung und ist nicht darauf trainiert, finanzielle Konsequenzen zu modellieren; seine Verlustfunktion ist auf die Lösung der gestellten Aufgabe optimiert. Der Agent interpretierte den Timeout als fehlgeschlagenen Aufruf, obwohl die Zahlung bereits autorisiert war. Da die Bestätigung verloren ging, fehlte dem System der Nachweis über den Erfolg. Der LLM-basierte Agent erkannte die finanzielle Tragweite nicht, da das Sprachmodell keine inhärente Kenntnis von Buchungslogik besitzt und auf die Lösung der gestellten Aufgabe optimiert ist. Es behandelte den Fehler als technischen Ausfall und startete automatisch Wiederholungsversuche. Die Folge war eine Kaskade von 14 Abbuchungen für eine einzige Zuzahlung.

Architektur gegen Abrechnungskaskaden

In einer traditionellen serviceorientierten Architektur hätte ein strikter Zustandsautomat den Fall anders behandelt. Die Transaktion wäre in einen ausstehenden Zustand versetzt worden, ein Abgleich über einen Idempotenzschlüssel hätte den tatsächlichen Status beim Gateway ermittelt, und die Benutzeroberfläche hätte einen Wartezustand angezeigt. Ein solcher Mechanismus verhindert doppelte Ausführungen, weil jeder Aufruf eindeutig identifiziert und nur einmal verarbeitet wird. Der Idempotenzschlüssel stellt sicher, dass derselbe Aufruf nicht erneut ausgeführt wird, selbst wenn die Antwort verloren geht. Die Zustandsverwaltung verfolgt den Status der Transaktion nach und verhindert, dass ein Agent fälschlicherweise annimmt, die Zahlung sei fehlgeschlagen. Der Fachbeitrag fordert deshalb eine spezielle Architektur für verteilte Systeme, die Idempotenzschlüssel und Zustandsverwaltung umfasst. Ohne diese Absicherung können autonome Agenten, die auf Aufgabenlösung optimiert sind, finanzielle Transaktionen fehlinterpretieren und unkontrolliert wiederholen. Die notwendige Architektur muss sicherstellen, dass Wiederholungsversuche keine zusätzlichen Abbuchungen auslösen, sondern lediglich den Status abfragen oder auf eine Bestätigung warten. Gerade bei LLM-gesteuerten Agenten, die keine inhärente Kenntnis von Buchungslogik besitzen, ist eine solche Infrastruktur unverzichtbar, um Abrechnungskaskaden zu verhindern.