Authorization in LLM-Anwendungen

• Große Sprachmodelle (LLMs) sind unvorhersehbare Systeme, die unsichere Eingaben menschlicher Nutzer verarbeiten. Deshalb ist die Anwendung des Least-Privilege-Prinzips unverzichtbar.
• Da LLMs tatsächlich für verschiedenste Aufgaben wie interne Suche und Automatisierung eingesetzt werden, sollten sie nur mit den „effektiven Berechtigungen“ arbeiten, die auf das Minimum beschränkt sind, um Sicherheitsvorfälle und Missbrauch zu verhindern.
• In einer RAG-Architektur (Retrieval-Augmented Generation) müssen Daten-Embeddings und Berechtigungsprüfungen von den Datenquellen getrennt werden; daher ist eine fein granular kontrollierte Zugriffskontrolle auf Ressourcenebene erforderlich.
• Je mehr komplexe Anwendungsfälle wie externe (3rd-party) Daten/RAG, Agents und MCP zunehmen, desto stärker wird die tatsächliche Stelle und Methode der Berechtigungsdurchsetzung zum zentralen Sicherheitsthema.
• Tokenbasierte Authentifizierung wie OAuth hat Grenzen bei der fein granularen Berechtigungssteuerung auf Ressourcenebene; daher muss die eigentliche Berechtigungslogik direkt in der Anwendungsschicht implementiert werden.

---

Begriffe und Grundkonzepte

• Prompt: Die an das LLM übergebene Anfrage des Nutzers (Anweisung, Frage usw.)
• RAG (Retrieval-Augmented Generation): Ein Workflow, der dem Prompt zusätzliche Daten beifügt, um die Genauigkeit der LLM-Antwort zu erhöhen (z. B. automatisches Anhängen einer Firmenurlaubsliste)
• Context: Zusätzliche Daten, die dem Prompt beigefügt werden (z. B. gefundene relevante Materialien)
• Embedding: Numerische Vektordarstellung von Text, genutzt für Datensuche und Matching
• Agent: Eine LLM-basierte Ausführungs-Engine, die anhand des Prompts Aktionen ausführt (z. B. automatisches Aufrufen von Tools)
• Tool: Externe Funktionen wie APIs oder Anwendungen, die ein LLM direkt aufrufen kann
• Model Context Protocol (MCP): Ein von Anthropic vorgeschlagenes Standardprotokoll für den Tool-Zugriff von LLMs

Kernprinzipien des Berechtigungsmodells für LLMs

• Golden Rule:
  > Ein LLM sollte nur mit den minimalen Berechtigungen arbeiten, die für die Verarbeitung der Nutzeranfrage unbedingt notwendig sind.
• Bei menschlichen Nutzern wird ein gewisses Maß an „gewohnheitsmäßiger Überberechtigung“ oft toleriert, aber LLMs sind unvorhersehbar, schnell und können bei Fehlern großen Schaden in großem Umfang anrichten.
  → Die „effektiven Berechtigungen“ eines LLM sollten auf die Schnittmenge aus Nutzer-, LLM- und Task-Berechtigungen beschränkt werden.

Berechnung der effektiven Berechtigungen

• Effektive Berechtigungen einer LLM-Anwendung =
  1. Berechtigungen des LLM
  2. Berechtigungen des Nutzers
  3. Für die angeforderte Aufgabe notwendige Berechtigungen
     die Schnittmenge dieser drei Elemente
• Der Nutzer „delegiert“ seine Rolle an das LLM (z. B. einen Chatbot),
  aber weder die Berechtigungen des LLM noch die des Nutzers dürfen überschritten werden.
• Anschaulich erklärt durch ein Venn-Diagramm für Berechtigungen
  • Die Ausführung ist nur erlaubt, wenn die Task-Berechtigungen vollständig in dieser Schnittmenge enthalten sind.

RAG (Retrieval-Augmented Generation) und Berechtigungsverarbeitung

1. RAG mit 1st-Party-Daten (eigene Daten)

• Beispiel: Ein interner Chatbot soll im firmeninternen Quellcode „Dateien mit geheimen Schlüsseln“ finden.
• Embedding: Alle Dateien werden in Vektoren umgewandelt und in einer DB gespeichert; auch der Prompt wird in einen Vektor umgewandelt und per Ähnlichkeits-Matching abgeglichen.
• Ort der Berechtigungsdurchsetzung:
  • Die tatsächliche besitzende Organisation, Art, das Repository und die Nutzerberechtigungen der als Suchergebnisse zurückgegebenen „Dateien“ werden sofort geprüft.
  • Es wird geprüft, ob der Nutzer auf die betreffende Datei zugreifen darf (Ressourcenberechtigung).
  • Beim Verknüpfen von Embedding und Quelldaten erfolgt die Berechtigungsprüfung in der Anwendungsschicht.
• Berechtigungslogik direkt in das LLM einzubauen, ist instabil (aufgrund seiner probabilistischen Eigenschaften nicht zuverlässig garantierbar).
• Zusammenfassung:
  • Der Kern von RAG ist, nach der Verknüpfung von Embeddings mit den Originaldaten Berechtigungen stark nutzer- und ressourcenbezogen durchzusetzen.

2. RAG mit 3rd-Party-Daten (externe Daten)

• Daten aus externen APIs/Systemen (z. B. Wiki, Ticketsysteme usw.) werden eingebettet und genutzt.
• Problem: Embeddings und Originaldaten befinden sich in unterschiedlichen Systemen → der Ort der Berechtigungsdurchsetzung wird unklar.
• Drei Methoden der Berechtigungsverarbeitung
  1. Berechtigungen an das externe System delegieren (bei jeder einzelnen API-Anfrage echte Berechtigungsprüfung, aber langsame Antwortzeiten und Rate-Limit-Probleme)
  2. ACLs (Access Control Lists) in die Anwendung synchronisieren (hohe Genauigkeit/Zuverlässigkeit, aber höherer Aufwand für ACL-Verwaltung und Synchronisation)
  3. Die externe Berechtigungslogik intern nachimplementieren (höherer Verwaltungs- und Synchronisationsaufwand, steigende Logikkomplexität)
• Fazit: Je nach realer Situation ist der Trade-off bei „Ort und Methode der Berechtigungsdurchsetzung“ entscheidend
  (z. B. Leistung vs. Einfachheit, Verwaltungskosten vs. Genauigkeit).

Agent-basierte LLMs (AI Agents) und Berechtigungen

• Beispiel: Ein Chatbot führt automatische Wartungsaufgaben aus, etwa Branches in einem Repository löschen oder Issues schließen.
• Über MCP (Model Context Protocol) werden Tools (Funktionen/APIs) dem LLM auf standardisierte Weise bereitgestellt.
• Für jede einzelne MCP-Anfrage muss das Modell der effektiven Berechtigungen angewendet werden
  (Schnittmenge aus Nutzer-, Agent- und Task-Berechtigungen).
• Grenzen tokenbasierter Authentifizierung wie OAuth
  • Berechtigungsinformationen sind zwar im Token enthalten, decken aber keine Berechtigungen auf Echtzeit- bzw. Ressourcenebene ab.
  • In der Praxis wird nur ein Teil der Informationen im Token abgelegt; der Rest erfordert separat implementierte Berechtigungslogik in der Anwendungsschicht.

Fazit und praktische Zusammenfassung

• In LLM-/RAG-/Agent-Umgebungen ist der Kern des Berechtigungsmanagements die Wahl von „Ort und Methode der Berechtigungsdurchsetzung“.

• Durch das Modell effektiver Berechtigungen wird das LLM darauf beschränkt, nur innerhalb der Schnittmenge aus „Nutzer + LLM + Task“ zu arbeiten.

• Authentifizierungs-Token wie OAuth dienen nur zur Identifikation im Sinne von „Wer hat die Anfrage gestellt?“;
  die eigentliche Berechtigungsprüfung pro Ressource muss zwingend in der Anwendung erfolgen.

• Bei der Anbindung externer Systeme müssen verschiedene Trade-offs berücksichtigt werden, etwa
  1) Delegation von Berechtigungen (Leistungseinbußen), 2) ACL-Synchronisation (betriebliche Komplexität), 3) Nachimplementierung der Berechtigungslogik (hoher Wartungsaufwand).

• Endgültige Zusammenfassung:
  > Ein LLM sollte nur innerhalb der minimalen Berechtigungen arbeiten, die zur Verarbeitung einer Nutzeranfrage unbedingt erforderlich sind,
  > wobei effektive Berechtigungen als Schnittmenge aus LLM-Berechtigungen, Nutzerberechtigungen und Task-Berechtigungen definiert sind.
  > Die tatsächliche Berechtigungsprüfung muss zwingend pro Ressource in der Anwendungsschicht erfolgen.