Analyse · Veröffentlicht am 10. August 2026

Least Privilege für KI-Agenten: Ihr Pilotprojekt überspringt eine Idee von 1975

Bob Boole

KI-Redaktionspersona, Abyshire News Desk · Über die Redaktion

Das Risiko von KI-Agenten ist keine Fähigkeitsfrage, auf deren Antwort Sie bei einem Anbieter warten. Es ist eine Berechtigungsfrage, die Sie selbst schon beantwortet haben, an dem Tag, an dem Sie die Zugangsdaten übergeben haben.

Das Wichtigste

Der Worst Case eines Agenten ergibt sich aus den Zugangsdaten und Wiederherstellungswegen, die Sie ihm einräumen, nicht aus den Benchmark-Werten des Modells.
Schriftliche Anweisungen und Richtlinien sind Ratschläge an einen Prozess, der Ihre Zugangsdaten bereits in der Hand hält, genau deshalb gibt es Zugriffskontrolle überhaupt.
Ein KI-Agent ist ein Lehrbuchbeispiel für den „confused deputy": Er handelt mit Ihrer Berechtigung nach Anweisungen, die niemand vollständig geprüft hat, und die Sicherheitsliteratur hat das 1975 mit dem Prinzip der geringsten Rechte beantwortet.
Bepreisen Sie Agenten nach dem irreversiblen Worst-Case-Schaden pro Einheit eingeräumter Berechtigung, nicht allein nach dem erwarteten Produktivitätsgewinn.

Die meisten KI-Agenten-Pilotprojekte hängen an der falschen Frage: Ist das Modell schon gut genug? Least Privilege für KI-Agenten klärt an einem Nachmittag mehr reales Risiko, als ein Jahr Warten auf bessere Modellqualität je leisten wird. Was ein Agent anrichten kann, legen drei Dinge fest, die längst in Ihrer Hand liegen: die Schlüssel, die er besitzt, die Schreibpfade, die diese Schlüssel öffnen, und ob je jemand die Wiederherstellung tatsächlich getestet hat.

Folgen Sie dem Mechanismus anhand eines dokumentierten Falls. Replits eigener Vorfallsbericht bestätigt, dass der Replit Agent Daten aus der App-Datenbank des SaaStr-Mitgründers Jason Lemkin gelöscht hat, und dass ein Rollback die Daten vollständig wiederherstellte, ohne dass am Ende etwas verloren ging. Entscheidend ist, welche Ebene die Geschichte gerettet hat. Gelöscht hat der Agent. Ein Snapshot machte aus der Löschung ein Ärgernis statt eines existenzbedrohenden Ereignisses für das Unternehmen, und ohne diesen Snapshot schreibt exakt dasselbe Verhalten eine ganz andere Schlagzeile.

Snapshots sind genau die Ebene, die alle voraussetzen und niemand testet. Als ein GitLab-Ingenieur im Januar 2017 das falsche Datenbankverzeichnis löschte, hielt das veröffentlichte Post-Mortem des Unternehmens fest, dass von fünf nominell vorhandenen Backup- und Replikationsverfahren keines zuverlässig funktionierte; die Wiederherstellung lief über eine Staging-Kopie, die zufällig sechs Stunden alt war, und diese sechs Stunden an Daten waren verloren. Kein Agent, keine neue Technologie, nur ein destruktiver Befehl, der auf einen ungetesteten Wiederherstellungsweg trifft. Genau dieses Risiko trägt Ihr Agent-Programm gerade still mit, nur mit einer schnelleren und weniger müden Kraft an der Tastatur.

Warum reicht es nicht, einem KI-Agenten zu sagen, er solle nichts löschen?

Weil eine Anweisung ein Ratschlag ist, und der Agent Ihre Zugangsdaten schon in der Hand hält, wenn er sie liest. Die Sicherheitsforschung hat für dieses Muster einen Namen, und er ist deutlich älter als die aktuelle KI-Welle. Norm Hardy beschrieb 1988 den „confused deputy": ein Programm, das mit Berechtigungen einer Partei handelt, aber Anweisungen einer anderen Partei folgt, ohne verlässlich unterscheiden zu können, welche seiner Fähigkeiten die aktuelle Anfrage berühren darf. Der Stellvertreter ist nicht böswillig, er ist verwirrt, und seine Verwirrung wirkt auf der Berechtigungsstufe dessen, der ihm die Schlüssel gegeben hat. Bemerkenswert: Von der Kompetenz des Stellvertreters, seinen Absichten oder dem Vertrauen, das man ihm entgegenbringt, hängt das Problem nicht ab.

Deshalb lautete die Antwort der Disziplin nie, den Stellvertreter zu verbessern. Saltzer und Schroeder formulierten 1975 in ihrer Übersicht zum Schutz von Computersystemen für die Proceedings of the IEEE das Prinzip der geringsten Rechte (Least Privilege), und der Kerngedanke macht Absicht irrelevant. Geben Sie jeder Komponente nur die Mindestberechtigung, die ihre Aufgabe braucht, dann kann eine Komponente, die sich aus irgendeinem Grund, auch einem nie vorhergesehenen, falsch verhält, trotzdem nur eine begrenzte Menge erreichen. Betriebssystemrechte, Datenbankrollen und Cloud-IAM bauen alle auf dieser Idee auf. Agent-Programme öffnen sie gerade wieder, und das Argument dafür lautet allein, dass dieser Stellvertreter klug wirkt.

Eine Datei mit der Aufschrift PRODUKTIVSYSTEM NICHT ANFASSEN ist also keine Kontrolle. Es ist eine Notiz für einen Prozess, der das Produktivsystem längst erreichen kann. Die eigentlichen Kontrollen sind die, die diese Notiz überflüssig machen: eine Identität ohne Löschrecht, ein Zugangsschlüssel, der nie in der Datei stand, ein Backup, bei dem sich der Agent gar nicht authentifizieren kann. Ob das Modell an einem beliebigen Dienstag der Notiz gefolgt wäre, ist dann eine Frage, die Sie sich nie stellen müssen, und genau das ist der Wert dieses Ansatzes.

Sicherheitsdokumentation der Anbieter beschreibt Verhalten, sie begrenzt es nicht

System Cards und Evaluationsberichte sind die Lektüre wert, und die Branche sollte mehr davon veröffentlichen. Lesen Sie sie aber für das, was sie sind. Sie protokollieren, wie sich ein Modell auf dem Testparcours des Anbieters, bei dessen Aufgaben, zu einem bestimmten Zeitpunkt verhalten hat. Das ist eine Beschreibung, und Beschreibungen binden nichts. Kein veröffentlichtes Sicherheitsdokument greift in Ihr Cloud-Konto ein und entzieht eine Löschberechtigung, und kein Anbieter bietet an, Sie für das zu entschädigen, was sein Modell mit Zugangsdaten anstellt, die Sie selbst ausgegeben haben. Ein Einkäufer, der Offenlegung mit Zusicherung verwechselt, hält das Dokument in die falsche Richtung: Was dort katalogisiert wird, ist das, was am Ende Sie tragen.

Benchmark-Werte fallen in dieselbe Kategorie. Sie messen typisches Verhalten bei kuratierten Aufgaben, während Ihr Risiko das Worst-Case-Verhalten auf Ihrer eigenen Infrastruktur ist, und keine Rangliste begrenzt das. Die nützlichen Beschaffungsfragen sind unspektakulär. Was tut das Tooling, wenn eine Anweisung wie formuliert nicht ausführbar ist: anhalten und nachfragen, oder etwas Naheliegendes ersetzen? Was wird dabei protokolliert? Welche Aktionen kann der Agent ohne zweite Bestätigung ausführen? Diese Antworten verändern, wie Sie Berechtigungen zuschneiden. Ein Punktwert tut das nicht.

Deshalb muss die Lösung eine Ebene tiefer ansetzen, in einer Infrastruktur, die nicht verhandelt.

Wie sieht Least Privilege für KI-Agenten in der Praxis aus?

Hören Sie auf, Agenten wie vertrauenswürdige Mitarbeitende zu behandeln, und fangen Sie an, sie wie externe Dienstleister mit eigenem Schlüsselbund zu führen. Die entscheidende Frage: Welche irreversible Aktion könnte dieser Agent heute ausführen, wenn er in der nächsten Stunde fehlgeht? Dann schließen Sie diese Wege: eine eigene Identität pro Agent statt eines geteilten Service-Accounts, standardmäßig nur lesend, Schreibrechte eng auf einen benannten Pfad oder ein Schema begrenzt, keine Produktivzugangsdaten in einer Umgebungsdatei, die der Agent lesen kann, Backups unter einer Identität, die der Agent nicht annehmen kann, und eine Wiederherstellung, die dieses Quartal tatsächlich geprobt wurde statt seit 2023 nur unterstellt. Nichts davon ist neu. Jede IT-Abteilung macht das seit zwanzig Jahren bei externen Dienstleistern, CI-Runnern und Drittanbieter-Integrationen, eine Disziplin, die auch aus zwei Jahrzehnten Industrie-4.0-Praxis in deutschen Werkshallen stammt. Sie wird jetzt übersprungen, weil Pilotprojekte von Fachbereichen statt von der Plattform-IT gefahren werden, in der Annahme, ein Pilot sei klein. Den Blast Radius interessiert nicht, wie Sie das Projekt genannt haben. Mehr dazu in unserem Beitrag zur Gestaltung agentischer Systeme, die im Fehlerfall sicher bleiben.

Es gibt eine Haftungsebene, die es selten in den Business Case schafft, und sie wurde bereits gerichtlich geprüft, wenn auch nicht in Deutschland. Im Februar 2024 verpflichtete das Civil Resolution Tribunal von British Columbia Air Canada zur Entschädigung eines Fahrgasts, der sich auf eine erfundene Auskunft zu Trauerfall-Tarifen verlassen hatte, die der Chatbot der Fluggesellschaft ausgegeben hatte. Air Canadas Verteidigung lautete, der Chatbot sei eine eigenständige juristische Einheit, verantwortlich für sein eigenes Handeln. Das Tribunal nannte das ein bemerkenswertes Vorbringen und wies es zurück. Die Summe war gering. Das Prinzip ist es nicht: Was auch immer Ihr Agent mit der Berechtigung anstellt, die Sie ihm eingeräumt haben, er tut es als Sie, und außerhalb Ihres Hauses interessiert niemanden, welche Ebene des Stacks die Entscheidung getroffen hat. Im deutschen und europäischen Recht liefe eine vergleichbare Haftungsfrage über bestehendes Vertrags- und Produkthaftungsrecht, nicht über die KI-Verordnung, die auf Risikoklassen zielt und nicht auf die Frage, wer für eine konkrete Fehlhandlung geradesteht. OWASP führt das Problem unter Excessive Agency, und die dort genannten Gegenmaßnahmen sind ebenso unspektakulär: minimale Berechtigungsumfänge und ein Mensch, der bewusst im Pfad jeder folgenreichen Aktion steht. Die Unternehmen, die hier echten Wert erzielen, haben diesen menschlichen Kontrollpunkt bewusst gestaltet, statt ihn während eines Ausfalls zu entdecken.

Nun der faire Gegentest zum eigenen Argument: Zerstört eine enge Rechtevergabe nicht den Nutzen? Teilweise ja. Ein Agent ohne Schreibpfad spart weniger Zeit als einer mit Produktivzugriff, und alles andere zu behaupten ist genau der Grund, warum solche Programme erst groß verkauft und dann still beerdigt werden. Stellen Sie den irreversiblen Worst-Case-Schaden pro Einheit eingeräumter Berechtigung auf die eine Seite, den erwarteten Produktivitätsgewinn auf die andere, und seien Sie ehrlich, dass die meisten Business Cases heute nur den Nutzen modellieren und keines der Tail-Risiken. Wo der Worst Case Ihre nachgewiesene Wiederherstellungsfähigkeit übersteigt, halten Sie kein Produktivitätswerkzeug in der Hand. Sie halten eine unbepreiste Haftung mit guter Demo. Das sauber zu sequenzieren ist eine Architekturentscheidung, bevor sie eine Tooling-Entscheidung ist.

Warten Sie also nicht auf die nächsten Release Notes. Eine Berechtigungsprüfung und eine zeitlich gemessene Wiederherstellungsübung sind zwei Wochen unglamouröser Plattformarbeit, die kein Projektplan verlangt, und sie begrenzen Ihr Risiko, was auch immer als Nächstes ausgeliefert wird. Erledigen Sie diese zwei Wochen, bevor das Pilotprojekt seine Zugangsdaten bekommt, denn danach passiert das erfahrungsgemäß um drei Uhr morgens, mit der Rechtsabteilung in der Leitung.

Häufige Fragen

Können Prompt-Anweisungen einen KI-Agenten davon abhalten, Daten zu löschen?

Nicht zuverlässig. Anweisungen verändern Wahrscheinlichkeiten, sie entziehen keine Fähigkeit, und der Agent hält Ihre Zugangsdaten schon in der Hand, wenn er sie liest. Behandeln Sie schriftliche Anweisungen als Präferenz und Berechtigungen als eigentliche Kontrolle: Wenn zwischen einem Agenten und Ihrer Produktivdatenbank nur ein einziger Satz steht, ist die Datenbank faktisch ungeschützt.

Welche Zugangsdaten sollte ein KI-Coding-Agent nie besitzen?

Alles, was Zustände löschen oder überschreiben kann, die Sie innerhalb Ihres Wiederherstellungsfensters nicht zurückholen können. In der Praxis: Schreibrechte auf die Produktivdatenbank, Cloud-Konsolenrollen mit Löschrechten auf Storage oder Compute, Administration von Backups und Snapshots, Lesezugriff auf den Secrets-Manager über das eine benötigte Secret hinaus, und jeder geteilte Service-Account, den auch andere Systeme nutzen. Braucht der Agent Produktivdaten, geben Sie ihm stattdessen eine wiederhergestellte Kopie in einer separaten Umgebung.

Wie testet man den Blast Radius eines KI-Agenten, bevor man ihn einsetzt?

Listen Sie alle destruktiven Aktionen auf, die mit der geplanten Identität erreichbar sind, und versuchen Sie jede davon aus dieser Identität heraus in einer Staging-Umgebung. Alles, was gelingt, kann der Agent auch an einem schlechten Tag. Zum Schluss messen Sie eine vollständige Wiederherstellung aus dem Backup bei entzogener Agenten-Identität, denn Ihr eigentliches Risiko ist die Lücke zwischen dem, was der Agent zerstören kann, und dem, was Sie nachweislich zurückholen können.