Mythos trifft DORA Art. 20: KI‑Workloads ohne eigene Identität sind Audit-Müll

Mythos macht jeden Mitarbeiter zum Hacker. DORA verlangt Kontrolle. Beides trifft auf Systeme, die dafür nicht gebaut sind.
Anthropics Mythos senkt die Einstiegshürde für Exploits auf null. Gleichzeitig greifen KI-Agenten unkontrolliert auf Kernbankensysteme zu. Art. 20 und 21 RTS RMF verlangen Identitätsmanagement für alle Systeme. Die meisten Institute können das technisch nicht liefern.

von Josef Nemecek, Saviynt

Anthropics KI-Modell Mythos findet autonom Sicherheitslücken in Betriebssystemen und Browsern. In FreeBSD eine 17 Jahre alte Schwachstelle mit Root-Zugriff. In OpenBSD einen Bug, der 27 Jahre unentdeckt blieb. Mozilla hat mit Mythos 271 Schwachstellen in Firefox identifiziert und gepatcht (hier).
Was das für die Finanzbranche bedeutet: Die Einstiegshürde für das Ausnutzen von Schwachstellen verschwindet.

Anthropics eigene Ingenieure ohne Sicherheitsausbildung haben das Modell abends gestartet und am nächsten Morgen einen funktionierenden Exploit vorgefunden.“

Das BSI spricht von einem möglichen Paradigmenwechsel. Der Bundesverband deutscher Banken koordiniert die Reaktion mit BaFin und Bundesbank (hier).

KI-Agenten als unkontrollierte Identitäten

Parallel setzen Finanzinstitute KI-Agenten produktiv ein, die Compliance-Prüfungen automatisieren und auf Kernbankensysteme zugreifen. Gartner prognostiziert, dass bis Ende 2026 rund 40 Prozent der Unternehmensanwendungen mit aufgabenspezifischen KI-Agenten ausgestattet sein werden (hier).
Jeder dieser Agenten ist eine Identität mit Credentials und Zugriff auf Kernbanksysteme. Eine Saviynt-Studie unter 100 deutschen CISOs zeigt: 93 Prozent haben KI-Identitäten in ihren Kernsystemen, nur 25 Prozent steuern diese Zugriffe mit klaren Richtlinien. 76 Prozent haben unsanktionierte KI-Tools entdeckt, oft mit eigenen Credentials und erhöhten Berechtigungen (hier).

Was DORA verlangt und wo die Lücke klafft

Die BaFin hat Anfang 2025 die BAIT aufgehoben. Die Spielregeln kommen jetzt aus DORA (hier). Art. 20 RTS RMF fordert Identitätsmanagement, das die Identifizierung und Authentifizierung von Personen und Systemen sicherstellt. Art. 21 konkretisiert: Need-to-Use-Prinzip, halbjährliche Rezertifizierung für kritische Systeme, Zurechenbarkeit aller Handlungen (hier).
Entscheidend: Art. 20 spricht von „Personen und Systemen“.

KI-Agenten sind Systeme. Die Frage, ob sie als Identitäten zu behandeln sind, ist regulatorisch beantwortet. In der Praxis sieht es anders aus.“

Wo es technisch scheitert

Das Inventar-Problem. Die meisten Banken haben ein IAM-System für menschliche Nutzer: Active Directory, LDAP, teilweise RACF auf dem Mainframe. KI-Agenten tauchen dort nicht auf. Sie laufen in Cloud-Umgebungen und nutzen AI-Frameworks, werden auf lokalen Rechnern ausgeführt, oder arbeiten direkt in Systemen wie Microsoft, Salesforce, ServiceNow oder SAP. Für den Zugriff auf Zielsysteme brauchen sie Credentials und ein Tool für die Kommunikation: ODBC/JDBC für Datenbank-Zugriffe, REST/WebService für APIs, RPA für Benutzerschnittstellen.

Wenn Mitarbeiter leichtsinnig ihre eigenen Zugangsdaten verwenden, arbeiten die Agenten im Impersonation-Modus und sind nicht vom realen Benutzer zu unterscheiden.“

Schlimmer noch: Nutzt man administrative Service-Accounts, erkennt der Agent, den gerufenen Geistern des Zauberlehrlings gleich, diese Privilegien und kann sie nutzen. Jeder Agent braucht deshalb eine eigene Identität mit eigenen Zugriffsdaten und angepassten Berechtigungen. Und das IGA-System muss die Agenten aufspüren können, egal ob in der Cloud, in einer VM oder auf dem eigenen Rechner.
Das Lifecycle-Problem. Art. 21 RTS RMF verlangt Konto­verwaltungs­verfahren für die Gewährung, Änderung und Entziehung von Zugangsrechten. Für menschliche Nutzer existieren Joiner-Mover-Leaver-Prozesse. Für KI-Agenten gibt es kein Äquivalent.

Ein Agent wird deployt, bekommt Credentials und läuft.“

Wenn das Projekt endet oder der Dienstleister den Vertrag beendet, passiert meist nichts.
Mit einem modernen IGA-System lässt sich das lösen: Beim Deployment wird, wie bei externen Mitarbeitern, per Formular oder API-Aufruf eine Agenten-Identität erstellt. Der Agent nutzt den zurückgegebenen Token für die Authentisierung. Das IGA-System übernimmt die Rechteverwaltung inklusive Zertifizierungen, erkennt missbräuchliche Zugriffe und SOD-Verletzungen und deaktiviert den Zugang bei Nutzungsende.
Das Rezertifizierungs-Problem. DORA verlangt halbjährliche Rezertifizierung für kritische Systeme. Bei KI-Agenten wird das exponentiell komplexer, weil sie Rechte dynamisch eskalieren. In Agentic-AI-Architekturen delegieren Agenten Aufgaben an andere Agenten und reichen Berechtigungen weiter.

Man muss Agenten mittels Policies und Guardrails permanent überwachen und gewisse Calls und Tools verbieten.“

Bei einem Pool orchestrierter Agenten muss man zusätzlich prüfen, ob sich der Benutzer mittels Agenten Berechtigungen „erschleicht“, die zu einer SOD-Verletzung führen: Per eigener Berechtigung eine Rechnung anlegen, per Agent diese zur Zahlung freigeben.
Das Drittanbieter-Problem. DORA Art. 28 ff. stellt strenge Anforderungen an IKT-Drittparteienrisiko. KI-Agenten kommen oft von externen Anbietern und bringen eigene Credentials mit. Würden Agenten mindestens gleich behandelt wie externe Mitarbeiter, würden die JML-Prozesse der IGA-Lösung funktionieren: Der Agent verliert seinen Zugriff, weil man die Benutzerkonten deaktiviert.

Darum braucht es klare Richtlinien, wie Agenten-Identitäten geschaffen werden, und Mechanismen, um Agenten zu erkennen, die sich nicht an die Regeln halten.“

Was jetzt passieren muss

Sichtbarkeit schaffen. Verschaffen Sie sich einen Überblick, welche Agenten im Einsatz sind. Verbinden Sie sich mit den Plattformen (Microsoft Copilot, AWS Bedrock), nutzen Sie Endpoint-Security-Systeme zur Erkennung von Workloads, und analysieren Sie API-Logdateien der Kernsysteme auf Anomalien. Mit diesen Daten wissen Sie, wer welche Agenten erstellt hat.
Governance etablieren. Verpflichten Sie Ihre Mitarbeiter, für Agenten eine eigene Identität zu besorgen. Das IGA-Team stellt dafür einfache Mittel bereit, vergleichbar mit dem Onboarding eines externen Mitarbeiters. Ohne eigene Identität riskieren Mitarbeiter den Verlust ihrer Zugangsrechte, wenn ihr Agent außer Kontrolle gerät.
Überwachung und Ökosystem aufbauen. Prüfen Sie die Aktivität der Agenten, besonders außerhalb der Bürozeiten. Halten Sie die Berechtigungen bewusst kleiner als die der Benutzer, da Menschen von sich aus selten auf die Idee kommen, ihre Möglichkeiten auszuloten. Bauen Sie ein Sicherheits-Ökosystem auf, das abweichendes Verhalten erkennt und per IGA-Aufruf ein Konto kurzfristig sperren kann. Josef Nemecek, Saviynt