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

Ein KI-Agent, der E-Mails lesen, Termine buchen oder Daten in ein CRM schreiben soll, braucht dafür 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?”, sondern „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 – und behält diese Rechte, 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 bereits einsetzen. Er beantwortet die 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, und wie widerruft man Rechte wieder – inklusive einer eigenen Risikomatrix mit Gegenmaßnahmen und einer Checkliste zum Abhaken.

Das Problem: Rechte aus Bequemlichkeit statt aus Bedarf

Der Bundesamt für Sicherheit in der Informationstechnik (BSI) beschreibt in seiner Publikation zu generativen KI-Modellen einen Kernmechanismus, der genau hier ansetzt: 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 ausdrücklich, die Zugriffs- und Ausführungsrechte von LLM-basierten Anwendungen „auf das notwendige Minimum” zu beschränken und klare Vertrauensgrenzen zwischen Modell, Anwendung, externen Ressourcen und erweiterten Funktionen festzulegen.

In der Umsetzung passiert oft das Gegenteil. Ein Agent soll drei Support-Tickets pro Tag kategorisieren – und bekommt dafür 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 – und 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, ein Agent, der eine Aktion ausführt, die niemand angestoßen hat.

Begriffe kurz geklärt

• Identität ist das technische Konto, unter dem ein Agent handelt – Service-Account, API-Schlüssel, OAuth-Token oder Bot-Nutzerkonto. Sie ist von der Identität der Person zu unterscheiden, die den Agenten betreibt oder konfiguriert hat.
• Berechtigung (Permission) ist eine einzelne, konkrete Erlaubnis: „darf Datei X lesen”, „darf E-Mail versenden”, „darf Datensatz Y ändern”.
• Rolle ist ein benanntes Bündel von Berechtigungen, das man einer Identität zuweist, statt jede Berechtigung einzeln zu vergeben – etwa „Viewer”, „Editor” oder eine selbst definierte Rolle wie „Ticket-Kategorisierer”.
• Least Privilege ist das Prinzip, jeder Identität nur die minimal nötigen Berechtigungen für ihre konkrete Aufgabe zu geben, zeitlich und fachlich begrenzt.
• Scope bezeichnet bei API-Zugängen (z. B. OAuth) die genaue Grenze eines Tokens – 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 – auch wenn es technisch funktioniert.

Welche Identität nutzt ein Agent?

Die kurze Antwort steht bereits oben als Direktantwort: 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 drei konkrete Nachteile.

Erstens fehlt die Nachvollziehbarkeit. Wenn im Log nur „Nutzerin Maier” steht, lässt sich im Nachhinein nicht mehr rekonstruieren, ob ein bestimmter E-Mail-Versand von Maier selbst oder vom Agenten ausgelöst wurde, der unter ihrem Konto läuft. Bei einer Fehlermeldung, einem Kundenbeschwerde oder einem Sicherheitsvorfall ist das die erste Frage, die man beantworten muss – und ohne getrennte Identität kann man es nicht.

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 wenn dessen Aufgabe unverändert ist. Verlässt Maier das Unternehmen und ihr Konto wird gesperrt, fällt der Agent mit aus, obwohl er weiterlaufen sollte.

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 einer klar definierten, engen Aufgabe braucht das Gegenteil: einen schmalen, stabilen Zugriff. Beide Anforderungen unter einem Konto zu vereinen, führt fast zwangsläufig dazu, dass der Agent zu viel darf.

Technisch heißt das in der Praxis: ein eigener Service-Account pro Agent oder pro klar abgegrenzter Agentengruppe, ein eigener API-Schlüssel oder ein eigenes OAuth-Token mit definierten Scopes, ein eigener Eintrag im Rollensystem des jeweiligen Tools. Workflow-Plattformen wie n8n bilden das inzwischen strukturiert ab: Zugänge (dort „Credentials” genannt) werden dort 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, die ein Agent bekommt, stellt man sich die Frage „Braucht er 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 lässt sich das in drei Schritten umsetzen:

1. Aufgabe zuerst definieren, dann Rechte ableiten. Nicht „Agent bekommt Zugriff auf das CRM”, sondern „Agent liest neue Leads aus der Ansicht X und schreibt einen Status-Tag” – daraus folgt exakt: Lesezugriff auf diese Ansicht, Schreibzugriff nur auf das Statusfeld. Kein Zugriff auf Kontakthistorie, Preise oder andere Objekte.
2. Granularität nutzen, die das Tool bietet. Viele Systeme erlauben feinere Rechte, als im Alltag genutzt werden – Zugriff auf einzelne Tabellen statt die ganze Datenbank, auf einzelne Ordner statt das ganze Laufwerk, auf einzelne API-Endpunkte statt den vollen Kontozugriff. Das BSI nennt dies explizit als Gegenmaßnahme (M17): klare Vertrauensgrenzen zwischen Modell, Anwendung, externen Ressourcen und Funktionen.
3. Regelmäßig prüfen, nicht nur beim Einrichten. Rechte, die beim Start sinnvoll waren, veralten. Ein Agent, der ursprünglich nur lesen sollte, 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 – durch fehlerhafte Ausgaben des Modells, durch eine Prompt Injection aus einer verarbeiteten externen Quelle oder schlicht durch einen Konfigurationsfehler.

Wie trennt man Lesen und Schreiben?

Diese Trennung ist der wirksamste einzelne Hebel, weil sie das Risiko sofort in zwei sehr unterschiedliche Kategorien teilt.

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

Schreibende oder auslösende Aktionen – eine E-Mail versenden, einen Datensatz ändern oder löschen, eine Zahlung anstoßen, eine Bestellung auslösen – verändern etwas außerhalb des Agenten, oft unumkehrbar. 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 nicht als ein Paket vergeben, sondern als getrennte Berechtigungen behandelt, auch wenn dasselbe Tool oder derselbe Datensatz betroffen ist. Ein Agent, der Support-Anfragen kategorisiert, kann breiten Lesezugriff auf das Ticketsystem bekommen – aber nur sehr engen oder gar keinen Schreibzugriff, wenn Antworten weiterhin von Menschen versendet werden sollen. Rollensysteme, wie sie etwa n8n mit den Projektrollen Admin, Editor und Viewer abbildet, arbeiten nach genau diesem Prinzip: Eine Viewer-Rolle kann Workflows und Zugangsdaten einsehen, aber nicht ausführen oder verändern – für rein beobachtende oder auditierende Zugänge oft die richtige Wahl, auch für Agenten, die nur lesen sollen.

Wie schützt man Secrets?

Zugangsdaten – API-Schlüssel, Passwörter, Tokens – sind der Teil der Berechtigung, der am häufigsten falsch behandelt wird, weil er am unauffälligsten ist. Ein Schlüssel, der im Prompt, in einer Konfigurationsdatei im Repository oder in einer Notiz landet, ist faktisch offen zugänglich für jeden, der Zugriff auf diese Stelle bekommt – unabhängig vom eigentlichen Berechtigungskonzept des Systems dahinter.

Drei 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. Der Agent erhält zur Laufzeit Zugriff auf die Funktion des Schlüssels (z. B. „diese Aktion ausführen”), im Regelfall aber nicht die Möglichkeit, den Schlüssel selbst im Klartext auszulesen oder anzuzeigen.
• Nutzungsrecht und Sichtbarkeit sind zwei verschiedene Dinge. In n8n etwa lässt sich ein Zugang für ein Projekt freigeben, sodass Workflows ihn nutzen können, ohne dass jedes Projektmitglied den zugrunde liegenden Schlüssel sieht – erstellt und „besitzt” bleibt der Zugang bei der ursprünglichen Person oder dem Projekt-Admin. Diese Trennung ist für Agenten besonders relevant: Ein Agent braucht die Funktion eines Zugangs, so gut wie nie die Möglichkeit, ihn auszulesen oder weiterzugeben.
• Ein Secret pro Zweck, nicht ein Master-Schlüssel für alles. Ein einzelner API-Schlüssel mit Vollzugriff, der von mehreren Agenten und Workflows gemeinsam genutzt wird, macht jede spätere Einschränkung oder jeden Widerruf unnötig kompliziert – ändert man ihn, sind alle Verbindungen betroffen, nicht nur die eine, die es betrifft.

Das BSI weist im gleichen Zusammenhang darauf hin, dass grundsätzlich davon auszugehen ist, dass alle Informationen, auf die ein generatives KI-Modell während des Betriebs Zugriff hat, potenziell abgegriffen werden können. Für Secrets heißt das: Ein Agent, der einen Schlüssel im Klartext verarbeiten könnte (etwa weil er in einer Systemanweisung oder einem verarbeiteten Dokument steht), sollte diesen Schlüssel gar nicht erst zu Gesicht bekommen.

Wie widerruft man Rechte?

Rechte zu vergeben ist der leichte Teil. Der Test für ein funktionierendes Berechtigungskonzept ist, wie schnell und wie sauber sich Rechte wieder entziehen lassen – etwa wenn ein Projekt endet, ein Agent ersetzt wird, eine Integration kompromittiert scheint oder sich einfach die Aufgabe ändert.

Das funktioniert zuverlässig nur, wenn zwei Voraussetzungen aus den vorherigen Abschnitten erfüllt sind: eine eigene Identität pro Agent (sonst trifft ein Widerruf auch Menschen mit) und dokumentierte, granulare Rechte (sonst weiß niemand genau, was entzogen werden muss). Sind diese Voraussetzungen erfüllt, sieht Widerruf in der Praxis so aus:

• Sofortiger Entzug: Service-Account deaktivieren oder löschen, API-Schlüssel rotieren bzw. widerrufen, Rolle im Rollensystem entfernen. Bei gut getrennten Identitäten ist das eine einzelne Aktion, keine Suche über mehrere Systeme.
• Rotation statt nur Löschung 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, nicht nur anlassbezogen. Wer hat welche Agenten mit welchen Rechten aktuell im Einsatz? Eine einfache, aktuell gehaltene Liste beantwortet diese Frage in Minuten statt in Tagen – und deckt „vergessene” Agenten auf, deren ursprüngliche Aufgabe längst erledigt ist, deren Zugang aber nie entfernt wurde.
• Verantwortlichkeit benennen. Genau wie bei menschlichen Zugängen sollte für jeden Agenten feststehen, wer für dessen Rechte verantwortlich ist und wer sie im Ernstfall entziehen kann, auch außerhalb der üblichen Bürozeiten.

Umsetzung: Ein pragmatischer Ablauf

Für ein KMU, das den ersten oder zweiten Agenten mit echten Systemzugriffen aufsetzt, hat sich folgender Ablauf in meiner Arbeit bewährt – bewusst schlank gehalten, nicht als vollständiges Governance-Framework:

1. Aufgabe und benötigte Systeme auflisten. Was genau soll der Agent tun, mit welchen Tools und Datenquellen, lesend und/oder schreibend?
2. Für jede benötigte Aktion die kleinste passende Berechtigung identifizieren, nicht die bequemste. Bei unklarer Granularität: lieber beim Anbieter oder in der Dokumentation nachsehen, ob ein feinerer Scope existiert, statt „Vollzugriff, weil einfacher” zu wählen.
3. Eigene Identität einrichten (Service-Account, API-Schlüssel oder OAuth-App), Secrets in einer dedizierten Verwaltung ablegen, nie im Workflow selbst oder im Prompt.
4. Schreibende und kritische Aktionen markieren und entscheiden, welche davon eine menschliche Freigabe brauchen – zumindest in der Anfangsphase, bis Vertrauen in die Zuverlässigkeit des Agenten aufgebaut ist.
5. Verantwortliche Person benennen, die Rechte im Blick behält, dokumentiert und bei Bedarf entzieht.
6. Rechte nach einem festen Rhythmus überprüfen – etwa vierteljährlich oder immer, wenn sich die Aufgabe des Agenten ändert.

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

Eigene Risikomatrix: Berechtigungsrisiken und Gegenmaßnahmen

Die folgende Matrix fasst die in diesem Artikel behandelten Risiken zusammen und ordnet ihnen konkrete Gegenmaßnahmen zu. Sie ist als Ausgangspunkt für die eigene Bewertung gedacht, nicht als abschließende Checkliste für jeden Einzelfall.

Risiko	Beispiel aus der Praxis	Gegenmaßnahme	Priorität
Agent läuft unter menschlichem Konto	Workflow nutzt das persönliche CRM-Login einer Mitarbeiterin	Eigener Service-Account/API-Schlüssel pro Agent	Hoch
Vollzugriff statt engem Scope	Agent für Ticket-Kategorisierung hat Zugriff auf das gesamte CRM	Rechte auf konkrete Ansicht/Feld/Endpunkt begrenzen	Hoch
Schreib- und Leserechte gebündelt	Ein Zugang erlaubt sowohl Lesen als auch unbeaufsichtigtes Löschen	Getrennte Berechtigungen, Freigabe für kritische Schreibaktionen	Hoch
Secrets im Klartext	API-Schlüssel steht im Prompt oder in einer Konfigurationsdatei	Dedizierter Secrets-/Credential-Speicher, kein Klartext-Zugriff für den Agenten	Hoch
Geteilter Master-Schlüssel für mehrere Agenten	Ein Zugang wird von drei verschiedenen Workflows genutzt	Ein Secret pro Zweck, Zuordnung dokumentieren	Mittel
Vergessene, nie entzogene Rechte	Ein Test-Agent aus einem abgeschlossenen Projekt hat weiter Zugriff	Regelmäßige Rechte-Durchsicht, feste Verantwortlichkeit	Mittel
Prompt Injection nutzt vorhandene Rechte aus	Agent verarbeitet externe Inhalte, die versteckte Anweisungen enthalten	Vertrauensgrenzen zwischen Modell, Anwendung und externen Quellen; Bestätigung vor kritischen Aktionen	Mittel
Keine Nachvollziehbarkeit im Log	Unklar, ob eine Aktion von Mensch oder Agent ausgelöst wurde	Getrennte Identität und Protokollierung je Agent	Mittel

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

Risiken & Grenzen

Ein sauberes Berechtigungskonzept löst nicht jedes Problem. Ein paar ehrliche Grenzen:

• Least Privilege verhindert keine fehlerhaften Ausgaben. Ein Agent mit minimalen Rechten kann innerhalb dieser Rechte trotzdem falsche Entscheidungen treffen – er kann nur weniger Schaden anrichten, 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 müssen bei Änderungen der Aufgabe angepasst werden. Für sehr kleine, einmalige Automatisierungen kann ein pragmatischerer, aber weiterhin klar dokumentierter Zugang ausreichen – „am wenigsten Rechte, die realistisch pflegbar sind” statt eines theoretischen Maximums an Granularität.
• Prompt Injection lässt sich nicht vollständig ausschließen. Das BSI stellt klar, dass es „nach aktuellem Stand der Technik” keine Möglichkeit gibt, Manipulationen der Eingabe vollständig und zuverlässig zu unterbinden – 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”. In diesem Fall ist die ehrliche Entscheidung, ob der Use Case mit diesem Werkzeug überhaupt vertretbar ist – oder ob ein Tool mit feineren Rechten oder eine engere Umsetzung ohne die riskante Integration die bessere Wahl ist.
• Rechtlicher Rahmen, keine Rechtsberatung (Stand Juli 2026). Wo Agenten personenbezogene oder anderweitig sensible Daten verarbeiten, gelten parallel die üblichen DSGVO-Anforderungen sowie – abhängig vom Anwendungsfall – Vorgaben des EU AI Act, etwa zu Transparenzpflichten bei KI-generierten Inhalten und zu angemessener menschlicher 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 überhaupt anbietet, entscheidet sich nur am konkreten Fall. Mehr zu den Grundlagen von KI-Agenten – was sie von klassischen Workflows unterscheidet – findest du im Cluster KI-Agenten. Wenn du deinen konkreten Agenten-Use-Case und die passende Rechtestruktur einschätzen lassen willst: Das findest du in unserem Beratungsangebot, Grundlagen zum sicheren Umgang mit KI-Systemen vermitteln unsere Schulungen, und ein Erstgespräch klärt in kurzer Zeit, wo dein größtes Risiko aktuell liegt.

Checkliste: Berechtigungen für KI-Agenten

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, seit wann, wofür, wer verantwortlich ist.
8. Rechte lassen sich sofort und unabhängig von menschlichen Zugängen entziehen oder rotieren.
9. Es gibt einen festen Rhythmus, um bestehende Agenten-Rechte zu überprüfen – nicht nur beim Einrichten.
10. Bei personenbezogenen oder sensiblen Daten sind Datenschutz und relevante AI-Act-Pflichten mitgedacht, nicht nachträglich ergänzt.