In einem früheren Beitrag haben wir über den Zugriff von Agenten gesprochen. Genauer gesagt darüber, warum die meisten KI-Agenten zu viel davon haben und wie sich dies durch die auf Richtlinien basierende Aufrufsteuerung von Werkzeugen ändern lässt.
Heute gehen wir noch einen Schritt weiter: die Identität des Agenten.
Wenn ein KI-Agent innerhalb Ihrer Unternehmenssysteme eine Aktion ausführt, welche Identität verwendet er dabei? Das scheint eine einfache Frage zu sein. Bei den meisten KI-Implementierungen in Unternehmen ist die Antwort jedoch überraschend unklar.
Die Falle des Dienstkontos
So läuft es normalerweise ab: Ein Entwickler richtet einen KI-Agenten ein und möchte, dass dieser eine Verbindung zu einem Backend-System, einem CRM, einem ERP und einem Data Warehouse herstellt. Er erstellt ein Dienstkonto mit den erforderlichen Berechtigungen. Diese Anmeldedaten übermittelt er dem Agenten. Fertig.
Das ist pragmatisch, schnell und nahezu universell einsetzbar. Leider bringt diese Abkürzung auch ein grundlegendes Identitätsproblem mit sich. Schlimmer noch: Genau diese Art von Problem verhindert, dass funktionsfähige KI-Systeme die Freigabe für den Einsatz in der Produktion erhalten. Schauen wir uns einmal an, warum das so ist.
Dienstkonten sind keine Personen. Sie haben keine beruflichen Funktionen, keine Berichtswege und keine Richtlinien für den Datenzugriff, die an den Beschäftigungsstatus einer bestimmten Person gebunden sind. Sie werden nicht deaktiviert, wenn jemand das Unternehmen verlässt. Und wenn etwas schiefgeht – wenn ein Mitarbeiter auf Daten zugreift, auf die er keinen Zugriff haben sollte, oder eine Aktion ausführt, die niemand genehmigt hat –, führt der Prüfpfad zu einem Dienstkonto und nicht zu der Person, die diese Aktion veranlasst hat.
„Agent hat auf Datensatz X zugegriffen“ist keine nützliche forensische Information.„Der Agent handelte im Auftrag von Alice, die nur Lesezugriff auf diesen Datensatz hatte und diese Aktion nicht genehmigt hatte“ ist eine nützliche Information. Dieser Unterschied ist von enormer Bedeutung, wenn man einem Compliance-Team einen Vorfall erklären möchte.
Identitätsdiebstahl vs. Beauftragung
Es gibt zwei Modelle dafür, wie ein KI-Agent im Namen eines Nutzers handeln kann.
1. Identitätsbetrug
Unter Identitätsübernahme versteht man, dass der Agent buchstäblich die Identität des Benutzers annimmt. Anmeldedaten werden so weitergegeben oder delegiert, dass das Backend-System die Aktion als direkt vom Benutzer stammend wahrnimmt. Dies ist einfach zu implementieren. Außerdem verwischt es die Grenze zwischen menschlichen Handlungen und Handlungen des Agenten auf eine Weise, die sich im Nachhinein nur schwer aufklären lässt.
2. Delegation
Unter „Delegation“ versteht man, dass der Agent mit einer begrenzten, zeitlich befristeten Befugnisübertragung des Benutzers handelt. Das Backend-System weiß, dass ein Agent aktiv ist, weiß, welcher Benutzer ihn autorisiert hat, und weiß genau, wozu der Agent berechtigt war. Dies ist schwieriger zu implementieren, aber es ist das einzige Modell, das echte Nachvollziehbarkeit gewährleistet.
SnapLogic unterstützt die Delegierung über den Austausch und die Weitergabe von OAuth2-Tokens. Wenn ein Benutzer einen KI-Agenten über den MCP-Server auslöst, werden seine Identität und sein OAuth2-Token durch die gesamte Ausführungskette weitergeleitet.
Wenn die SnapLogic-Pipeline das Backend-System erreicht, enthält sie die Identität des ursprünglichen Benutzers und nicht die eines anonymen Dienstkontos.
Warum dies für die Compliance von Bedeutung ist
Die Identitätsweitergabe ist nicht nur ein technisches Detail. Für regulierte Branchen, Finanzdienstleister, das Gesundheitswesen und Behörden ist sie eine zwingende Compliance-Anforderung, wenn es um den Zugriff auf reale Daten geht. Und ohne diesen Zugriff ist ein KI-Agent nutzlos.
Die meisten Unternehmenssysteme wenden bereits Zugriffskontrollen auf der Grundlage der Benutzeridentität an. Zum Beispiel:
- Das CRM-System ermöglicht es nicht jedem Mitarbeiter, alle Kundendaten einzusehen
- Das ERP-System verfügt über rollenbasierte Berechtigungen, die seit Jahren sorgfältig gepflegt werden
- Das Data Warehouse verfügt über eine Sicherheit auf Spaltenebene, die an bestimmte Benutzerrollen gebunden ist
Wenn Sie ein generisches Dienstkonto über diese Systeme senden, finden diese Kontrollen keine Anwendung. Die Richtlinien sind zwar vorhanden, werden aber umgangen. Der Agent erhält die Zugriffsrechte des Dienstkontos, die oft weitaus umfangreicher sind als die eines einzelnen Benutzers.
Und nein, die Lösung besteht nicht darin, ein Konto mit eingeschränktem Zugriff zu verwenden, denn ohne Zugriff auf bestimmte Daten ist der Agent weitaus weniger nützlich und lässt sich nur auf allgemeine Anwendungsfälle mit geringer Wirkung beschränken.
Wenn Sie die Identität des Benutzers weitergeben, gelten alle bestehenden Zugriffsbeschränkungen automatisch. Der Agent kann genau das tun, was der Benutzer tun kann. Sie mussten Ihr Sicherheitsmodell für die KI nicht neu aufbauen. Sie müssen lediglich die richtige Identität durchgeben.
Der von SnapLogic implementierte Standard: RFC 9728
Der MCP-Server von SnapLogic implementiert RFC 9728, die OAuth 2.0-Spezifikation für geschützte Ressourcenmetadaten. Dabei handelt es sich um einen standardbasierten Ansatz für die Identitätsverwaltung und nicht um einen proprietären Mechanismus, der neue Sicherheitsanforderungen schafft oder Sie an einen Anbieter bindet.
Wenn sich ein KI-Agent mit einem SnapLogic MCP-Server verbindet, erkennt er die OAuth2-Konfiguration automatisch. Der Authentifizierungs-Handshake entspricht den geltenden Standards. Das Identitäts-Token wird mithilfe der SecurityContext-Weitergabe über die Datenebene von SnapLogic weitergeleitet – vom KI-Client über die Pipeline bis hin zum Backend.
Die Frage, die Sie sich zu Ihren aktuellen KI-Agenten stellen sollten
Wenn in Ihrem Unternehmen bereits KI-Agenten im Einsatz sind, fragen Sie sich: Unter welcher Identität greifen sie auf Backend-Systeme zu?
Wenn die Antwort „ein Dienstkonto“ lautet, haben Sie ein Identitätsproblem. Ihre Mitarbeiter agieren außerhalb des Identitäts- und Zugriffsmodells, das Sie über Jahre hinweg aufgebaut haben.
In Teil 3 werden wir uns damit befassen, was passiert, wenn Zugriff und Identitätsprüfung korrekt gehandhabt wurden: die Kontrolle. Genauer gesagt: Wie weisen Sie Ihrem Sicherheitsteam, Ihrem Compliance-Team und Ihren Prüfern nach, dass Ihre KI-Agenten genau das tun, was sie tun sollen, und nicht mehr?
Dies ist eine dreiteilige Serie zur Vorbereitung auf unsere bevorstehende virtuelle Diskussion mit dem Titel „Steuerung von KI-Agenten: Sicherer Zugriff, Identitätsmanagement und Kontrolle im Unternehmensmaßstab“.Seien Sie am 10. Juni in Ihrer Region dabei: Melden Sie sich für die EMEA-Übertragung oder die Nordamerika-Übertragungan. Wir freuen uns auf Sie!
