KI-Agents sollten Benutzerberechtigungen übernehmen, statt eigene Zugangsdaten zu besitzen

Jede neue Integration wirft dieselbe Sicherheitsfrage auf: Worauf kann sie zugreifen, was einem Menschen verwehrt bleibt? Bei KI-Agents hängt die Antwort von einer zentralen Designentscheidung ab. Entweder besitzt der Agent eigene Zugangsdaten, oder er agiert mit den Berechtigungen der anfragenden Person.

Diese Entscheidung bestimmt die Größe der Angriffsfläche. Ein gemeinsam genutztes Servicekonto mit weitreichenden Rechten schafft eine privilegierte Identität, die niemand wie eine Person überprüft – und die auf Daten zugreifen kann, die kein einzelner Anwender sehen sollte. Die Vererbung von Berechtigungen verhindert dieses Problem von Anfang an.

Dieser Artikel erläutert, warum dauerhafte Agent-Zugangsdaten ein Risiko darstellen, wie Berechtigungsvererbung in der Praxis funktioniert und welche Fragen Sie bei der Sicherheitsprüfung einer Agent-Plattform stellen sollten.

Executive Summary

KI-Agents sollten stets im Auftrag des anfragenden Anwenders agieren. Wenn ein Agent die Rollen und Berechtigungen einer Person übernimmt, kann er nicht mehr sehen oder tun als diese Person. Die Plattform prüft Richtlinien bei jeder Anfrage, und der Audit-Trail weist jede Aktion einer namentlich bekannten Person zu. Agents mit eigenen, weitreichenden Zugangsdaten bewirken das Gegenteil: Sie vergrößern die Angriffsfläche und lösen die Verbindung zwischen Aktion und verantwortlichem Anwender auf. Für CISOs und Security-Architekten wird die Überprüfung durch Vererbung zu einer Frage des Zugriffsmodells der Plattform – nicht des Codes jedes einzelnen Agents.

wichtige Erkenntnisse

1. Dauerhafte Agent-Zugangsdaten schaffen eine neue privilegierte Identität. Ein Servicekonto mit umfassenden Berechtigungen kann auf Daten zugreifen, die für keinen einzelnen Anwender bestimmt sind.
2. Vererbung hält die Angriffsfläche konstant. Ein Agent, der mit den Rollen und Berechtigungen des Anwenders agiert, kann keine Ressourcen außerhalb dieser Autorisierung erreichen.
3. Richtlinien sollten bei jeder Anfrage geprüft werden. Attributbasierte Entscheidungen, die Klassifizierung, Anwenderattribute und Kontext berücksichtigen, lassen die Kontrolle bei der Plattform – nicht beim Agent.
4. Definierter Tool Scope macht aus der Sicherheitsprüfung eine Dokumentenprüfung. Gibt ein Agent vor der Installation an, was er tun kann, prüfen Reviewer eine Spezifikation statt den Code zu auditieren.
5. Administratoren brauchen einen zentralen Schalter. Zerstörerische Tools bleiben deaktiviert, bis sie explizit freigeschaltet werden. Die Liste der verfügbaren Tools lässt sich einschränken – so bleibt das Agent-Verhalten im Rahmen der vom Unternehmen genehmigten Aktionen.

Warum dauerhafte Agent-Zugangsdaten Risiken schaffen

Integrationsabkürzungen laufen oft nach demselben Muster ab: Jemand legt ein Servicekonto an, gibt ihm ausreichend Rechte für das Projekt und macht weiter. Das Konto bleibt jahrelang bestehen und sammelt Zugriffsrechte an, die niemand regelmäßig gegen die Rolle einer Person prüft.

Eine privilegierte Identität ohne Überprüfung

Anwender wechseln die Rolle, verlassen das Unternehmen oder verlieren Zugriffsrechte. Ein Servicekonto tut das nicht. Wenn ein Agent ein solches Konto nutzt, spiegelt sein Zugriff den Stand bei der Einrichtung wider – nicht den aktuellen Bedarf der anfragenden Person.

Aktionen ohne verantwortlichen Anwender

Handelt der Agent in eigenem Namen, zeigt das Protokoll den Agent – nicht die Person, die die Aktion ausgelöst hat, oder ob diese überhaupt Zugriff auf die Daten haben durfte. Für Ermittler oder Auditoren entsteht so eine Lücke in der Verantwortlichkeitskette.

Wie Berechtigungsvererbung für KI-Agents funktioniert

Bei der Vererbung übernimmt eine KI-Aktion die Rollen und Berechtigungen des authentifizierten Anwenders. Die Plattform prüft attributbasierte Richtlinien in Echtzeit für jede Anfrage – unter Einbeziehung von Dateiklassifizierung, Sensitivitätslabels, Anwenderattributen und Kontext. Kann der Anwender eine Datei nicht direkt öffnen, kann der Agent es auch nicht.

Definierter Tool Scope

Jeder Agent deklariert im Vorfeld, welche Tools er nutzt. Reviewer gleichen diese Angaben vor der Installation mit ihren Anforderungen ab. Tool-Aufrufe werden zudem gegen die dem Client gewährten Scopes geprüft – ein Agent kann also nur die Tools nutzen, für die er freigegeben wurde.

Zentrale Kontrolle für Administratoren

Zerstörerische Tools wie Verschieben oder Löschen sind standardmäßig deaktiviert und müssen explizit freigeschaltet werden. Administratoren können zudem festlegen, welche Tools für Agents registriert werden dürfen, und Bestätigungsschritte vor Schreibaktionen einbauen. Diese Kontrollen ermöglichen es dem Security-Team, den Handlungsspielraum von Agents vor der Installation festzulegen.

Fragen an jede Agent-Plattform

Fragen Sie, mit wessen Berechtigungen ein Agent agiert und ob es eigene Zugangsdaten gibt. Fragen Sie, wo Richtlinien geprüft werden und ob Sicherheitstokens oder Dateidaten ohne Anwenderaktion in den Kontext des Modells gelangen. Fragen Sie, wie jeder Aufruf im Audit-Log erscheint und ob er Ihr SIEM erreicht. Eine Plattform, die diese Fragen präzise beantwortet, beschleunigt die Prüfung. Eine Plattform, die stattdessen das „gute Verhalten“ des Assistenten beschreibt, hat nicht geantwortet.

Warum der Enforcement Point entscheidend ist

Ein Assistent kann durch ein böswilliges Dokument oder Prompt manipuliert werden. Kontrollen, die auf das Wohlverhalten des Assistenten setzen, versagen in diesem Moment. Kontrollen am Connector – wie das Fernhalten von Tokens und Dateidaten vom Kontext, außer wenn der Anwender eine Datei bewusst einliest – bleiben hingegen wirksam.

Durchsetzung der Vererbung auf der Kiteworks Data Control Plane

Posture-Tools zeigen, wo sensible Daten liegen, und IAM regelt, wer sich anmelden darf. Doch keine dieser Lösungen steuert, was ein Agent tut, sobald er im Auftrag eines Anwenders agiert. Die Kiteworks Data Control Plane setzt in diesem Moment Identität, Berechtigungen und datenbasierte Richtlinien durch. Das Audit-Log ist manipulationssicher und kann Ihr SIEM-Tooling speisen. Der Kiteworks Agent Marketplace zeigt dieses Modell in der Praxis – mit Agents, die als anfragender Anwender innerhalb von Kiteworks agieren.

Die Data Control Plane arbeitet parallel zu Ihrem IAM, DSPM und DLP – diese behalten ihre Aufgaben. Wenn Sie das Zugriffsmodell gemeinsam mit Ihren Security-Architekten prüfen möchten, vereinbaren Sie eine individuelle Demo. Wir führen Sie Schritt für Schritt durch die Kontrollen.