Berechtigungen für KI-Agenten: Least Privilege und Rollen

Das Wichtigste in Kürze:

• Jeder KI-Agent braucht eine eigene technische Identität, kein menschliches Konto.
• Least Privilege heißt: nur die Rechte, die die konkrete Aufgabe wirklich braucht.
• Lese- und Schreibrechte trennen, kritische Aktionen an eine menschliche Freigabe koppeln.
• Secrets in eine dedizierte Verwaltung legen, Rechte dokumentieren und entziehbar halten.

Ein KI-Agent, der E-Mails liest, Termine bucht oder Daten in ein CRM schreibt, braucht technischen Zugriff. Auf Postfächer, Kalender, Datenbanken, manchmal auf ganze Systemlandschaften. Die Frage, die in Projekten fast immer zu kurz kommt, lautet nicht „Funktioniert der Agent?“. Sie lautet: Was darf er eigentlich, und was passiert, wenn das schiefgeht?

In der Praxis sehe ich immer wieder dasselbe Muster. Ein Agent bekommt beim Aufsetzen den API-Schlüssel eines bestehenden Admin-Kontos, weil das am schnellsten geht. Diese Rechte behält er dann, weit über die eigentliche Aufgabe hinaus, oft dauerhaft.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die KI-Agenten produktiv einsetzen wollen oder schon einsetzen. Er beantwortet die 5 Kernfragen der Rechtevergabe:

• Welche Identität nutzt ein Agent?
• Was bedeutet Least Privilege konkret?
• Wie trennt man Lesen und Schreiben?
• Wie schützt man Zugangsdaten?
• Wie widerruft man Rechte wieder?

Dazu kommen eine eigene Risikomatrix mit Gegenmaßnahmen und eine Checkliste zum Abhaken.

Das Problem: Rechte aus Bequemlichkeit

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) benennt den Mechanismus präzise. Unerwünschte oder unautorisierte Aktionen entstehen dann, wenn eine LLM-basierte Anwendung „entsprechende Aktions- und Zugriffsmöglichkeiten hat und autonom basierend auf den Ausgaben des zugrundliegenden LLMs handeln kann“. Das Modell selbst muss dafür nicht einmal fehlerhaft sein. Es reicht, dass es zu breite Rechte ausnutzen kann, etwa durch eine missverstandene Anweisung oder eine manipulierte Eingabe (Prompt Injection). Das BSI empfiehlt deshalb in Maßnahme M17, die Zugriffs- und Ausführungsrechte solcher Anwendungen „auf das notwendige Minimum“ zu beschränken. Dazu gehören klare Vertrauensgrenzen zwischen Modell, Anwendung, externen Ressourcen und erweiterten Funktionen.

In der Umsetzung passiert oft das Gegenteil. Ein Agent soll 3 Support-Tickets pro Tag kategorisieren. Dafür bekommt er Zugriff auf das komplette Ticketsystem inklusive Kundendaten, weil die verfügbare Integration nur „alles oder nichts“ anbietet. Ein Workflow-Agent soll Rechnungen in ein Tool schreiben. Er läuft über das persönliche Konto der Buchhaltung, weil ein eigener technischer Zugang zunächst wie unnötiger Mehraufwand wirkt.

Beides funktioniert im Testbetrieb einwandfrei. Das Risiko zeigt sich erst, wenn etwas schiefgeht: eine fehlerhafte Ausgabe, eine kompromittierte Verbindung, eine Aktion, die niemand angestoßen hat.

Begriffe kurz geklärt

5 Begriffe reichen für den Einstieg.

• Identität: das technische Konto, unter dem ein Agent handelt, also Service-Account, API-Schlüssel, OAuth-Token oder Bot-Nutzerkonto; sie ist von der Person zu unterscheiden, die den Agenten betreibt.
• Berechtigung (Permission): eine einzelne, konkrete Erlaubnis, etwa „darf Datei X lesen“, „darf E-Mails versenden“ oder „darf Datensatz Y ändern“.
• Rolle: ein benanntes Bündel von Berechtigungen, das man einer Identität zuweist, etwa „Viewer“, „Editor“ oder eine eigene Rolle wie „Ticket-Kategorisierer“.
• Least Privilege: das Prinzip, jeder Identität nur die minimal nötigen Rechte für ihre konkrete Aufgabe zu geben, zeitlich und fachlich begrenzt.
• Scope: die genaue Grenze eines API-Zugangs, zum Beispiel bei OAuth, etwa „nur Kalender lesen“ statt „vollständiger Kontozugriff“.

Wichtig ist die Abgrenzung nach unten. Ein geteiltes Admin-Passwort, das der Agent „mitbenutzt“, ist kein Berechtigungskonzept, sondern das Fehlen eines solchen. Daran ändert auch nichts, dass es technisch funktioniert.

Welche Identität nutzt ein Agent?

Die kurze Antwort: eine eigene technische Identität, kein menschliches Konto. Der Grund ist mehr als Ordnung. Sobald ein Agent unter dem Konto einer Person läuft, verschmelzen zwei Dinge, die getrennt bleiben müssen. Was die Person selbst tut, und was der Agent in ihrem Namen tut. Das hat 3 konkrete Nachteile.

Erstens fehlt die Nachvollziehbarkeit. Steht im Log nur „Nutzerin Maier“, lässt sich später nicht mehr rekonstruieren, wer einen E-Mail-Versand ausgelöst hat: Maier selbst oder der Agent unter ihrem Konto. Bei einer Fehlermeldung, einer Kundenbeschwerde oder einem Sicherheitsvorfall ist das die erste Frage. Ohne getrennte Identität kannst du sie nicht beantworten.

Zweitens vererbt sich jede Rechteänderung der Person auf den Agenten, und umgekehrt. Wird Maier befördert und bekommt zusätzliche Rechte, bekommt sie der Agent automatisch mit, auch bei unveränderter Aufgabe. Verlässt Maier das Unternehmen und ihr Konto wird gesperrt, fällt der Agent mit aus. Dabei sollte er eigentlich weiterlaufen.

Drittens lässt sich ein menschliches Konto aus guten Gründen nicht beliebig einschränken. Menschen brauchen im Tagesgeschäft wechselnde, oft breite Zugriffe. Ein Agent mit klar definierter, enger Aufgabe braucht das Gegenteil: einen schmalen, stabilen Zugriff. Beides unter einem Konto zu vereinen, führt fast zwangsläufig dazu, dass der Agent zu viel darf.

Technisch heißt das: ein eigener Service-Account pro Agent oder pro klar abgegrenzter Agentengruppe. Dazu ein eigener API-Schlüssel oder ein eigenes OAuth-Token mit definierten Scopes und ein eigener Eintrag im Rollensystem des Tools. Workflow-Plattformen wie n8n bilden das inzwischen strukturiert ab. Zugänge (dort „Credentials“ genannt) werden separat verwaltet und projektweise zugewiesen, statt im Workflow selbst zu stehen. Wer Zugriff auf einen Workflow hat, hat dadurch nicht automatisch Zugriff auf die dahinterliegenden Zugangsdaten.

Was bedeutet Least Privilege?

Least Privilege ist keine Zahl, sondern eine Denkrichtung. Bei jeder Berechtigung stellt man sich die Frage: Braucht der Agent das für diese Aufgabe wirklich? Nicht: Könnte das später mal nützlich sein? Der zweite Reflex ist der häufigste Grund für überberechtigte Agenten.

Praktisch sind es 3 Schritte.

1. Aufgabe zuerst definieren, dann Rechte ableiten. Aus „Agent liest neue Leads aus Ansicht X und schreibt einen Status-Tag“ folgt: Lesezugriff nur auf diese Ansicht, Schreibzugriff nur auf das Statusfeld, ohne Kontakthistorie oder Preise.
2. Vorhandene Granularität nutzen. Viele Systeme erlauben feinere Rechte, als im Alltag genutzt werden: einzelne Tabellen statt der ganzen Datenbank, einzelne Ordner statt des Laufwerks, einzelne API-Endpunkte statt Vollzugriff.
3. Regelmäßig prüfen, nicht nur beim Einrichten. Ein Agent bekommt im Projektverlauf „schnell noch“ Schreibrechte für einen Sonderfall, und die bleiben oft bestehen, wenn der Sonderfall längst erledigt ist.

Least Privilege bedeutet ausdrücklich nicht, dem Agenten grundsätzlich zu misstrauen. Es bedeutet, den Schaden im Fehlerfall zu begrenzen. Auslöser können fehlerhafte Ausgaben des Modells sein, eine Prompt Injection aus einer verarbeiteten externen Quelle oder schlicht ein Konfigurationsfehler.

Wie trennt man Lesen und Schreiben?

Diese Trennung ist der wirksamste einzelne Hebel. Sie teilt das Risiko sofort in 2 sehr unterschiedliche Kategorien.

Lesende Aktionen verändern nichts im Zielsystem: Daten abrufen, zusammenfassen, kategorisieren, einen Antwortentwurf erstellen. Geht dabei etwas schief, entsteht schlimmstenfalls eine falsche Ausgabe, die ein Mensch prüfen kann, bevor sie wirkt. Diese Aktionen können in der Regel ohne zusätzliche Freigabe automatisiert laufen.

Schreibende oder auslösende Aktionen verändern etwas außerhalb des Agenten, oft unumkehrbar: eine E-Mail versenden, einen Datensatz ändern oder löschen, eine Zahlung anstoßen, eine Bestellung auslösen. Hier lohnt sich eine bewusste Entscheidung pro Aktionstyp. Läuft sie vollautomatisch, weil der Schaden im Fehlerfall gering und leicht korrigierbar ist? Oder braucht sie eine explizite menschliche Freigabe, bevor sie ausgeführt wird?

Technisch heißt das: Lese- und Schreibrechte werden als getrennte Berechtigungen behandelt, auch beim selben Tool oder Datensatz. Ein Agent, der Support-Anfragen kategorisiert, kann breiten Lesezugriff auf das Ticketsystem bekommen. Schreibzugriff bekommt er nur sehr eng oder gar nicht, wenn Antworten weiterhin von Menschen versendet werden sollen.

Rollensysteme arbeiten nach genau diesem Prinzip, etwa n8n mit den 3 Projektrollen Admin, Editor und Viewer. Eine Viewer-Rolle kann Workflows und Zugangsdaten einsehen, aber nicht ausführen oder verändern. Für rein beobachtende oder auditierende Zugänge ist das oft die richtige Wahl, auch für Agenten, die nur lesen sollen.

Wie schützt man Secrets?

Zugangsdaten werden am häufigsten falsch behandelt, weil sie am unauffälligsten sind. API-Schlüssel, Passwörter und Tokens fallen im Alltag kaum auf. Ein Schlüssel im Prompt, in einer Konfigurationsdatei im Repository oder in einer Notiz ist faktisch offen zugänglich. Jeder, der Zugriff auf diese Stelle bekommt, kann ihn lesen, unabhängig vom Berechtigungskonzept des Systems dahinter.

3 Grundregeln haben sich in meiner Arbeit bewährt.

• Secrets gehören in eine dedizierte Verwaltung, nicht in Code, Prompts oder Chat-Verläufe. Workflow-Tools bieten dafür eigene Credential-Speicher, für komplexere Setups gibt es dedizierte Secrets-Manager.
• Nutzungsrecht und Sichtbarkeit trennen. In n8n etwa lässt sich ein Zugang für ein Projekt freigeben, ohne dass jedes Projektmitglied den Schlüssel sieht; er bleibt bei der Ersteller-Person oder dem Projekt-Admin.
• Ein Secret pro Zweck, kein Master-Schlüssel für alles. Ändert man einen geteilten Vollzugriffs-Schlüssel, sind alle Verbindungen betroffen, nicht nur die eine, die es betrifft.

Der Agent erhält zur Laufzeit Zugriff auf die Funktion des Schlüssels, etwa „diese Aktion ausführen“. Die Möglichkeit, den Wert im Klartext auszulesen oder anzuzeigen, bekommt er im Regelfall nicht. Das BSI geht grundsätzlich davon aus, dass alle Informationen abgegriffen werden können, auf die ein generatives KI-Modell im Betrieb Zugriff hat. Für Secrets heißt das: Ein Schlüssel, der in einer Systemanweisung oder einem verarbeiteten Dokument steht, ist falsch aufgehoben. Der Agent sollte ihn gar nicht erst zu Gesicht bekommen.

Wie widerruft man Rechte?

Rechte zu vergeben ist der leichte Teil. Der Test für ein funktionierendes Konzept ist, wie schnell und sauber sich Rechte wieder entziehen lassen. Anlässe gibt es genug: Ein Projekt endet, ein Agent wird ersetzt, eine Integration scheint kompromittiert, oder die Aufgabe ändert sich.

Zuverlässig funktioniert das nur unter 2 Voraussetzungen. Erstens eine eigene Identität pro Agent, sonst trifft ein Widerruf auch Menschen mit. Zweitens dokumentierte, granulare Rechte, sonst weiß niemand genau, was entzogen werden muss. Sind beide erfüllt, sieht Widerruf in der Praxis so aus:

• Sofortiger Entzug: Service-Account deaktivieren oder löschen, API-Schlüssel rotieren oder widerrufen, Rolle im Rollensystem entfernen. Bei gut getrennten Identitäten ist das eine einzelne Aktion, keine Suche über mehrere Systeme.
• Rotation bei Verdacht auf Kompromittierung: Ein neuer Schlüssel wird ausgestellt, der alte sofort ungültig gemacht, nicht erst am Ende einer geplanten Wartung.
• Regelmäßige Durchsicht: Eine aktuell gehaltene Liste zeigt in Minuten, wer welche Agenten mit welchen Rechten betreibt, und deckt vergessene Agenten auf, deren Aufgabe längst erledigt ist.
• Verantwortlichkeit benennen: Für jeden Agenten steht fest, wer die Rechte verantwortet und sie im Ernstfall entziehen kann, auch außerhalb der üblichen Bürozeiten.

Umsetzung in 6 Schritten

Dieser Ablauf hat sich in meiner Arbeit bewährt. Er richtet sich an KMU, die den ersten oder zweiten Agenten mit echten Systemzugriffen aufsetzen. Er ist bewusst schlank gehalten, kein vollständiges Governance-Framework.

1. Aufgabe und Systeme auflisten. Was genau soll der Agent tun, mit welchen Tools und Datenquellen, lesend oder schreibend?

2. Kleinste passende Berechtigung wählen, nicht die bequemste. Bei unklarer Granularität lieber in der Dokumentation nachsehen, ob ein feinerer Scope existiert, statt Vollzugriff zu vergeben.

3. Eigene Identität einrichten. Service-Account, API-Schlüssel oder OAuth-App anlegen und Secrets in einer dedizierten Verwaltung ablegen, nie im Workflow selbst oder im Prompt.

4. Kritische Aktionen markieren. Entscheide, welche schreibenden Aktionen eine menschliche Freigabe brauchen, zumindest bis Vertrauen in die Zuverlässigkeit des Agenten aufgebaut ist.

5. Verantwortliche Person benennen. Sie behält die Rechte im Blick, dokumentiert sie und entzieht sie bei Bedarf.

6. Rechte in festem Rhythmus prüfen. Etwa vierteljährlich oder immer dann, wenn sich die Aufgabe des Agenten ändert.

Dieser Ablauf ersetzt keine tiefergehende Sicherheitsprüfung bei sensiblen Daten oder regulierten Branchen. Er ist ein Mindeststandard gegen die häufigsten Fehler: Vollzugriff aus Bequemlichkeit, geteilte Konten, Secrets im Klartext, vergessene Zugänge.

Risikomatrix mit Gegenmaßnahmen

Die Matrix bündelt 8 typische Berechtigungsrisiken. Sie ist als Ausgangspunkt für die eigene Bewertung gedacht, nicht als abschließende Prüfung für jeden Einzelfall.

4 Risiken stufe ich als hohe Priorität ein:

• Agent unter menschlichem Konto: Ein Workflow nutzt das persönliche CRM-Login einer Mitarbeiterin; die Gegenmaßnahme ist ein eigener Service-Account oder API-Schlüssel pro Agent.
• Vollzugriff statt engem Scope: Ein Agent für Ticket-Kategorisierung sieht das gesamte CRM; die Rechte gehören auf konkrete Ansichten, Felder oder Endpunkte begrenzt.
• Gebündelte Schreib- und Leserechte: Ein Zugang erlaubt Lesen und unbeaufsichtigtes Löschen zugleich; besser sind getrennte Berechtigungen plus Freigabe für kritische Schreibaktionen.
• Secrets im Klartext: Ein API-Schlüssel steht im Prompt oder in einer Konfigurationsdatei; er gehört in einen dedizierten Credential-Speicher ohne Klartext-Zugriff für den Agenten.

4 weitere haben mittlere Priorität:

• Geteilter Master-Schlüssel: Ein Zugang wird von 3 verschiedenen Workflows genutzt; besser ist ein Secret pro Zweck mit dokumentierter Zuordnung.
• Vergessene, nie entzogene Rechte: Ein Test-Agent aus einem abgeschlossenen Projekt hat weiter Zugriff; dagegen helfen regelmäßige Rechte-Durchsicht und feste Verantwortlichkeit.
• Prompt Injection nutzt vorhandene Rechte aus: Verarbeitete externe Inhalte enthalten versteckte Anweisungen; dagegen helfen Vertrauensgrenzen und eine Bestätigung vor kritischen Aktionen.
• Keine Nachvollziehbarkeit im Log: Unklar bleibt, ob Mensch oder Agent eine Aktion ausgelöst hat; die Antwort sind getrennte Identität und Protokollierung je Agent.

Eigene Risikomatrix Philogic Labs, abgeleitet aus BSI-Gegenmaßnahmen zu generativen KI-Modellen sowie aus Projekterfahrung mit Workflow-Automatisierung.

Risiken und Grenzen

Ein sauberes Berechtigungskonzept löst nicht jedes Problem. 5 ehrliche Grenzen gehören dazu.

Least Privilege verhindert keine fehlerhaften Ausgaben. Ein Agent mit minimalen Rechten kann innerhalb dieser Rechte trotzdem falsche Entscheidungen treffen. Er richtet nur weniger Schaden an, weil sein Wirkungsbereich begrenzt ist. Prüfschritte für kritische Aktionen bleiben deshalb sinnvoll, unabhängig vom Berechtigungskonzept.

Granulare Rechte kosten Pflegeaufwand. Je feiner die Rechte, desto mehr Einzelfälle sind bei Aufgabenänderungen anzupassen. Für sehr kleine, einmalige Automatisierungen kann ein pragmatischerer, aber klar dokumentierter Zugang ausreichen. Die Leitlinie lautet dann: die wenigsten Rechte, die realistisch pflegbar sind.

Prompt Injection lässt sich nicht vollständig ausschließen. Das BSI stellt klar, dass sich Manipulationen der Eingabe „nach aktuellem Stand der Technik“ nicht vollständig und zuverlässig unterbinden lassen. Das gilt besonders, wenn ein Modell Informationen aus unsicheren, externen Quellen verarbeitet. Berechtigungsmanagement begrenzt hier die Auswirkungen, es verhindert die Ursache nicht.

Nicht jedes Tool bietet die nötige Granularität. Manche Integrationen erlauben tatsächlich nur „alles oder nichts“. Dann steht die ehrliche Entscheidung an, ob der Use Case mit diesem Werkzeug überhaupt vertretbar ist. Alternativen sind ein Tool mit feineren Rechten oder eine engere Umsetzung ohne die riskante Integration.

Rechtlicher Rahmen, keine Rechtsberatung (Stand Juli 2026). Verarbeiten Agenten personenbezogene oder sensible Daten, gelten parallel die üblichen DSGVO-Anforderungen. Je nach Anwendungsfall kommen Vorgaben des EU AI Act dazu, etwa Transparenzpflichten bei KI-generierten Inhalten und angemessene menschliche Aufsicht bei höherem Risiko. Verbindliche Einordnung liefert dieser Artikel nicht; im Zweifel gehört das Thema zu Rechtsberatung oder Datenschutzbeauftragten.

Verbindliche Details stehen bei der Europäischen Kommission.

Und eine Grenze dieses Artikels selbst: Er beschreibt Prinzipien und ein Vorgehen, kennt aber nicht deine konkrete Systemlandschaft. Ob dein CRM, dein Ticketsystem oder dein Workflow-Tool die nötige Granularität anbietet, entscheidet sich nur am konkreten Fall.

Mehr zu den Grundlagen findest du im Cluster KI-Agenten, etwa was Agenten von klassischen Workflows unterscheidet. Deinen konkreten Agenten-Use-Case und die passende Rechtestruktur einschätzen zu lassen, ist Teil unseres Beratungsangebots. Grundlagen zum sicheren Umgang mit KI-Systemen vermitteln unsere Schulungen. Ein Erstgespräch klärt in kurzer Zeit, wo dein größtes Risiko aktuell liegt.

Checkliste: Berechtigungen für KI-Agenten

10 Punkte solltest du abhaken können.

1. Jeder Agent läuft unter einer eigenen technischen Identität, nicht unter dem Konto einer Person.

2. Die Rechte des Agenten sind aus seiner konkreten Aufgabe abgeleitet, nicht aus Bequemlichkeit gewählt.

3. Lesende und schreibende Aktionen sind als getrennte Berechtigungen behandelt.

4. Kritische oder unumkehrbare Aktionen brauchen eine definierte menschliche Freigabe, zumindest in der Anfangsphase.

5. Secrets liegen in einer dedizierten Verwaltung, nie im Prompt, im Code oder in einer Notiz.

6. Es gibt kein geteiltes Master-Secret für mehrere Agenten oder Workflows.

7. Für jeden Agenten ist dokumentiert, welche Rechte er hat, seit wann, wofür und wer verantwortlich ist.

8. Rechte lassen sich sofort und unabhängig von menschlichen Zugängen entziehen oder rotieren.

9. Ein fester Rhythmus stellt sicher, dass Agenten-Rechte regelmäßig überprüft werden, nicht nur beim Einrichten.

10. Bei personenbezogenen oder sensiblen Daten sind Datenschutz und relevante AI-Act-Pflichten von Anfang an mitgedacht.