Was ist Agentenidentität – und warum Ihre KI wahrscheinlich keine hat?

Die meisten KI-Tools authentifizieren sich mithilfe der Anmeldeinformationen des menschlichen Bedieners. Das wird zu Compliance-Problemen führen. Hier erfahren Sie, wie eine korrekte Agentenidentität aussieht und warum dieser Unterschied jetzt wichtig ist.

Das Authentifizierungsproblem, über das niemand spricht

Wenn Ihr KI-Agent eine Aktion in Ihren Systemen ausführt, unter wessen Identität agiert er dann?

Bei den meisten KI-Tools liegt die Antwort heute bei Ihnen. Der Agent meldet sich mit den Zugangsdaten des menschlichen Bedieners an, übernimmt dessen Berechtigungen und arbeitet unter dessen Namen. Jeder Protokolleintrag, jeder gelesene Datensatz und jeder ausgeführte Befehl sieht so aus, als ob er vom Menschen selbst ausgeführt worden wäre.

Das Design ist einfach zu implementieren und leicht zu demonstrieren. Es fügt sich zudem nahtlos in Ihre bestehenden Zugriffskontrollsysteme ein. Und da bisher keine Probleme aufgetreten sind, ist den meisten Teams die dadurch entstehende Lücke nicht aufgefallen.

Das Problem mit der Weitergabe von Anmeldeinformationen liegt nicht in ihrer heutigen Unsicherheit, sondern in ihrer zukünftigen Nichtkonformität. KI-Systeme gehen von der reinen Beantwortung von Fragen zur eigenständigen Aktionsbereitstellung in Produktionssystemen über. In diesem Fall werden Prüfer und Aufsichtsbehörden eine Frage stellen, die mit geteilten Anmeldeinformationen nicht beantwortet werden kann: Hat ein Mensch oder die KI diese Aktion ausgeführt?

Was ist Agentenidentität in KI-Systemen?

Die Agentenidentität ist ein eindeutiges, überprüfbares und zeitlich begrenztes Attribut, das dem KI-Agenten selbst unabhängig vom Benutzer zugewiesen wird. Sie gibt dem Agenten in Ihren Systemen einen eigenen Namen, sodass Sie jede seiner Aktionen dem Agenten und nicht dem Bediener zuordnen können.

Eine korrekte Agentenidentität besteht aus drei Komponenten:

• Es verwendet eigene Anmeldeinformationen. Der Agent authentifiziert sich als er selbst. Er verwendet oder teilt niemals die Anmeldeinformationen des Benutzers.
• Beschränkte Autorisierung. Der Agent kann nur auf die für die jeweilige Aufgabe erforderlichen Daten zugreifen.
• Zeitlich begrenzt. Die Zugangsdaten verfallen mit dem Ende der Sitzung und können nicht wiederverwendet werden.

Wie sich die Agentenidentität von einem Dienstkonto unterscheidet

Agentenidentität und Dienstkonten lösen unterschiedliche Probleme. Ein Dienstkonto ist eine dauerhafte, gemeinsam genutzte Anmeldeinformation, die einer Funktion zugewiesen wird, beispielsweise einem geplanten Job oder einer Systemintegration. Es ist oft jahrelang gültig, sammelt im Laufe der Zeit Berechtigungen und dient mehreren Prozessen.

Die Agentenidentität ist aufgaben- und sitzungsbeschränkt. Sie wird für eine bestimmte Aufgabe ausgestellt, auf die dafür erforderlichen Berechtigungen beschränkt und nach Beendigung der Sitzung wieder freigegeben. Ersetzt man die Bedieneranmeldeinformationen durch ein allgemeines Dienstkonto, ändert sich nichts. Man tauscht lediglich eine gemeinsame Identität gegen eine andere.

Warum sollte ein KI-Agent nicht die Zugangsdaten des Bedieners verwenden?

Die Weitergabe von Benutzerdaten an einen KI-Agenten birgt drei Probleme: Zuordnungsfehler, Ausweitung des Anwendungsbereichs und eine wachsende Compliance-Lücke.

Zuordnungsfehler. Ein Prüfer untersucht eine Änderung an einem Produktionsauftrag und fragt, ob diese von einem Menschen oder der KI vorgenommen wurde. Wenn der Agent unter der Bediener-ID agierte, wird im Protokoll ein gemeinsamer Name für beide angezeigt. Es lässt sich nicht unterscheiden, was der Bediener entschieden hat und was der Agent eigenständig getan hat.

Ausweitung des Berechtigungsbereichs. Der Agent erbt die vollständigen Berechtigungen des Benutzers, nicht nur die für die jeweilige Aufgabe erforderlichen. Ein erfahrener Systemprogrammierer kann beispielsweise Rechte für Hunderte von Datensätzen, Sicherheitsdefinitionen und Jobplänen besitzen. Ein Agent, der unter dieser ID einen Batch-Fehler diagnostiziert, erhält all diese Rechte.

Compliance-Lücke. Regulierungsbehörden erwarten zunehmend, dass die Aktionen von KI-Agenten unabhängig nachvollziehbar und kontrolliert werden. Gemeinsam genutzte Anmeldeinformationen erfüllen diese Anforderung systembedingt nicht, unabhängig von der Stärke der Sicherheitsvorkehrungen.

Dieses Risiko wird leicht übersehen, weil gemeinsam genutzte Zugangsdaten so lange funktionieren, bis jemand einen Nachweis darüber verlangt, wer was getan hat. Diese Schwachstelle wird nicht bei einem Penetrationstest aufgedeckt, sondern erst bei einem Audit.

Was versteht man unter eingeschränkter Autorisierung für KI-Agenten?

Die eingeschränkte Autorisierung bedeutet, dass der Agent nur auf die für die jeweilige Aufgabe erforderlichen Ressourcen zugreifen und diese bearbeiten kann. Wenn die Aufgabe beispielsweise die Diagnose eines fehlgeschlagenen Batch-Jobs umfasst, erhält der Agent Lesezugriff auf die Protokolle, die Ausgabe und die zugehörigen Leistungsdaten dieses Jobs. Er hat jedoch keine Berechtigung, Sicherheitsdefinitionen zu ändern, nicht zugehörige Jobs abzubrechen oder Datensätze zu löschen.

Die meisten KI-Tools funktionieren heute anders. Der Agent erhält dieselben Zugriffsrechte wie der menschliche Bediener, unabhängig von den Anforderungen der jeweiligen Aufgabe. Dieser Ansatz ermöglicht jeder Agentensitzung einen maximal möglichen Wirkungsbereich.

Die eingeschränkte Autorisierung ist wichtig, da das Prinzip der minimalen Berechtigungen in regulierten Umgebungen bereits als Standard gilt. Das NIST AI Risk Management Framework geht davon aus, dass jede Identität nur die für ihre Aufgabe erforderlichen Zugriffsrechte besitzt, und die Zugriffskontrollen, die Ihre Prüfer kontrollieren, entsprechen demselben Standard. Menschliche Benutzer müssen diese Anforderung bereits erfüllen. KI-Agenten sollten dies ebenfalls tun, und die eingeschränkte Autorisierung ist der Weg dorthin.

Wie eine korrekte Agentenidentität in der Praxis aussieht

Stellen Sie sich folgendes typische Szenario vor: Ein nächtlicher Abrechnungsauftrag wird um 2:14 Uhr abgebrochen. Der diensthabende Mitarbeiter bittet einen KI-Agenten, den Fehler zu diagnostizieren.

Mit korrekter Agentenidentität:

• Der Agent authentifiziert sich mit eigenen, kurzlebigen Anmeldeinformationen, die von den Anmeldeinformationen des Bedieners getrennt sind.
• Der Zugriff beschränkt sich auf die relevanten Jobprotokolle, Systemmeldungen und Leistungsdaten.
• Jeder Lesevorgang und jede Empfehlung wird unter der Identität des Agenten protokolliert, wobei der Bediener als menschlicher Genehmiger vermerkt wird.
• Wenn der Agent eine Lösung vorschlägt, der Operator diese genehmigt, und das Protokoll erfasst beide Identitäten.
• Die Anmeldeinformationen verfallen mit dem Ende der Sitzung.

Mit gemeinsam genutzten Anmeldeinformationen:

• Der Agent meldet sich als Operator an und verfügt über die vollen Zugriffsrechte des Operators.
• Es kann weit über die Diagnose hinausgehen.
• Im Protokoll ist lediglich die Bediener-ID vermerkt. Drei Monate später, als ein Prüfer fragt, welche Schritte die KI und welche der Mensch unternommen hat, kann niemand eine Antwort geben.

Beide Vorgehensweisen könnten das Problem gleich schnell lösen. Nur eine von ihnen liefert eine Antwort, wenn jemand fragt, wie es dazu kam.

Das ist die Architektur Rocket^® EVA^™ Rocket EVA funktioniert so: Jedem Agenten wird eine eigene, kurzlebige und auf einen bestimmten Bereich beschränkte Berechtigung zugewiesen, die von der Identität des menschlichen Bedieners getrennt ist. Jede Aktion wird der Agentenidentität zugeordnet, und der menschliche Genehmiger wird protokolliert. Die Berechtigungen verfallen am Ende der Sitzung und können nicht wiederverwendet werden.

Rocket EVA setzt zudem operative Grenzen durch Richtlinien als Code durch und protokolliert Aktivitäten in einem unveränderlichen Audit-Trail. Es arbeitet mit Ihren bestehenden Identitäts- und Zugriffsmanagement-Kontrollen zusammen, sodass Sie die Governance stärken, ohne Ihr Sicherheitsmodell neu aufbauen zu müssen. Ihr Team erhält schnellere Diagnosen, und Ihr Compliance-Team erhält einen lückenlosen Nachweis, den es verteidigen kann.

Wie Sie beurteilen können, ob Ihr KI-Anbieter über eine echte Agentenidentität verfügt

Stellen Sie jedem KI-Anbieter diese vier Fragen:

1. Authentifiziert sich Ihr Agent mit seiner eigenen Identität oder mit den Anmeldeinformationen des Betreibers?
2. Ist diese Identität zeitlich begrenzt? Läuft sie nach Beendigung der Sitzung ab?
3. Ist die Autorisierung auf die Aufgabe beschränkt oder erbt der Agent die vollen Berechtigungen des Benutzers?
4. Können Sie einen Bericht erstellen, der die Handlungen des Agenten von denen des Menschen unterscheidet?

Achten Sie auf konkrete, architektonische Antworten. Ein Anbieter, der nicht alle vier Fragen konkret beantworten kann, verfügt nicht über eine Architektur für gesteuerte Agentenidentitäten.

Erfahren Sie, wie Rocket EVA die Agentenidentität handhabt.

Rocket ist eine Marke der Rocket Software, Inc. und ihrer Tochtergesellschaften.