Wenn Software im Namen des Kunden handelt

Ein KI-Agent in Form eines Robots gibt am Laptop Zahlungen an die Bank frei
Bild: KI

Von KYC (Know Your Customer) zu KYA (Know Your Agent): Warum KYC im Zeitalter autonomer KI-Agenten eine weitere Ebene braucht.

Eine Rechnung liegt im Postfach. Die Zahlung wird geprüft und der Zahlungsauftrag an die Bank weitergeleitet. Prozesse wie dieser sind gang und gäbe und können doch in naher Zukunft eine neue Komponente bekommen. Eben dann, wenn diese Routineaufgaben nicht mehr Menschen, sondern KI-Agenten erledigen. Für Finanzinstitute entsteht dadurch eine neue Unsicherheit. Welches System handelt hier und wer hat genau diesen Vorgang autorisiert?

KI-Agenten können Webseiten bedienen, Formulare ausfüllen, Informationen aus verschiedenen Quellen verarbeiten und innerhalb eines vorgegebenen Rahmens selbstständig handeln. Damit rückt ein Akteur in den Mittelpunkt, der in den bisherigen Prozessen kaum vorgesehen war.

Know Your Customer (KYC) beantwortet, wer der Kunde ist. Know Your Agent, kurz KYA, nimmt zusätzlich das System in den Blick, das für eine Person oder Organisation handelt. Für Banken und Zahlungsdienstleister geht es dabei um eine belastbare Zuordnung. Sie müssen erkennen können, wer den Agenten betreibt, wie weit sein Auftrag reicht und wer für seine Handlung einsteht.

Automatisierung wird schwieriger einzuordnen

Automatisierte Zugriffe sind per se nichts Neues. Bisher waren es jedoch Bots, die meist nach festen Regeln arbeiten und daher leicht zu erkennen sind.

KI-Agenten sind dagegen weitaus flexibler. Sie helfen Menschen bei wiederkehrenden Abläufen, aber machen es auch Kriminellen leichter, Angriffe zu skalieren.

Der Identity Fraud Report 2025–2026 von Sumsub beschreibt eine Verschiebung hin zu anspruchsvolleren Angriffen. Die globale Identitätsbetrugsrate lag 2025 bei 2.2 Prozent. Gleichzeitig nahm der Anteil komplexer Betrugsversuche im Jahresvergleich um 180 Prozent zu.

Pauschal alle automatisierten Zugriffe zu sperren funktioniert nicht, da das auch legitime Nutzer treffen würde. Andererseits darf ein Agent auch nicht wie ein gewöhnlicher Nutzer behandelt werden, weil er beispielsweise kompromittiert und für kriminelle Aktivitäten genutzt werden könnte. Zusätzlich muss die Tragweite der Berechtigungen geprüft werden. Ein Agent, der Informationen abruft, stellt ein niedrigeres Risiko dar als ein System, das Geld bewegt oder Kontodaten verändert. Auch der Auftraggeber gehört in die Bewertung.

In einem solchen Prozess müssten mehrere Prüfungen ineinandergreifen. Zuerst weist sich der Agent gegenüber dem Finanzdienstleister mit einer eigenen technischen Identität aus. Danach wird geprüft, für welchen Kunden oder welches Unternehmen er handelt und welche Rechte ihm übertragen wurden. Vor der Ausführung werden Betrag, Zahlungsempfänger und Zweck der Transaktion mit dem ursprünglichen Auftrag abgeglichen. Weicht die Zahlung vom erwarteten Rahmen ab, muss sie nicht automatisch blockiert werden. Möglich wäre auch eine zusätzliche Prüfung oder die Freigabe durch eine verantwortliche Person.

Eine digitale Identität reicht nicht

Damit ein KI-Agent als technischer Akteur eindeutig erkennbar ist, braucht es Zertifikate, kryptografische Schlüssel oder Zugriffstoken. Diese Mittel beantworten aber zunächst nur die Frage, welcher technische Dienst kommuniziert. Für KYA müssen drei Ebenen getrennt betrachtet werden:

Welcher Agent handelt? Für wen handelt er? Und was darf er im konkreten Auftrag tun? Dazu braucht es eine nachvollziehbare Delegation durch eine Person oder Organisation sowie eng begrenzte, zeitlich kontrollierte und widerrufbare Berechtigungen. Ein Agent, der Zahlungseingänge sortiert, benötigt andere Rechte als ein System, das eine Überweisung vorbereitet. Die Befugnisse müssen zweckgebunden und widerrufbar sein.

Dabei müssen technische Identität, menschliche Verantwortung und konkrete Handlungserlaubnis getrennt betrachtet werden. Eine Maschinenidentität zeigt, welcher technische Akteur eine Verbindung aufbaut. Sie sagt noch nicht, für wen er handelt und welche konkrete Aktion freigegeben wurde. Ein Zertifikat kann die Identität eines Dienstes bestätigen, aber nicht automatisch die Erlaubnis für eine Überweisung an einen neuen Zahlungsempfänger. Dafür braucht es eine nachvollziehbare Delegation sowie eng begrenzte und zeitlich kontrollierte Berechtigungen.

Eine Prüfung beim Start genügt dafür nicht. Ein Agent kann nach einem Update anders reagieren oder kompromittiert werden. Bei hohen Beträgen oder Änderungen an sicherheitsrelevanten Daten sollte eine zusätzliche Freigabe durch eine verantwortliche Person möglich sein.

Vertrauen muss während der Nutzung bestehen

Klassisches KYC konzentriert sich häufig auf einen einzelnen Zeitpunkt. Autonome Agenten arbeiten allerdings über längere Zeiträume, wechseln zwischen Diensten und führen zahlreiche Aktionen aus. Unternehmen brauchen deshalb ein laufendes Bild der Aktivität. Technische Merkmale und das Verhalten innerhalb einer Sitzung sollten daher mit früheren Vorgängen verbunden werden.

Eine neue Sitzung allein muss dabei kein Betrugsindikator sein. Ein neues Zielkonto ebenfalls nicht. Treffen jedoch mehrere Abweichungen zusammen, wie etwa ein unbekannter Zugriff, ein neuer Zahlungsempfänger, ein ungewöhnlich hoher Betrag und ein Wechsel der verwendeten Werkzeuge, steigt das Risiko deutlich.

Die Reaktion sollte in verschiedenen Stufen erfolgen. In der ersten Stufe kann der Agent weiterarbeiten, in der zweiten muss er zusätzliche Informationen liefern, anschliessend werden einzelne Aktionen zurückgehalten und schlussendlich benötigt der Agent eine menschliche Freigabe. Dabei muss auch der Abgleich mit dem ursprünglichen Auftrag erfolgen. Wer einen Agenten mit dem Sortieren von Rechnungen beauftragt, hat damit nicht automatisch die Änderung von Kontodaten oder die Einrichtung eines neuen Zahlungsempfängers freigegeben.

Wenn fremde Inhalte den Auftrag umdeuten

Eine besondere Gefahr für die Sicherheit von KI-Agenten sind Prompt- und Instruction-Injection-Angriffe. Eine schädliche Anweisung kann in einer Webseite, einem Dokument, einer E-Mail oder der Antwort eines Werkzeugs versteckt sein. Behandelt der Agent sie als Befehl, verlässt er womöglich seinen ursprünglichen Auftrag.

KYA verhindert solche Angriffe nicht automatisch. Auch ein identifizierter Agent kann manipuliert werden. Seine Identität muss deshalb mit Regeln für den zulässigen Kontext verbunden werden. Welche Quellen dürfen Handlungen auslösen und wann braucht es eine menschliche Bestätigung? Im Nachhinein muss sich feststellen lassen, welcher Agent gehandelt hat, wer hinter ihm stand und weshalb eine Aktion freigegeben wurde.

KYA ist eine Managementaufgabe

Die Kontrolle autonomer Systeme lässt sich nicht allein an die IT-Abteilung delegieren. Die Geschäftsleitung muss festlegen, welche Aufgaben ein Agent übernehmen darf und wann ein Mensch eingreifen muss. Ein Agentenregister hält dabei fest, welche Systeme im Einsatz sind, wer verantwortlich ist, worauf sie zugreifen und welche Handlungen erlaubt sind.

Für Finanzdienstleister wird die Abstimmung zwischen Plattformen relevant. Ein Agent kann ein Produkt auswählen, Daten übermitteln, eine Zahlung auslösen und die Bestätigung eines weiteren Dienstes verarbeiten. Dabei muss jede Plattform erkennen, welcher Akteur handelt und welche Autorisierung gilt.

Vom Kundenwissen zum Handlungswissen

KYC bleibt die Grundlage für den Zugang zu Finanzdienstleistungen. Wenn Software im Namen eines Kunden handelt, muss diese Grundlage um Maschinenidentität, menschliche Verantwortung, begrenzte Befugnisse und laufende Risikoanalyse erweitert werden.

Ein Agent sollte innerhalb klarer Grenzen arbeiten. Verändert sich sein Verhalten oder steigt das Risiko einer Handlung, braucht es eine passende Prüfung. Im kritischen Moment muss die Verantwortung feststehen.

Im digitalen Banking reicht es künftig nicht aus, zu wissen, wem ein Konto gehört. Anbieter müssen auch nachvollziehen können, welches System für diese Person handeln darf, wie weit dessen Befugnisse reichen und ob sich eine relevante Aktion erklären lässt.

Der Autor: Mick Amelishko

Mick Amelishko, Engineering Leader & AI Advocate bei Sumsub

Mick Amelishko ist Engineering Leader mit mehr als 15 Jahren Erfahrung im Aufbau verteilter Systeme und in der Skalierung wachstumsstarker B2B-SaaS-Plattformen, die von Millionen Menschen genutzt werden.

Bei Sumsub verantwortet er als AI Advocate die Einführung und Weiterentwicklung von KI-Agenten sowie den Aufbau agentischer Infrastrukturen auf Basis des Model Context Protocol (MCP).

Zuvor leitete Mick Amelishko bei PandaDoc Engineering-Teams und war unter anderem für Plattformen zur Workflow-Automatisierung, Zahlungsinfrastrukturen, API-Ökosysteme und die Automatisierung dokumentenbasierter Prozesse verantwortlich.