KI-Access-Control für GenAI – Rechte, Rollen, Logging

Ein interner Chatbot für Richtlinien, ein Assistenzsystem für Vertriebsmails oder ein RAG-Tool für Projektakten: In vielen GenAI-Projekten entsteht schnell ein „API-first“-Betriebsbild. Genau dort entscheidet sich, ob Risiken kontrollierbar bleiben. Denn ohne durchdachte Zugriffskontrolle kann dieselbe Anwendung für eine Person ein Produktivitätsgewinn sein – und für eine andere unbeabsichtigt ein Datenabfluss, eine unzulässige Einsicht oder eine Audit-Lücke.

KI-Access-Control in GenAI-Kontexten ist mehr als „Login erforderlich“. Es geht um die Frage: Wer darf welche Funktion nutzen, auf welche Daten zugreifen, welche Aktionen auslösen – und wie wird das nachweisbar dokumentiert? Das betrifft nicht nur die Oberfläche, sondern auch APIs, Tool-Aufrufe, Retrieval, Prompt-Variablen, Connectoren und die Ausleitung von Ergebnissen.

Zugriffskontrolle bei GenAI: Was sich gegenüber klassischen Apps ändert

LLM-App statt Formular: Aktionen sind schwerer vorherzusehen

In klassischen Business-Apps sind Eingaben und Ausgaben stärker strukturiert. Bei GenAI sind Prompts frei, Outputs variieren, und Tools (z. B. Kalender, CRM, Ticketsystem) können je nach Anfrage dynamisch angesprochen werden. Daraus folgt: Rechte müssen nicht nur an „Screens“ hängen, sondern an Fähigkeiten wie „darf Tool X ausführen“, „darf Dokumentklasse Y abrufen“, „darf Ergebnis exportieren“.

RAG verbindet Identität mit Datenzugriff in Echtzeit

In RAG-Systemen entscheidet die Retrieval-Schicht, welche Dokumente in den Kontext gelangen. Damit wird Zugriffskontrolle zu einem Teil der Such- und Index-Architektur. Ein häufiger Fehler: Der Vektorindex wird als „neutrale“ Schicht behandelt, obwohl er faktisch eine Abkürzung zu sensiblen Inhalten sein kann.

Hilfreich ist die Kopplung von Nutzeridentität und Retrieval-Policy (z. B. Dokumentfreigaben, Mandanten, Projektrollen). Dazu passt der Aufbau „Identity → Policy Decision → Retrieval Filter → Kontext“. Für angrenzende Risiken lohnt außerdem der Blick auf Datenklassifizierung für GenAI, weil Zugriffskontrolle ohne klare Schutzklassen schnell an Grenzen stößt.

Tool-Nutzung ist ein privilegierter Pfad

Sobald ein LLM Tools ausführen darf (z. B. „Ticket erstellen“, „E-Mail senden“, „Kundendaten lesen“), entsteht ein privilegierter Ausführungskanal. Hier sollte nicht „alles oder nichts“ gelten. Stattdessen benötigen Tools eigene Rechte, Limits und eine nachvollziehbare Freigabe pro Use Case.

Rollen, Rechte, Policies: ein praxistaugliches Modell

Rollen sind nicht gleich Berechtigungen

Rollen sind verständliche Bündel (z. B. „Support-Agent“, „Teamlead“, „Admin“). Berechtigungen sind präzise Aussagen (z. B. „read:knowledgebase:public“, „retrieve:project:alpha“, „execute:tool:create_ticket“). Eine saubere Trennung hilft, später fein nachzusteuern, ohne das Rollenmodell ständig umzubauen.

Policy-Muster, die sich in GenAI bewähren

In GenAI-Architekturen funktionieren Policies am besten, wenn sie entlang von vier Achsen formuliert werden:

• Least Privilege: Standardmäßig nur das Nötige erlauben, Erweiterungen explizit.
• Ressource: Welche Daten (Dokumenttyp, Mandant, Projekt, System) sind betroffen?
• Aktion: Lesen, Abrufen (Retrieval), Schreiben, Export, Tool-Ausführung.
• Kontext: Zweck/Use Case, Gerät/Netz, Risikostufe, Umgebung (Prod/Test).

Ein praktisches Beispiel: Ein „Sales-Assistant“ darf Angebote aus einer freigegebenen Produktdatenbank abrufen, aber keine Kundendaten exportieren und keine E-Mails versenden, ohne dass ein Mensch den Text freigibt. So wird die Produktivität gefördert, ohne dass die App zur Versandmaschine wird.

ABAC für Daten, RBAC für Bedienbarkeit

Für GenAI ist oft eine Kombination sinnvoll: RBAC für die groben App-Fähigkeiten (welche Features sind sichtbar) und ABAC für den Datenzugriff (welche Dokumente dürfen in den Kontext). ABAC-Attribute sind z. B. Mandant, Projekt-ID, Dokumentklasse, Freigabestatus, „intern/vertraulich“, Aufbewahrungsstatus.

Technische Bausteine: Identity, Gateway, Retrieval und Tools

Identity & Session: konsistente Nutzer- und Service-Identitäten

GenAI-Systeme haben nicht nur „User“, sondern auch Service-Accounts: Connectoren, Indexer, Worker, Tool-Runner. Für Security und Audits ist entscheidend, dass jede Aktion eindeutig einer Identität (oder einem technischen Principal) zugeordnet wird. Dabei sollte klar sein, ob eine Aktion „im Namen“ eines Users passiert oder als Systemdienst.

API- und App-Gateway: ein zentraler Enforcement-Point

Viele LLM-Apps wachsen als Microservice-Landschaft. Ohne zentralen Enforcement-Point driftet Zugriffskontrolle in einzelne Services ab. Ein Gateway kann Token prüfen, Policies erzwingen, Rate Limits pro Rolle setzen und eine einheitliche Audit-Spur erzeugen. Für die Betriebsseite ist ergänzend Rate Limiting für GenAI-APIs relevant, weil Missbrauch und Kostenexplosionen oft zusammen auftreten.

Retrieval: Filterung vor dem Kontext ist Pflicht

Beim Retrieval gilt: Dokumente müssen vor dem Einfügen in den Prompt gefiltert werden – nicht erst nach der Antwort. „Post-Filter“ ist zu spät, weil Informationen bereits im Modellkontext waren. Außerdem sollte der Index nicht nur Embeddings enthalten, sondern auch robuste Metadaten (Mandant, Berechtigung, Klassifizierung, Quelle, Aktualität).

Tools und Aktionen: Freigaben, Grenzen, Bestätigungen

Tool-Aufrufe sollten wie privilegierte API-Calls behandelt werden. Bewährte Mechaniken:

• Explizite Tool-Whitelists pro Use Case (nicht pro Modell).
• Parameter-Validierung (z. B. erlaubte Felder, zulässige IDs, Maximalgrößen).
• Human-in-the-loop für irreversibles Schreiben (E-Mail senden, Bestellung auslösen).
• Separate Secrets/Scopes für Tool-Runner, nicht im Prompt-Kontext.

Wer agentische Systeme plant, sollte diese Tool-Ebene besonders ernst nehmen; ergänzend kann Architektur und Risiken von KI-Agenten helfen, typische Kontrollpunkte systematisch abzuleiten.

Auditierbares Logging: Was wirklich in die Protokolle gehört

Nachvollziehbarkeit ohne Datenfriedhof

Ein Logging „aller Prompts und Antworten“ wirkt zunächst attraktiv, führt aber häufig zu neuen Risiken: unnötige Datenspeicherung, sensibler Inhalt in Logs, steigende Zugriffsfläche. Sinnvoller ist ein Ereignis- und Metadatenfokus: Wer hat wann welche Aktion ausgelöst, auf welche Datenklasse zugegriffen und welche Systeme wurden berührt?

Minimaler Audit-Datensatz für GenAI-Requests

Ein praxistauglicher Datensatz enthält typischerweise:

• Zeitstempel, Request-ID, Session-ID
• Nutzer- oder Service-Identität, Rolle(n), Mandant/Organisationseinheit
• Use-Case-ID oder App-Feature
• Datenzugriffs-Metadaten: Quellen/Connectoren, Dokument-IDs (oder Hashes), Klassifizierungen
• Tool-Aufrufe: Tool-Name, Parameter-Metadaten (ohne unnötige Inhalte), Ergebnisstatus
• Policy-Entscheidung: erlaubt/abgelehnt, Regel-ID, Grundcode
• Output-Handling: Export, Kopieren, Download, Weiterleitung (falls vorhanden)

Für die Qualitäts- und Risikoüberwachung kann zusätzlich eine getrennte Telemetrie sinnvoll sein. Dabei sollten Protokolle nicht mit Evaluationsdaten verwechselt werden; strukturierte Tests gehören in einen eigenen Prozess wie in LLM-Evaluierung im Unternehmen.

Aufbewahrung und Zugriff auf Logs

Logs sind oft sensibler als gedacht, weil sie Muster, Dokument-IDs oder Tool-Aktionen enthalten. Daher braucht es auch für Logs eine Zugriffskontrolle (z. B. nur Security/Compliance), klare Aufbewahrungsregeln und ein Verfahren für Auskunft/Incident-Analyse. Wichtig ist zudem, dass Debug-Logs aus der Entwicklung nicht ungeprüft in Produktion landen.

Typische Fehlerbilder – und wie sie sich vermeiden lassen

„Eine Rolle für alle“: Produktivität kurzfristig, Risiko dauerhaft

Wenn jede Person denselben Zugriff auf dieselben Daten bekommt, entstehen schnelle Demo-Erfolge, aber kein skalierbarer Betrieb. Besser ist ein Start mit wenigen Rollen, die entlang realer Arbeitskontexte getrennt sind: Abteilung, Mandant, Projekt, Datenklasse.

Vektorindex ohne Autorisierungsschicht

Ein Index, der Dokumente aus mehreren Bereichen mischt, ohne Retrieval-Filter anhand der Identität, ist eine Einladung zu ungewollten Einsichten. Der Index muss Metadaten tragen, und die Abfrage muss diese Metadaten verpflichtend berücksichtigen. Das ist kein „Nice-to-have“, sondern Kern der Zugriffskontrolle im RAG-Teil.

Prompt als Policy-Träger

Wenn Policies nur im Systemprompt formuliert sind („Gib keine vertraulichen Daten aus“), bleibt die Kontrolle weich und schwer prüfbar. Harte Kontrollen gehören in AuthZ-Schichten, Retrieval-Filter, Tool-Runner und Output-Kanäle. Prompt-Regeln sind ergänzend, nicht tragend.

Ein umsetzbarer Weg von null zu kontrolliertem Betrieb

Praktische Schritte für die ersten vier Wochen

• Use Cases priorisieren: Welche Datenquellen und Tools sind im Scope, welche Nutzergruppen?
• Rollen skizzieren: 3–6 Rollen starten, mit klaren „dürfen/dürfen nicht“-Aussagen.
• Policy-Backbone definieren: Ressource/Aktion/Kontext als Standard-Format, inklusive Regel-IDs.
• Retrieval absichern: Metadatenmodell festlegen, Filter erzwingen, Testfälle für „darf nicht sehen“ bauen.
• Tool-Ebene härten: Tool-Whitelist, Parameter-Validierung, Bestätigungsdialoge für Schreibaktionen.
• Audit-Logging einführen: Request-ID, Policy-Entscheidung, Datenquellen, Tool-Aufrufe, Exportpfade.
• Abnahmeprozess: Security/Compliance checkt Rollen, Policies, Logs und Missbrauchswege.

Entscheidungshilfe: Welche Zugriffsebene zuerst härten?

• Wenn die App nur „liest“ (Q&A über Dokumente):
  • Retrieval-Filter und Dokumentmetadaten zuerst absichern.
  • Dann Export- und Sharing-Kanäle (Copy, Download, E-Mail) kontrollieren.
• Wenn die App Tools ausführt (Tickets, E-Mails, CRM):
  • Tool-Berechtigungen zuerst: Whitelists, Scopes, Validierung.
  • Dann Human-in-the-loop für irreversible Aktionen.
• Wenn mehrere Teams/Mandanten dieselbe Plattform nutzen:
  • Mandantentrennung in Identity, Index und Storage als Basis.
  • Logging getrennt auswertbar machen (Tenant-Kontext in jedem Event).

Kompakte Gegenüberstellung gängiger Policy-Ansätze

Häufige Fragen aus Security, IT und Fachbereichen

Reicht Single Sign-on für GenAI-Apps aus?

Single Sign-on klärt Authentifizierung, nicht Autorisierung. Entscheidend sind zusätzlich Rollen/Policies, Retrieval-Filter, Tool-Scopes und eine saubere Protokollierung der Entscheidungen.

Sollten Prompts und Antworten gespeichert werden?

Das hängt vom Zweck ab. Für Auditierbarkeit reichen oft Metadaten und Ereignisse. Wenn Inhalte gespeichert werden, sollte das begründet, minimiert, geschützt und zugriffsseitig streng getrennt erfolgen.

Wie lässt sich verhindern, dass ein LLM über Tools „zu viel“ macht?

Tool-Aufrufe benötigen eigene Berechtigungen, eng definierte Parameter, ggf. Bestätigungen und eine klare Trennung zwischen „lesen“ und „schreiben“. Zusätzlich sollten Policies nicht nur im Prompt stehen, sondern technisch erzwungen werden.