Wie man RAG-Workflows sichert

RAG-Workflows (Retrieval-Augmented Generation) verbinden KI-Systeme mit den Wissensdatenbanken des Unternehmens, sodass die Abrufautorisierung zur wichtigsten Sicherheitsentscheidung in der Pipeline wird. Ein Agent mit gültigen Anmeldeinformationen kann Dokumente anzeigen, auf die der anfragende Benutzer keinen Zugriff hat, ohne herkömmliche Zugriffskontrolle-Flags auszulösen. Daten- und Modellverteidigungen sind notwendig, aber keine von beiden allein regelt die Abrufberechtigung. Durch die Authentifizierung von Agenten, die Durchsetzung der Autorisierung bei der Abfrage und die Weitergabe des Benutzerkontextes bei jedem Abruf-Hop kann eine Identity Security Fabric, die in einer Identitäts-Kontrollebene verankert ist, zur Absicherung von RAG-Workflows beitragen.

Die drei Ebenen der RAG-Sicherheit

RAG-Workflows bergen Risiken auf drei klar unterscheidbaren Ebenen. Sicherheitshinweise konzentrieren sich häufig auf zwei davon.

Die Daten- und Modellebenen sind zwar essenziell, aber keine beantwortet die RAG-Kernfrage: Ist diese Identität, ob Mensch oder Agent, autorisiert, diese Informationen abzurufen und darauf zu reagieren? In vielen Bereitstellungen sind der technische Zugriff eines Agenten und die tatsächlichen Berechtigungen des anfragenden Benutzers zwei unterschiedliche Dinge. Diese Lücke ist das zentrale Identitätsproblem in der RAG-Sicherheit.

Das RAG-Sicherheitsbedrohungsmodell, zugeordnet zu den OWASP-LLM-Top-10.

Das OWASP Top 10 für LLM-Anwendungen ist ein häufig referenziertes Framework zur Identifizierung von Sicherheitsrisiken in KI-Systemen. Einige der Hauptrisiken haben eine direkte Identity-Dimension in RAG-Architekturen.

Identity Governance ist ein entscheidender Faktor bei jedem dieser Risiken. Ein Agent, der außerhalb seiner Befugnisse handelt, oder die Rechte eines Benutzers, die nachgelagert nicht durchgesetzt werden, können jede dieser Sicherheitslücken in ein Datenleck verwandeln.

So sichern Sie RAG-Workflows Schritt für Schritt

Die Daten- und Modellebenen haben ausgereifte Handbücher. Die folgenden Schritte konzentrieren sich auf die Identity Layer, auf der die meisten RAG-Architekturen immer noch Lücken aufweisen, und behandeln kurz Daten- und Modellkontrollen.

1. Sichern Sie die Datenebene: Aufnahme, Vektorspeicher und Abruf

Die Quellvalidierung filtert Dokumente aus nicht vertrauenswürdigen Quellen heraus, bevor sie den Vektorspeicher erreichen. Die Datenklassifizierung markiert Inhalte bei der Aufnahme nach Sensitivitätsstufe, sodass nachgelagerte Autorisierungsentscheidungen getroffen werden können. Die PII-Filterung verhindert, dass persönlich identifizierbare Informationen eingebettet und indexiert werden, wodurch die Offenlegung reduziert wird, bevor die Abrufautorisierung überhaupt geprüft wird.

Zwei verschiedene Bedrohungen operieren auf dieser Ebene und erfordern separate Abwehrmaßnahmen. Datenmanipulation beschädigt die Knowledge Base während der Aufnahme durch böswillige oder manipulierte Quelldokumente. Indirekte Prompt Injection bettet Anweisungen in ansonsten legitime Inhalte ein, um das Verhalten von Agenten zum Zeitpunkt der Inferenz zu kapern, und wird in Schritt 5 auf der Modellebene behandelt. Identity-Kontrollen sind eine effektive Upstream-Kontrolle gegen indirekte Prompt Injection. Wenn eine Zugriffsrichtlinie ein Dokument einschränkt, ruft der Agent es niemals ab, unabhängig von seinem Inhalt.

Im Vector Store ist Verschlüsselung im Ruhezustand und bei der Übertragung die Grundvoraussetzung. Die Mandantensegmentierung sorgt dafür, dass Einbettungen in Multi-tenant-Architekturen mandantenspezifisch isoliert werden.

Verschlüsselung und Filterung schützen Daten vor Außenstehenden. Sie hindern einen legitimen Agenten nicht daran, Daten abzurufen, auf die der anfragende Benutzer nicht zugreifen sollte. Das ist ein Autorisierungsproblem.

2. Fein abgestufte Autorisierung beim Datenabruf durchsetzen

Grobgranulares RBAC wurde für menschliche Benutzer mit vorhersehbaren Arbeitsfunktionen entwickelt. In einem RAG-Workflow bedeutet die Berechtigung eines Benutzers für einen Ordner nicht, dass er auch für jedes darin enthaltene Dokument berechtigt ist. Rollenbasierte Zugangskontrollen sind zu grob. Zugriffskontrollen auf Dokumentenebene und in einigen Architekturen mit Höchstmaß an Sicherheit erfordern Kontrollen auf Abschnittsebene ein granulareres Richtlinienmodell. Für die RAG-Abfrage kommen zwei etablierte FGA-Ansätze zum Einsatz:

• ReBAC (beziehungsbasierte Zugriffskontrolle) gewährt Zugriff auf der Grundlage der Beziehung des Benutzers zu der Ressource (z. B. Projektmitgliedschaft, Eigentümerschaft oder Organisationshierarchie).
• ABAC (attributbasierte Zugriffskontrolle) bewertet Benutzer-, Ressourcen- und Kontextattribute, die nützlich sind, wenn Entscheidungen von Datenklassifizierungs-Tags abhängen.

Ein wichtiger Unterschied: Die Metadatenfilterung im Vector Store ist ein Richtlinien-Enforcement-Point (PEP), aber der Richtlinien-Decision-Point (PDP) sollte in der Identitätskontrollebene liegen. Der Vektorspeicher setzt Entscheidungen durch, die von der Richtlinien-Engine getroffen wurden; er trifft sie nicht. Die Autorisierung muss vom Abrufer überprüft werden, der mit delegierter Autorität im Namen des Benutzers handelt und nicht nur die eigenen Systemanmeldedaten des Agenten verwendet. Das PDP in das PEP oder in die Zugangsdaten des Retrievers zusammenzufassen, ist ein häufiger architektonischer Ausfall.

3. Identität für KI-Agenten festlegen

KI-Agenten sollten innerhalb des Enterprise Identity Security Fabric als nicht-menschliche Identitäten behandelt werden. Ohne zentrale Identity Governance können sich RAG-Pipeline und die Agent, die sie bedienen, teamübergreifend ohne Inventar, Besitz oder Zugriffskontrolle ausbreiten, wodurch Schatten-KI entsteht. Die Erkennung und das Management der Sicherheitslage nichtmenschlicher Identitäten sind Voraussetzungen für ihre Verwaltung. Sie können Agenten, die Sie nicht inventarisiert haben, nicht Least Privilege aufzwingen. Jeder Agent benötigt eine eindeutige Identity, keine gemeinsamen API-Keys und keine übermäßig berechtigten Service-Accounts.

Wie sich ein Agent authentifiziert, bestimmt das Ausmaß des Schadens, den kompromittierte Anmeldedaten anrichten können. OAuth 2.0-Client-Anmeldedaten und mTLS erfordern beide ein gespeichertes Geheimnis oder Zertifikat, obwohl beide den Wechsel unterstützen. Der Workload-Identitätsverbund macht langlebige gespeicherte Geheimnisse überflüssig. Die Plattform stellt eine signierte Identitätsbestätigung aus, die der Agent gegen ein begrenztes, kurzlebiges Access Token eintauscht. Bei richtiger Implementierung und Rotation bietet jeder Ansatz stärkere Sicherheitseigenschaften als gemeinsame Schlüssel oder Standing Service-Accounts.

4. Verbreiten Sie den Benutzerkontext mit OAuth 2.0 Token-Austausch

In Agentic RAG tritt das verwirrte Stellvertreter-Problem auf, wenn ein Agent mit gültigen Anmeldedaten Daten abruft, für die der anfragende Benutzer nicht berechtigt ist. OAuth 2.0 Token Exchange (RFC 8693) ist eine der standardisierten Antworten. Gemäß RFC 8693 ist das Identitätstoken des Benutzers das Subjekt, und die Identität des Agenten ist der Akteur, wodurch eine überprüfbare Delegationskette entsteht. 

Diese Delegationsanweisung trägt dazu bei, das Problem der verwirrten Stellvertreter zu mindern. Der Agent darf nicht über das hinausgehen, was der Benutzer sehen darf. Der effektive Zugriff ist durch die Rechte des anfragenden Benutzers und weiter durch die autorisierten Bereiche des Agenten eingeschränkt, niemals durch die Vereinigung der beiden. Diese Einschränkung schließt die Autorisierungslücke an jedem einzelnen Schritt.

5. Verteidigen Sie die Prompt- und Output-Ebene

Eingabebereinigung, Ausgabefilterung, Leitplanken und Tool-Call-Validierung werden an der Systemaufforderung und an jeder Stelle angewendet, an der externe Inhalte in das Kontextfenster gelangen. Indirekte Prompt Injection ist das RAG-spezifische Risiko, dem Priorität eingeräumt werden muss. Der Abrufvorgang ist ein autorisierter Pfad, über den nicht vertrauenswürdige Inhalte das Modell erreichen können. Die OWASP Top 10 für LLM-Anwendungen bietet weit verbreitete Implementierungshinweise für diese Ebene.

6. Überwachen, Log und Audit Sie jede Agentenaktion.

Jeder Abruf, jede Aufforderung, jeder Toolaufruf und jede Antwort sollten mit dem Identitätskontext des Agenten protokolliert werden (welcher Agent, der unter wessen Delegation agierte, worauf zugegriffen hat und wann). Compliance-Audits können dann bestätigen, dass die Autorisierungskontrollen durchgesetzt und nicht nur konfiguriert wurden. Die SIEM/SOAR-Integration bringt die RAG-Telemetrie in den umfassenderen Sicherheitsüberwachungs-Stack ein. Die Erkennung von Anomalien in Abrufmustern kann frühe Anzeichen kompromittierter Agenten aufdecken, einschließlich Zugriffs außerhalb des normalen Bereichs, Datenvolumens, das nicht mit den Berechtigungen des initiierenden Benutzers übereinstimmt, oder Abweichungen von etablierten Verhaltensgrundlagen.

7. Wenden Sie Zero Trust im gesamten RAG-Workflow an

In RAG wird Zero Trust hauptsächlich durch identitätsbewusste Autorisierung auf der Abrufebene ausgedrückt, nicht nur durch Netzwerkgrenzen. Vertrauen ist gut, Kontrolle ist besser, auch Anrufe von Agent-zu-Agent innerhalb desselben Workflows. Kurzlebige Tokens, kontinuierliche Autorisierung und die Durchsetzung von Richtlinien bei jedem Hop sind der operative Ausdruck dieses Prinzips. NIST SP 800-207 bietet eine grundlegende Referenz für Zero Trust.

Wenn RAG agentenhaft wird: Was ändert sich für die Sicherheit?

Die sieben oben genannten Kontrollen gelten für jeden RAG-Workflow. Wenn RAG agentenbasiert wird, mehrstufiges Denken, Werkzeugaufrufe und verkettete Agentendelegierung einführt, bietet jeder Schritt eine neue Gelegenheit, Autorisierungslücken zu verschärfen. Die Identity Control Plane sollte den Benutzerkontext bei jedem Sprung weitergeben, einschließlich Anrufen von Agent zu Agent und von Agent zu Anwendung, nicht nur beim ersten Abruf. Standardbasierte Delegationsmuster erweitern den OAuth 2.0 Token Exchange auf Downstream-Aufrufe und stellen sicher, dass kein Agent in der Kette die Berechtigungen des anfragenden Benutzers überschreitet.

Häufige Sicherheitsfehler bei RAG

Viele schwerwiegende RAG-Sicherheitslücken sind vorhersehbare Identity-Fehler, die sich leise verstärken.

• Behandlung der Berechtigungen des Agenten als Benutzerberechtigungen: Der Agent könnte über umfassendere Zugriffsrechte verfügen als der Benutzer, dem er dient. Wenn der Retriever basierend auf den Anmeldeinformationen des Agenten und nicht auf den Berechtigungen des Benutzers handelt, kann er Dokumente zurückgeben, die der Benutzer nie einsehen durfte.
• Sich auf das LLM verlassen, um die Zugriffskontrolle durchzusetzen: Das Modell kann nicht bestimmen, auf was der Benutzer zugreifen darf. Wenn Sie diese Entscheidung in den Prompt verschieben, wird sie vollständig aus der Identitätskontrollebene entfernt.
• Überdimensionierte Service-Accounts für Abrufer: Ein Retriever mit ständigem Lesezugriff auf die gesamte Knowledge Base gibt alles zurück, was semantisch relevant ist, unabhängig von der Person, die die Anfrage gestellt hat.
• Kein Audit-Trail von der Aufforderung über den Abruf bis zur Antwort: Ohne Zuordnung bei jedem Schritt können Datenexpositions-Events nicht untersucht oder gegenüber Prüfern nachgewiesen werden.
• Statische, langlebige Anmeldeinformationen für Agenten: Ein kompromittierter Agent mit langlebigen Anmeldedaten kann über einen längeren Zeitraum unentdeckt operieren und so den Explosionsradius jeder Sicherheitsverletzung erweitern.

Häufig gestellte Fragen

Was ist das größte Sicherheitsrisiko in RAG?

Bei RAG-Bereitstellungen in Unternehmen besteht das größte Risiko in übermäßigen Zugriffsrechten, bei denen ein Agent Daten zurückgibt, zu deren Einsichtnahme der anfragende Benutzer nicht berechtigt ist. Viele RAG-Architekturen sichern die Daten und das Modell, lassen die Abrufebene jedoch ungeschützt vor legitimen Agenten, die über die Rechte des anfragenden Benutzers hinaus handeln.

Wie unterscheidet sich RAG-Sicherheit von herkömmlicher Anwendungssicherheit?

RAG führt nicht-menschliche Identitäten ein, die autonom agieren, eine Abrufebene, die Autorisierungsentscheidungen in Echtzeit erfordert, und die Notwendigkeit, den Benutzerkontext über Agentenketten hinweg zu propagieren. Herkömmliche Zutrittskontrollmodelle wurden für keine dieser Bedingungen konzipiert.

Welche Rolle spielt Identität bei der RAG-Sicherheit?

Die Identität ist eine grundlegende Kontrollebene, die alle drei Ebenen der RAG-Verteidigung verbindet: Daten, Modell und Abruf. Es wird bestimmt, wer, Mensch oder Agent, was abrufen kann, unter welcher delegierten Befugnis, und es wird der Audit-Trail zur Überprüfung bereitgestellt.

Was ist die Berechtigungslücke in RAG?

Die Autorisierungslücke ist der Unterschied zwischen dem, worauf ein KI-Agent technisch zugreifen kann, und dem, was der anfragende Benutzer sehen darf. Es kommt am häufigsten vor, wenn die Anmeldeinformationen eines Agenten die Berechtigungen des Benutzers überschreiten. Der standardbasierte Ansatz kombiniert eine feingranulare Autorisierung auf der Abrufebene mit OAuth 2.0 Token Exchange, sodass jeder Abruf anhand der Berechtigungen des anfragenden Benutzers und nicht anhand der Anmeldeinformationen des Agenten bewertet wird.

Wie wenden Sie Zero Trust auf einen RAG-Workflow an?

Behandeln Sie jeden Abruf, jeden Werkzeugaufruf und jede Interaktion von Agent zu Agent als nicht vertrauenswürdig, bis sie bestätigt wurden. Geben Sie kurzlebige, auf den Gültigkeitsbereich beschränkte Token für jede Aktion aus. Setzen Sie die Richtlinien an jedem Knotenpunkt durch. Der praktische Ausdruck von Zero Trust in RAG ist Autorisierung auf der Abrufebene, nicht Perimeterschutz.

Schützen Sie KI-Agenten und RAG in großem Maßstab mit Okta

Das Schließen der Autorisierungslücke beginnt mit einer Identitätskontrollebene, die menschliche Identitäten, KI-Agenten und die Abrufautorisierung über RAG-Workflows hinweg miteinander verbindet. Die Okta-Plattform hilft Unternehmen, KI-Agenten als nicht-menschliche Identitäten zu verwalten, eine feingranulare Autorisierung auf der Abrufebene durchzusetzen, den Benutzerkontext über agentische Workflows hinweg zu propagieren und einen nachvollziehbaren Audit-Trail vom anfragenden Benutzer bis zur endgültigen KI-Antwort zu unterstützen.

Mehr erfahren

Diese Materialien dienen ausschließlich allgemeinen Informationszwecken und stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Unternehmensberatung dar.

Der Inhalt gibt womöglich nicht den aktuellen Stand der relevanten Sicherheits-, Rechts- und Datenschutzfragen wieder. Es liegt in Ihrer Verantwortung, sich mit Blick auf die Rechtslage, den Datenschutz, die Sicherheit, die Compliance und das Business beraten zu lassen. Stützen Sie sich nicht allein auf diese Materialien.

Okta übernimmt keinerlei Zusicherungen oder Garantien in Bezug auf diesen Inhalt und haftet nicht für Verluste oder Schäden, die aus Ihrer Implementierung dieser Empfehlungen resultieren. Informationen zu den vertraglichen Zusicherungen von Okta gegenüber seinen Kunden finden Sie unter okta.com/agreements.