Least Privilege für KI-Systeme: Nur notwendige Daten und Aktionen erlauben

Wer in kleinen und mittleren Unternehmen KI-Werkzeuge einführt, folgt fast immer dem Weg des geringsten Widerstands: Das Chat-Tool bekommt Zugriff auf das komplette Firmenlaufwerk, weil das schneller geht als eine engere Freigabe einzurichten. Der Automatisierungs-Agent nutzt das Konto der Person, die ihn eingerichtet hat, weil ein eigener Zugang zusätzliche Arbeit bedeutet. Das Ergebnis: Ein System, das für eine einzige Aufgabe gebaut wurde, kann plötzlich auf Kundendaten, Gehaltslisten oder Vertragsentwürfe zugreifen, die mit seiner eigentlichen Funktion nichts zu tun haben. Least Privilege ist die Gegenbewegung dazu – das Prinzip, jedem System, jedem Agenten und jedem Konto nur die Rechte zu geben, die es tatsächlich braucht, nicht mehr.

Direkt zur Kernfrage: Least Privilege bedeutet, dass ein KI-System ausschließlich die Daten und Aktionsrechte erhält, die für seine konkrete Aufgabe nötig sind – zeitlich befristet, dokumentiert und getrennt von den Rechten der Person, die es bedient. Ein Beispiel macht den Unterschied greifbar: Ein Agent, der Rechnungen aus E-Mails extrahiert, braucht Lesezugriff auf ein Postfach und Schreibzugriff auf eine Buchhaltungstabelle – nicht auf den gesamten Datenraum des Unternehmens, nur weil er unter dem Konto der Buchhaltungsleitung läuft. Das BSI und die französische Cybersicherheitsbehörde ANSSI nennen die „Begrenzung der Zugriffsrechte nach Bedarf” in ihren gemeinsamen Designprinzipien für LLM-Systeme entsprechend an erster Stelle.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die KI-Tools und -Agenten bereits einsetzen oder gerade einführen – meist ohne eigenes Sicherheitsteam, das Berechtigungskonzepte hauptberuflich pflegt. Er ist Teil unseres Themen-Clusters KI-Governance, das Datenschutz-, Sicherheits- und Richtlinienfragen rund um den KI-Einsatz im Unternehmen behandelt.

Das Problem: Warum KI-Systeme zu viele Rechte bekommen

Feinere Rollen machen mehr Arbeit – das ist der Kern des Problems, und er ist ehrlich benannt keine Ausrede, sondern eine reale Abwägung. Wer ein neues KI-Tool einrichtet, steht vor der Wahl: eine breite Freigabe in fünf Minuten oder eine engere Berechtigung, die erst Nachdenken über Ordnerstrukturen, Datenquellen und Aufgabengrenzen verlangt. Unter Zeitdruck gewinnt fast immer die breite Freigabe.

Bei klassischer Software ist dieses Risiko kalkulierbar, weil das Programm nur das tut, wofür es geschrieben wurde. Bei generativer KI ist das anders, aus drei Gründen:

• Der Aktionsradius ist unscharf. Ein Sprachmodell tut nicht nur, wofür es gedacht war, sondern das, worum es gebeten wird oder was ein manipulierter Prompt ihm vorgibt. Ein Agent mit Schreibrechten auf ein System kann diese Rechte auch dann nutzen, wenn eine Anfrage von außen (etwa in einem verarbeiteten Dokument) versucht, ihn dazu zu bringen.
• Rechte werden vererbt statt vergeben. Viele KI-Integrationen laufen technisch unter dem Konto der Person, die sie eingerichtet hat, oder unter einem generischen Servicekonto mit weitreichenden Rechten – nicht unter einer eigenen, engen Identität.
• Das Sprachmodell selbst kennt keine Zugriffsrechte. Die Datenschutzkonferenz stellt in ihrer Orientierungshilfe zu RAG-Systemen klar: Technische Schutzmaßnahmen wie Rollen- und Rechtekonzepte lassen sich im Subsystem umsetzen, das Daten an das Modell liefert – im Sprachmodell selbst gibt es keine Möglichkeit, Zugriffsrechte zu steuern. Wer einem Modell einmal Zugriff auf einen Datensatz gegeben hat, kann nicht darauf vertrauen, dass es diesen Zugriff situationsabhängig verweigert.

Für KMU heißt das: Die Verantwortung für Zugriffsbegrenzung liegt vollständig auf der Systemebene davor – bei der Auswahl der Datenquellen, der Konfiguration der Schnittstellen und der Kontenverwaltung. Genau dort setzt Least Privilege an.

Begriffe kurz geklärt

• Least Privilege (Prinzip der geringsten Berechtigung) ist laut BSI IT-Grundschutz-Kompendium der Grundsatz, dass Benutzerkennungen und Berechtigungen nur aufgrund des tatsächlichen Bedarfs und der Notwendigkeit zur Aufgabenerfüllung vergeben werden dürfen.
• Agent ist in diesem Artikel ein KI-System, das eigenständig Aktionen ausführt – Daten abrufen, Inhalte erstellen, in andere Systeme schreiben –, nicht nur Text ausgibt wie ein reiner Chat-Assistent.
• Service Account ist ein technisches Konto, über das ein System oder eine Automatisierung auf andere Systeme zugreift, ohne dass eine Person interaktiv angemeldet ist.
• Non-Human Identity (nichtmenschliche Identität) ist der Oberbegriff für Agenten, Service Accounts und ähnliche technische Akteure, die eine eigene Identität, eigene Berechtigungen und einen eigenen potenziellen Schaden verursachen können – unabhängig von der Person, die sie ursprünglich eingerichtet hat.

Wichtig ist die Abgrenzung: Least Privilege ist kein Ersatz für eine KI-Nutzungsrichtlinie, sondern deren technische Umsetzung an der Zugriffsschicht. Eine Richtlinie legt fest, was erlaubt ist; Least Privilege sorgt dafür, dass technisch auch nur das möglich ist.

Was bedeutet Least Privilege für KI-Systeme?

Bei klassischen IT-Konten ist Least Privilege etabliert: eine Vertriebsmitarbeiterin bekommt Zugriff auf das CRM, nicht auf die Personalakten. Bei KI-Systemen kommen zwei Besonderheiten hinzu, die das Prinzip komplizierter, aber nicht weniger notwendig machen.

Erstens die Aufgabenbindung statt Rollenbindung: Ein menschliches Konto bekommt Rechte passend zur Stellenbeschreibung, die sich selten ändert. Ein KI-Agent sollte Rechte passend zur einzelnen Aufgabe bekommen, die sich häufig ändert – ein Agent, der heute Support-Anfragen kategorisiert, sollte morgen nicht automatisch auch Rechnungen verarbeiten dürfen, nur weil er technisch dieselbe Grundausstattung hat.

Zweitens die Kombination aus Daten- und Aktionsrechten: Bei klassischer Software trennt man meist nur Lesen und Schreiben. Bei KI-Agenten kommt eine dritte Dimension dazu – welche Aktionen darf das System selbstständig ausführen, und welche erfordern eine Bestätigung durch einen Menschen? Ein Agent mit Leserechten auf Kundendaten und der Fähigkeit, E-Mails zu versenden, kann ohne Prüfschritt erheblichen Schaden anrichten, selbst wenn er nirgends etwas verändert.

Die folgende Matrix zeigt, wie sich das für die drei typischen Kontotypen in einem KMU unterscheidet – als eigene Einordnung, keine Kopie aus einer der zitierten Quellen:

Kontotyp	Typischer Zugriff heute	Least-Privilege-Zielzustand	Größtes Risiko bei Fehlkonfiguration
Mitarbeiterkonto mit KI-Tool	Zugriff wie ohne KI-Tool, plus Upload-Möglichkeit in externe Dienste	Klare Freigabeliste, welche Datenkategorien in welches Tool dürfen	Schatten-KI: Upload sensibler Daten in ungeprüfte Dienste
Agent / Automatisierung	Läuft unter dem Konto der einrichtenden Person oder unter einem generischen Servicekonto	Eigene Identität mit Rechten exakt für die eine Aufgabe, zeitlich befristet	Rechteausweitung durch manipulierte Eingaben (Prompt Injection)
Service Account (Systemanbindung)	Weitreichender API-Zugriff „damit alles funktioniert”	Geltungsbereich auf konkrete Datenquelle/Endpunkt begrenzt, ohne interaktives Login	Kompromittierung wirkt sich auf alle angebundenen Systeme aus, nicht nur auf ein Postfach

Eigene Einordnung Philogic Labs, abgeleitet aus Beratungspraxis und den zitierten BSI-/DSK-Grundlagen.

Wie trennt man Nutzer, Agent und Service Account?

Der häufigste Fehler in der Praxis: Ein Agent oder eine Automatisierung läuft „unter” der Person, die ihn konfiguriert hat. Das ist bequem in der Einrichtung und riskant im Betrieb, weil drei Probleme entstehen. Der Agent erbt alle Rechte der Person, auch die, die er nie braucht. Bei einem Personalwechsel hängt die Automatisierung an einem Konto, das eigentlich deaktiviert werden müsste. Und im Protokoll lässt sich nicht mehr unterscheiden, ob eine Aktion von der Person oder vom System ausgeführt wurde.

Sauberer ist eine Drei-Ebenen-Trennung, die sich mit vertretbarem Aufwand auch ohne eigenes IAM-System (Identity- und Access-Management) einrichten lässt:

1. Nutzerkonto – die Person, die ein KI-Tool bedient (etwa im Chat-Interface). Rechte richten sich nach ihrer Funktion, wie bei jedem anderen Software-Zugang auch.
2. Agentenidentität – eine eigene, benannte Kennung für jeden eigenständig handelnden Agenten, getrennt von der Person, die ihn eingerichtet hat. Idealerweise trägt der Name die Funktion: „Agent-Rechnungsextraktion”, nicht „Service1”.
3. Service Account – die technische Anbindung an dahinterliegende Systeme (E-Mail-Postfach, Datenbank, CRM-API), auf die die Agentenidentität zugreift. Ein Service Account sollte nur die Endpunkte und Operationen freigeben, die die konkrete Aufgabe braucht – lesend, wo Schreiben nicht nötig ist.

Diese Trennung macht drei Dinge möglich, die mit einer gemeinsamen Identität nicht gehen: Rechte für den Agenten unabhängig vom Nutzerkonto anpassen, den Agenten deaktivieren, ohne das Nutzerkonto zu berühren, und im Protokoll klar erkennen, wer oder was gehandelt hat. Für Unternehmen ohne eigenes IAM-Team reicht dafür oft schon eine saubere Namenskonvention plus getrennte API-Schlüssel oder App-Passwörter pro Agent – ein vollständiges Identitätsmanagement-System ist für den Einstieg nicht nötig, wird aber bei wachsender Zahl von Agenten irgendwann sinnvoll.

Wie begrenzt man den Datenzugriff?

Die Datenschutzkonferenz benennt in ihrer Orientierungshilfe zu RAG-Systemen die drei wichtigsten technischen Stellschrauben: Mandantentrennung, Rechte- und Rollenkonzepte sowie Zugriffsbeschränkungen auf die zugrundeliegende Datenquelle – etwa eine Vektordatenbank bei RAG-Systemen, aber ebenso ein Dateisystem, ein Postfach oder eine Kundendatenbank bei anderen KI-Anwendungen.

Praktisch heißt das für ein KMU:

• Ordner- statt Laufwerksfreigabe. Ein KI-Tool, das Verträge zusammenfassen soll, bekommt Zugriff auf den Vertragsordner, nicht auf das gesamte Firmenlaufwerk. Das begrenzt Schaden bei Fehlkonfiguration und bei kompromittierten Zugängen gleichermaßen.
• Feldbasierte Begrenzung bei strukturierten Daten. Ein Agent, der Support-Tickets kategorisiert, braucht selten Zugriff auf Zahlungsdaten im selben Datensatz – wo das technisch möglich ist, sollten nur die relevanten Felder freigegeben werden.
• Getrennte Wissensquellen pro Anwendungsfall statt einer zentralen „KI-Datenbank für alles”. Wer alle Unternehmensdaten in eine gemeinsame durchsuchbare Quelle für alle KI-Anwendungen packt, hebt die Zugriffsbegrenzung faktisch wieder auf, egal wie fein die einzelnen Tool-Berechtigungen sind.
• Kein Zugriff auf besonders sensible Kategorien ohne gesonderte Prüfung. Gesundheitsdaten, Gehaltsdaten oder Bewerbungsunterlagen gehören nicht in den Standard-Datenzugriff eines KI-Tools, sondern brauchen eine eigene, bewusste Entscheidung – auch wegen möglicher Pflichten aus dem EU AI Act bei Systemen, die Entscheidungen über Menschen vorbereiten.

Der wichtigste Grundsatz dahinter: Datenbegrenzung passiert vor dem Modell, nicht im Modell. Wie oben zitiert, kann ein Sprachmodell selbst keine Zugriffsrechte durchsetzen – wer ihm einmal Zugriff auf einen Datenbestand gibt, muss davon ausgehen, dass es diese Daten in seinen Antworten grundsätzlich verwenden kann. Die Kontrolle muss deshalb auf der Ebene der Datenquelle und der Schnittstelle ansetzen, die dem Modell vorgelagert ist.

Wie prüft man Rechte regelmäßig?

Ein Berechtigungskonzept, das einmal eingerichtet und nie wieder geprüft wird, veraltet zuverlässig. Der BSI-Grundschutz-Baustein ORP.4 verlangt dafür ein geregeltes Verfahren zur Einrichtung, Änderung und zum Entzug von Berechtigungen – kein einmaliges Projekt, sondern einen laufenden Prozess.

Für KI-Systeme sind drei Prüfpunkte besonders wichtig, weil sich Agenten und ihre Aufgaben schneller ändern als klassische Rollen:

1. Wer hat Zugriff, und passt das noch zur aktuellen Aufgabe? Ein Agent, der ursprünglich für ein Pilotprojekt breite Rechte bekam, behält diese oft auch nach dem Piloten – die Rechte müssten mit dem Ende des Pilotprojekts überprüft werden.
2. Werden alle vergebenen Rechte tatsächlich genutzt? Eine ungenutzte Berechtigung ist reines Risiko ohne Nutzen. Wo technisch möglich, helfen Protokolle der tatsächlichen Zugriffe, um „auf Vorrat” vergebene Rechte zu erkennen.
3. Gibt es eine feste Zuständigkeit für die Prüfung? Ohne benannte Person verläuft jede gute Absicht im Sande. Für KMU reicht dafür meist eine feste Aufgabe im IT- oder Datenschutz-Zuständigkeitsbereich, mit einem wiederkehrenden Termin – vierteljährlich ist ein praktikabler Rhythmus für die meisten Fälle, ohne dass diese Zahl aus einer der zitierten Quellen stammt; sie ist eine Erfahrungsempfehlung aus der Beratungspraxis, keine Vorgabe.

In meiner Arbeit sehe ich häufig, dass Unternehmen die Ersteinrichtung eines KI-Tools sorgfältig machen, aber keinen Termin für die Nachprüfung setzen. Die Konsequenz zeigt sich meist erst Monate später, wenn niemand mehr genau weiß, warum ein bestimmter Agent Zugriff auf eine bestimmte Datenquelle hat.

Wie widerruft man Zugriffe im Notfall?

Der Ernstfall – ein kompromittiertes Konto, ein Agent, der fehlerhaft handelt, ein Tool, das unerwartet Daten abgreift – ist der denkbar schlechteste Zeitpunkt, um zum ersten Mal über Widerrufsprozesse nachzudenken. Ein vorbereiteter Prozess braucht vier Elemente:

• Sofortiger Zugriffsentzug statt Konfigurationsänderung. Im Notfall zählt Geschwindigkeit: Zugang deaktivieren oder Schlüssel widerrufen, nicht erst Rechte im Detail neu justieren. Feinjustierung kommt danach.
• Bekannte Liste aller aktiven Agenten- und Service-Account-Zugänge. Ohne aktuelle Übersicht lässt sich im Ernstfall nicht schnell entscheiden, was abzuschalten ist. Genau deshalb lohnt sich ein einfaches, gepflegtes Verzeichnis aller KI-Zugänge – wie es auch als eigenes Thema in diesem Cluster behandelt wird.
• Getrennte Widerrufbarkeit pro Identität. Wenn Nutzer-, Agenten- und Service-Konten sauber getrennt sind (siehe oben), lässt sich im Notfall genau ein betroffener Zugang sperren, ohne den gesamten Betrieb lahmzulegen.
• Nachgelagerte Analyse statt vorschneller Entwarnung. Nach dem Sperren: Protokolle sichern, betroffene Daten und Aktionen rekonstruieren, klären, ob eine Meldepflicht nach DSGVO besteht. Das ist im Einzelfall eine rechtliche Einschätzung – bei Unsicherheit gehört sie zu Datenschutzbeauftragten oder Rechtsberatung, nicht in eine allgemeine Handlungsanweisung.

Ein geübter, kurzer Prozess schlägt ein perfektes, aber ungetestetes Dokument. Es reicht, den Ablauf einmal im Team durchzusprechen und aufzuschreiben, wer im Ernstfall was tut.

Umsetzung: Vorgehen in der Praxis

Least Privilege lässt sich nicht an einem Tag flächendeckend einführen, aber mit einem klaren Startpunkt und einer Reihenfolge, die zu KMU-Ressourcen passt:

Schritt 1 – Bestandsaufnahme. Welche KI-Tools, Agenten und Automatisierungen sind aktuell im Einsatz, unter welchem Konto laufen sie, worauf haben sie Zugriff? Diese Liste existiert in den meisten KMU noch nicht vollständig – ihr Fehlen ist selbst ein Risikosignal.

Schritt 2 – Priorisierung nach Risiko. Nicht jedes Tool braucht sofort eine Überarbeitung. Priorität haben Systeme mit Zugriff auf personenbezogene Daten, Zahlungsdaten oder Geschäftsgeheimnisse sowie Systeme mit eigenständiger Schreib- oder Sendefähigkeit.

Schritt 3 – Rechte neu zuschneiden, nicht nur dokumentieren. Für die priorisierten Systeme: bestehende Freigaben auf das tatsächlich Nötige reduzieren, eigene Identitäten für Agenten einrichten, wo bisher Konten geteilt wurden.

Schritt 4 – Prüf- und Widerrufsprozess festlegen. Zuständigkeit benennen, Prüfrhythmus festlegen, Notfallablauf einmal durchspielen.

Schritt 5 – Neue Tools von Anfang an eng zuschneiden. Der wirksamste Hebel ist, bei jedem neuen KI-Werkzeug die enge Berechtigung von Beginn an einzurichten, statt sie nachträglich einzuschränken – nachträgliches Verengen ist immer aufwändiger und stößt auf mehr Widerstand, weil sich Arbeitsabläufe bereits an die breite Freigabe gewöhnt haben.

Für die Zeit- und Aufwandsplanung gilt wie bei jeder Sicherheitsmaßnahme: Der Aufwand hängt stark von der Zahl bereits eingesetzter Tools und der vorhandenen IT-Struktur ab. Eine grobe Bandbreite aus meiner Beratungspraxis: Die Bestandsaufnahme für ein KMU mit einer Handvoll KI-Tools lässt sich meist in wenigen Tagen erstellen; die Neuzuschneidung der Rechte dauert je nach Zahl der Systeme und Komplexität der bestehenden IT-Landschaft eher Wochen als Tage. Verlässliche Zahlen dafür gibt es nicht allgemeingültig – sie hängen zu stark vom Einzelfall ab, um sie seriös zu verallgemeinern.

Risiken & Grenzen

Least Privilege ist kein Freibrief für Sorglosigkeit und löst nicht jedes Problem:

• Es schützt nicht vor Fehlern innerhalb der erlaubten Rechte. Ein Agent mit eng zugeschnittenen, aber fehlerhaft konfigurierten Rechten kann innerhalb dieses engen Rahmens trotzdem Schaden anrichten. Least Privilege begrenzt den Radius, ersetzt aber keine inhaltliche Prüfung der Ausgaben.
• Zu enge Rechte behindern die Funktion. Wird ein Agent so eng beschnitten, dass er seine Aufgabe nicht mehr erfüllen kann, wird die Berechtigung oft ad hoc und undokumentiert erweitert – häufig wieder zu breit. Das Ziel ist die passende, nicht die minimal mögliche Berechtigung.
• Es macht keine Aussage zur Rechtmäßigkeit der Verarbeitung. Ein technisch sauber zugeschnittenes Zugriffsrecht beantwortet nicht die Frage, ob die Datenverarbeitung selbst datenschutzrechtlich zulässig ist. Diese Prüfung bleibt unabhängig davon nötig.
• Ohne Pflege verfällt jedes Konzept. Wie oben beschrieben, ist die regelmäßige Prüfung kein optionaler Zusatz, sondern Teil des Prinzips selbst.
• Rechtlicher Stand Juli 2026. Dieser Artikel ersetzt keine Rechtsberatung. Für verbindliche Einschätzungen zu DSGVO- oder EU-AI-Act-Pflichten im konkreten Fall sind Datenschutzbeauftragte oder Rechtsberatung die richtige Anlaufstelle; die zitierten Dokumente von BSI und Datenschutzkonferenz sind ein guter Ausgangspunkt für die technische und organisatorische Einordnung.

Checkliste: Least Privilege für KI-Systeme

1. Es gibt eine aktuelle Liste aller eingesetzten KI-Tools, Agenten und Service Accounts mit ihren jeweiligen Zugriffsrechten.
2. Nutzerkonto, Agentenidentität und Service Account sind für relevante Systeme technisch getrennt, nicht über ein gemeinsames Konto verknüpft.
3. Jedes KI-System hat Zugriff auf Ordner-, Feld- oder Datenbankebene zugeschnitten – nicht auf das gesamte Laufwerk oder Postfach.
4. Besonders sensible Datenkategorien (Gesundheits-, Gehalts-, Bewerbungsdaten) sind vom Standardzugriff ausgenommen und wurden gesondert geprüft.
5. Es gibt eine benannte Zuständigkeit und einen festen Rhythmus für die Rechteprüfung.
6. Ungenutzte oder nicht mehr passende Rechte werden bei der Prüfung tatsächlich entzogen, nicht nur dokumentiert.
7. Ein Notfallprozess für den sofortigen Zugriffsentzug ist aufgeschrieben und mindestens einmal im Team durchgesprochen.
8. Neue KI-Tools werden von Anfang an mit eng zugeschnittenen Rechten eingerichtet, nicht nachträglich eingeschränkt.
9. Zugriffsentscheidungen bei rechtlich sensiblen Fällen sind mit Datenschutzbeauftragten oder Rechtsberatung abgestimmt, nicht allein technisch entschieden.

Wer diese neun Punkte noch nicht vollständig abhaken kann, ist damit nicht allein – die meisten KMU stehen genau hier. Wenn du deine aktuelle KI-Nutzung und die bestehenden Zugriffsrechte strukturiert erfassen und priorisieren lassen willst: Unser Beratungsangebot dazu findest du auf der Startseite, ein kostenloses Erstgespräch klärt, wo die größten Lücken liegen. Für den Kompetenzaufbau im Team rund um KI-Risiken und Berechtigungen bieten sich zudem gezielte Schulungen an.