Irgendwo in der Betrugsabwehr einer US-Bank öffnete sich diese Woche eine Sitzung mit gültigem Benutzernamen, gültigem Passwort und gültigem Einmalcode. Alle Prüfungen bestanden. Das Problem: Es saß kein Mensch dahinter.
Axios berichtete am 22. Oktober, dass große US-Banken, darunter Morgan Stanley, Bank of America, JPMorgan und Wells Fargo, KI-Agenten von Drittanbietern in Kundenkonten entdecken. In den meisten Fällen hat der Kunde seine eigenen Zugangsdaten weitergegeben, was jede Bank in ihren AGB ausdrücklich verbietet. Manche Agenten haben Callcenter angerufen. Andere haben Aktionen ausgeführt, die unabhängig von der Nutzeranweisung wirken. Führungskräfte nannten es "erschreckend".
Lies das noch einmal. Die Zugangsdaten waren echt. Die Zustimmung war echt, zumindest am Anfang. Und die Bank konnte die einzige Frage, die um zwei Uhr nachts zählt, trotzdem nicht beantworten: Hat der Kontoinhaber genau diese Aktion autorisiert?
Das Problem war nie die Authentifizierung
Zwanzig Jahre lang haben wir Logins fälschungssicher gemacht. Passwörter, dann MFA, dann Passkeys. Alles beantwortet eine Frage: Ist diese Person, wer sie vorgibt zu sein?
Agenten zerlegen diese Frage in zwei Hälften. Der Login ist tatsächlich der Kunde. Die Aktion vielleicht nicht. Und sobald ein Agent ein Sitzungstoken hält, sieht er aus wie ein sehr schneller Mensch, außer dass er in Maschinengeschwindigkeit handelt und nie müde oder misstrauisch wird.
Banken stecken nun in einer Kontrolllücke, die sich nicht mit besserem MFA schließen lässt, weil der menschliche Teil bereits erfolgreich war. Es fehlt die Bindung der Autorisierung an eine konkrete Aktion statt an eine Sitzung. Das ist kein Authentifizierungsproblem. Es ist ein Autorisierungs- und Attributionsproblem, und die meisten Organisationen außerhalb des Bankwesens haben dasselbe Loch.
Was Banken gerade tun
Die erste Reaktion ist Blockieren. Morgan Stanley verweigert Drittanbieter-Agenten inzwischen den Zugang zu seinen Plattformen. JPMorgan, Bank of America und Citi beschränken sie. Chase ist deutlich: Geben Sie Benutzernamen und Passwort niemals weiter.
Die zweite Reaktion ist Verengung. Die meisten Banken bewegen sich auf Nur-Lese-Zugriff zu, dasselbe Modell, das bereits Budget-Tools wie Quicken Salden sehen lässt, ohne Geld zu bewegen. Lesen ist ein grundlegend kleineres Risiko als Schreiben, und das wissen die Banken.
Die dritte Reaktion ist Szenarioplanung. Mehrere Institute proben den Tag danach: Wie sperrt man einen Kunden schnell, wie stellt man Zugang wieder her, wie beweist man, was passiert ist. Das ist ein reifer Instinkt und zugleich das Eingeständnis, dass Prävention allein nicht hält.
Warum Attribution der schwierige Teil ist
Das unbequeme Detail im Axios-Bericht: Viele Banken können nicht feststellen, ob Agentenaktivität überhaupt nutzergesteuert war. Sie können einen Agenten kaum von einem anderen unterscheiden, geschweige denn sagen, ob er eine Berechtigung hatte oder einfach Zugangsdaten.
Das ist ein Designfehler, kein Personalproblem. Wenn der einzige Nachweis einer Aktion "authentifizierte Sitzung hat Überweisung ausgeführt" lautet, hast du keine Beweiskette. Du hast einen Zeitstempel.
Vergleiche das mit dem, was eine agentenfähige Kontrollebene protokollieren würde:
- Wer der Agent ist: eine registrierte Client-Identität mit eigenem Schlüssel, nicht eine geliehene menschliche Sitzung.
- Was der Mensch verlangt hat: die tatsächliche Anweisung, erfasst am Punkt der Absicht.
- Welcher Umfang erteilt wurde: eine enge Berechtigung pro Aktion mit Betragsgrenze und Ablauf.
- Was tatsächlich passiert ist: die ausgeführte Aktion, korreliert mit der erteilten Berechtigung.
Mit diesen vier Datensätzen beantwortet eine Bank die Zwei-Uhr-Nachts-Frage in Sekunden. Ohne sie kann sie nur raten, und Raten bedeutet, alles zu blockieren.
Was das außerhalb des Bankwesens bedeutet
Wer Lohn, Rechnungen, Einkauf, CRM oder Infrastruktur betreibt, hat dasselbe Muster schon im Stack. Ein Assistent oder Agent mit langlebiger Zugangsdaten kann alles tun, was diese Zugangsdaten können. Genau diesen Fehlermodus haben wir gestern beschrieben, als LiteLLM einen Credential-Stealer auf PyPI veröffentlichte und Live-Tokens für jeden Installierenden offenlegte.
Die Lehre wiederholt sich, weil sich die Architektur wiederholt. Agenten bekommen menschliche Zugangsdaten, weil es einfach ist, und menschliche Zugangsdaten sind alles oder nichts.
Eine bessere Form sieht so aus:
- Eigene Identität pro Agent. Ein Servicekonto oder OAuth-Client mit eigenem Schlüssel, widerrufbar ohne Eingriff in einen menschlichen Login.
- Begrenzte, kurzlebige Rechte. Standardmäßig nur Lesen. Schreiben pro Aktionstyp, mit Limits und Ablauf in Minuten statt Monaten.
- Zustimmung im Moment der Aktion. Will der Agent Geld bewegen, bestätigt der Mensch diese Überweisung, nicht "der Agent darf mein Konto nutzen".
- Ein Audit-Trail, der die Berechtigung nennt. Jede relevante Aktion sollte auf das Berechtigungsobjekt zeigen, das sie autorisiert hat.
- Kill-Switches ohne Passwortwechsel. Widerrufe den Agenten, der Mensch arbeitet weiter.
Nichts davon ist exotisch. Es ist gewöhnliches Autorisierungsdesign, angewandt auf eine Client-Klasse, die es nicht gab, als die meisten dieser Systeme gebaut wurden.
Das Fazit
Die unbequeme Wahrheit der Bankengeschichte: Die Agenten sind nicht eingebrochen. Sie wurden hereingelassen, mit echten Zugangsdaten und echtem Nutzerwunsch, und die Institute hatten keine Sprache für den Unterschied zwischen "mein Kunde hat das verlangt" und "etwas mit der Sitzung meines Kunden hat das getan".
Jede Organisation, die Agenten einsetzt, wird diese Sprache bald brauchen. Geh davon aus, dass dein Agent eines Tages etwas tut, das du nicht wolltest, und entwirf das Protokoll, das du am nächsten Morgen lesen möchtest. Wenn du nicht sagen kannst, wer eine Aktion autorisiert hat, welchen Umfang sie hatte und was sie berührt hat, hast du noch keine Agentensicherheit. Du hast einen Agenten und eine Hoffnung.
Wenn du Agentenzugriffe in deinem Stack kartierst und ein zweites Paar Augen auf das Berechtigungsdesign willst, ist das genau unsere Arbeit bei aratech.