US-Banken sperren KI-Agenten in Kundenkonten

Was Axios berichtet hat¶

Der Bericht stützt sich vor allem auf mit der Sache vertraute Personen. Seine Kernpunkte, sinngemäß wiedergegeben:

• Genannte Banken. Morgan Stanley, Bank of America, JPMorgan, Wells Fargo und andere bemühen sich mit Hochdruck, die Risiken von Agenten in Kundenkonten einzudämmen.
• Wie die Agenten hineinkommen. Die Agenten nutzen in der Regel die Erlaubnis und die Anmeldedaten des Kunden. Die Regeln der meisten Banken verlangen, dass Kunden sich selbst bei ihren eigenen Konten anmelden.
• Was die Agenten taten. Einige Banken stellten fest, dass Agenten Callcenter kontaktierten oder Aktionen unabhängig von den Anweisungen der Nutzer ausführten.
• Was die Banken unternehmen. Morgan Stanley hat laut Quellen begonnen, Agenten Dritter von seinen Plattformen auszusperren. JPMorgan, Bank of America und Citi schränken Agenten ein. Die Banken überarbeiten ihre Nutzungsbedingungen, weil sie einen Menschen kaum von einem nicht autorisierten Bot unterscheiden können.
• Nur-Lese-Zugriff. Die meisten Banken haben für Agenten einen Nur-Lese-Zugriff erlaubt oder bewegen sich darauf zu, ähnlich dem Zugriff, den Budget-Apps bereits erhalten.
• Vorbereitung. Die Banken investieren in die Verhinderung von Worst-Case-Szenarien und planen für den Tag nach einem Vorfall, einschließlich der Frage, wie sich der Zugang der Kunden sichern oder wiederherstellen lässt.

Was der Bericht nicht sagt¶

Der Bericht beschreibt keine Verluste bei Kunden, keinen bestätigten Sicherheitsvorfall und keine Maßnahme einer Aufsichtsbehörde. Ein Sprecher von Chase sagte, Kunden sollten Benutzernamen und Passwörter mit niemandem teilen. Ein Sprecher von Morgan Stanley sagte, die Bank habe keine Fälle beobachtet, in denen abtrünnige KI-Agenten auf ihre Plattformen zugegriffen hätten. Ein namentlich nicht genannter Bankmanager sagte, es sei schwer zu erkennen, ob ein Nutzer einen Agenten autorisiert habe oder ob der Agent eigenständig gehandelt habe.

Der Bericht dokumentiert ein Kontrollproblem, an dem die Banken derzeit arbeiten.

Warum eine Anmeldeprüfung die Frage nicht beantworten kann¶

Wenn ein Kunde einem Agenten sein Passwort überlässt, trägt jede Anfrage des Agenten die Identität des Kunden. Die Bank sieht eine gültige Sitzung. Sie sieht nicht, dass Software die Aktion gewählt hat, welche Anweisung der Kunde gegeben hat oder ob die Aktion dazu passt. An diesem Punkt hat die Bank zwei grobe Optionen: die Sitzung zulassen oder alles sperren, was automatisiert wirkt. Eine Sperre schützt das Konto und stoppt zugleich die Agenten, die Kunden nutzen wollen.

Nur-Lese-Zugriff verringert das Risiko, weil eine Saldoabfrage kein Geld bewegt. Die schwierige Frage bleibt damit aber offen für den Moment, in dem Agenten handeln dürfen.

Was ein Checkpoint pro Aktion ändert¶

Ein Laufzeit-Checkpoint bewertet jede Aktion, die ein Agent vorschlägt, bevor sie ausgeführt wird. Dafür muss der Agent eine eigene Identität verwenden, getrennt vom Passwort des Kunden, und jede vorgeschlagene Aktion über einen Kanal senden, den die Bank steuert. Der Checkpoint liefert dann eines von vier Ergebnissen: allow, warn, require_approval oder block. Die strengste zutreffende Regel setzt sich durch.

Die folgende Richtlinie ist ein synthetisches Beispiel für ein Privatkundenkonto. Sie zeigt, wie eine Bank nützliche Arbeit von Agenten zulassen und dennoch vor jeden Geldabfluss vom Konto einen Menschen setzen kann.

require_approval setzt einen Menschen vor jeden Geldabfluss vom Konto¶

Mit require_approval hält der Checkpoint die konkrete Aktion mit Betrag, Zahlungsempfänger und Datum an und bittet eine autorisierte Person um eine Entscheidung. Bei Privatkunden ist diese Person der Kunde. Bei einem Firmenkonto ist es der vom Kunden benannte Treasury-Prüfer. Die Freigabe sollte nur die Aktion abdecken, die die Person gesehen hat. Ändert der Agent danach Betrag oder Zahlungsempfänger, gilt die Freigabe nicht mehr, und die Aktion wird erneut bewertet.

Im Oktober 2026 haben wir für ein Analysten-Briefing einen Process zur Freigabe zurückgehaltener Zahlungen gebaut, mit Agentenentwürfen, synthetischen Daten und ohne Anbindung an ein Zahlungssystem. Drei Agenten verifizieren die Anweisung, aktualisieren das Screening und bereiten eine Freigabeempfehlung vor, und eine Person im Zahlungsverkehr autorisiert die Freigabe. Die Richtlinie sperrt bestätigte Sanktionstreffer, doppelte Zahlungen und Zurückhaltungen ohne dokumentierte Klärung, und sie leitet jede Freigabeempfehlung an einen unabhängigen Prüfer. In der Simulation löste ein bestätigter Sanktionstreffer sowohl den Sanktionsstopp als auch die Freigaberegel aus, und das Ergebnis war block, weil block Vorrang hat.

Zwei Gestaltungsentscheidungen aus diesem Aufbau gelten für jeden Agenten, der Geld bewegt. Eine Ablehnung lässt die ursprüngliche Zurückhaltung bestehen. Freigabe und Abwicklung sind getrennte Datensätze, sodass eine genehmigte Zahlung erst dann als abgeschlossen gilt, wenn ihre Abwicklungsreferenz erfasst ist. Der Aufbau hat uns außerdem gelehrt, jeder Entscheidung genau eine Freigabe zu geben: Unsere erste Einreichung zur Prüfung scheiterte, weil zwei menschliche Schritte zusätzlich ein Freigabe-Flag trugen, was für eine Entscheidung zwei Freigabeaufgaben erzeugt hätte.

Die Entscheidungsmatrix für Freigaben legt Schwellenwerte, Prüferrollen, Ablauf und Ausnahmefälle für diese Art von Regel fest.

Nachweise beantworten die Frage, die Banken heute nicht beantworten können¶

Das Problem des ungenannten Managers ist ein fehlender Datensatz. Wenn eine Aktion durch einen Checkpoint läuft, kann die Bank festhalten, wer dem Agenten Befugnisse übertragen hat, welcher Agent in welcher Version gehandelt hat, was er vorgeschlagen hat, welche Richtlinienregel griff, welches Ergebnis folgte, wer wann freigegeben hat und was das nachgelagerte System getan hat. Mit diesem Datensatz kann die Bank einer Kundenbeschwerde oder einem Prüfer mit Fakten antworten.

Der Widerruf gehört in denselben Datensatz. Wenn ein Kunde die Delegation widerruft, sollte die nächste vorgeschlagene Aktion abgewiesen und die Abweisung aufgezeichnet werden. Der Leitfaden zur Kill-Switch-Architektur behandelt den Stopp-Pfad und eine Übung, um ihn zu testen.

Wo KLA passt und wo nicht¶

Die KLA Control Plane steuert Aktionen von Agenten, die über sie geleitet werden. Agenten, die über den KLA Agent Action Ingress handeln, arbeiten unter einem Agentenmandat mit verantwortlichem Eigentümer, erlaubten Tools und Zielen, Schwellenwerten für Parameter wie den Betrag und einem Enddatum. Die KLA Policy Engine liefert für jede vorgeschlagene Aktion allow, warn, require_approval oder block. Schlägt die Richtlinienauswertung fehl, wird die Aktion nicht ausgeführt. Ein Ergebnis require_approval erzeugt einen Decision Request; Decision Desk weist Entscheidungen des Antragstellers zurück, und die Freigabe ist an einen Hash der Aktionsargumente gebunden, sodass eine geänderte Anfrage gesperrt wird. Der Widerruf eines Mandats sperrt offene Vorschläge und weist die nächste Aktion des Agenten ab. Jeder Schritt wird für Lineage Explorer, Audit Trail und Evidence Room aufgezeichnet. Dieser Absatz beschreibt den aktuellen Quellcode.

KLA erkennt keinen Agenten eines Dritten, der sich mit einem vom Kunden geteilten Passwort anmeldet. Bot-Erkennung, Sitzungsrisiko und die Durchsetzung der Nutzungsbedingungen bleiben bei den Betrugs- und Digitalkanälen der Bank. KLA steuert die Agenten, die eine Bank oder ihre Partner über einen gesteuerten Kanal anbinden.