Ungoverned RAG Pauzeren

Überblick

Ungoverned RAG bedeutet, Dokumente, Tickets, E-Mails, Wiki Pages, Code oder Database Exports in eine Retrieval-Schicht zu indexieren, ohne Source Permissions, Ownership, Freshness, Provenance, Retention, Quality Checks oder Incident Response zu erhalten. Das Muster ist attraktiv, weil RAG Enterprise Knowledge schnell durchsuchbar macht, dieselbe Pipeline kann aber vertrauliche Inhalte offenlegen, veraltete oder vergiftete Dokumente abrufen und selbstsichere, schwer auditierbare Antworten erzeugen. NVIDIAs AI Red Team berichtet, dass unsichere Access Control in RAG Data Sources wiederkehrend ist, inklusive nicht gepflegter Source Permissions, RAG Stores ohne source-spezifische Permissions, überberechtigte Read Tokens und Permission-Propagation-Delays (NVIDIA AI Red Team).

Die Unterscheidung ist nicht RAG vs. kein RAG, sondern governed vs. ungoverned Retrieval. NISTs Generative AI Profile empfiehlt Dokumentation von Data Origin und Content Lineage, Evaluation von Data/Content Flows, Privacy-Risk Monitoring, Review generierter Sources und Citations und Verifikation, dass RAG-Daten grounded sind (NIST AI 600-1). OWASP warnt, dass Sensitive Information Disclosure PII, Finanzdaten, Health Records, vertrauliche Business Data, Credentials und Legal Documents umfassen kann, und empfiehlt Least-Privilege Access, sichere Runtime-Orchestrierung externer Data Sources, Retention Policies und Data Sanitization (OWASP LLM02: Sensitive Information Disclosure).

Der Grund für Hold: Ungoverned RAG bewegt sich oft schneller als die Controls für vertrauenswürdige und sichere Antworten. RAG löst Halluzination, Prompt Injection, Access Control, Provenance oder Compliance nicht automatisch. OWASP stellt fest, dass RAG und Fine-Tuning Prompt-Injection-Vulnerabilities nicht vollständig mitigieren und bösartiger Content in externen Quellen Modellverhalten ändern kann, wenn er in den Context retrieved wird (OWASP LLM01: Prompt Injection).

Adoptionssignale

• RAG ist Default Enterprise AI Architecture, weil es aktuelle externe Daten ohne Retraining einbinden kann; NVIDIA weist darauf hin, dass der Retrieval Step auch Vektor für attacker-injected Data werden kann (NVIDIA AI Red Team).
• Security Guidance ist von generischen LLM-Warnungen zu RAG-spezifischen Controls gewandert. NVIDIA nennt zwei häufige Schwächen: per-user Read Permissions nicht korrekt implementiert und breiter Write Access auf den RAG Data Store, was indirekte Prompt Injection, Poisoning und Exfiltration Chains ermöglicht (NVIDIA AI Red Team).
• Governance Frameworks schließen RAG explizit in GenAI Risk Management ein. NIST verlangt Dokumentation von RAG Approaches, Provenance von Data Sources, Evaluation von Data/Content Flows, regelmäßiges adversarial Testing, Monitoring auf PII oder sensible Daten und Review von Sources und Citations in Outputs (NIST AI 600-1).
• RAG Evaluation Tooling ist reif genug, dass ungemessene Quality nicht mehr vertretbar ist. LangSmith rahmt RAG Evaluation um Correctness, Relevance, Groundedness und Retrieval Relevance; Ragas listet Metrics wie Context Precision, Context Recall, Response Relevancy, Faithfulness, Answer Accuracy, Context Relevance und Response Groundedness (LangSmith RAG evaluation, Ragas metrics).
• Observability-orientierte Evaluation Practices entstehen. Arize Phoenix trennt Retrieval Evaluation von Response Evaluation, erfasst retrieved Documents in Traces, evaluiert Document Relevance, QA Correctness und Faithfulness und nutzt Traces zum Debuggen, ob schlechte Retrieval oder Generation scheiterte (Arize Phoenix: Evaluate RAG).
• OWASPs LLM Guidance macht klar, dass sichere LLM-Systeme Least Privilege, External-Content-Segregation, Output Validation, menschliche Freigabe für privilegierte Aktionen und adversarial Testing brauchen, inkompatibel mit einem Vector Store, der Source Policy und Runtime User Scope ignoriert (OWASP LLM01: Prompt Injection, OWASP LLM06: Excessive Agency).

Risiken

• Permission Collapse ist der zentrale Failure Mode. Nutzt Ingestion ein breites Service Account oder kann der Vector Store Document-Level Permissions nicht reproduzieren, retrieven Nutzer Inhalte, die sie nie sehen durften; NVIDIA nennt überberechtigte Read Tokens und stale Permission Propagation als häufige Ursachen (NVIDIA AI Red Team).
• Stale Retrieval erzeugt falsche Autorität. RAG-Antworten können veraltete Policies, alte Tickets, ersetzte Verträge oder gelöschte Dokumente zitieren ohne Freshness Rules, Reindexing SLAs, Deletion Propagation und Source Versioning; NIST empfiehlt Tracking von Dataset Modifications, Deletions, Provenance und Content Lineage über den AI Lifecycle (NIST AI 600-1).
• Poisoned Content wird Instruction Channel. OWASP beschreibt indirekte Prompt Injection als bösartige Instruktionen in externen Quellen wie Websites oder Dateien, inklusive eines RAG-Szenarios, in dem ein Angreifer ein Repository-Dokument ändert, damit retrieved Content die Modellausgabe verändert (OWASP LLM01: Prompt Injection).
• Breiter Write Access macht Retrieval zur Angriffsfläche. NVIDIA warnt, dass breiter Write Access auf den RAG Data Store gezielte indirekte Prompt Injection, Application-Result Poisoning und spätere Exfiltration von User Documents oder Personal Data ermöglicht (NVIDIA AI Red Team).
• Ungemessene RAG Quality degradiert still. Ohne Evaluation Datasets, Retrieval Relevance Checks, Groundedness Tests und Response Correctness Scoring erkennen Teams nicht, ob schlechte Antworten von Chunking, schwachem Retrieval, stale Sources, irrelevantem Context oder Halluzination kommen; LangSmith und Phoenix behandeln Retrieval und Response Evaluation getrennt (LangSmith RAG evaluation, Arize Phoenix: Evaluate RAG).
• Compliance lässt sich nachträglich nicht rekonstruieren. Fehlen Logs zu Prompts, abgerufene Chunks, Source Versions, User Identity, Authorization Decisions und generierten Outputs mit passender Retention und Privacy, sind Forensik und Audit Evidence schwach. NIST empfiehlt System Inventories, Provenance Metadata, Monitoring, Incident Response Procedures und Dokumentation von Generated-Content Risks (NIST AI 600-1).
• Risiken nachgelagerter Aktionen verstärken Retrieval-Risiken. Eine RAG-Antwort, die Tools, Agents oder Workflow Automation speist, kann Auswirkungen auf Confidentiality, Integrity und Availability auslösen bei excessive Functionality, Permissions oder Autonomie; OWASP empfiehlt Tools und Permissions zu begrenzen, User Authorization Scope zu tracken, Authorization in nachgelagerten Systemen zu erzwingen und menschliche Freigabe für risikoreiche Aktionen (OWASP LLM06: Excessive Agency).

Empfehlung

Halten Sie Abstand von RAG-Implementierungen, die alles ohne Permissions, Freshness, Ownership, Source Visibility, Retention Rules oder Evaluation in einen Vector Store indexieren. Verbinden Sie keine breiten Enterprise Corpora mit einem General-Purpose Assistant, bis die Retrieval-Schicht für jeden Chunk beantworten kann: wer ihn sehen darf, woher er kommt, wie aktuell er ist und warum er retrieved wurde. Können diese Antworten nicht in Logs gezeigt und automatisch getestet werden, bleibt das System ein Prototyp auf Low-Risk, nicht-sensiblen Quellen.

Nutzen Sie governed Retrieval. Erhalten Sie Source-System Permissions bei Ingestion und Retrieval Time, vermeiden Sie zu breit berechtigte Service Accounts, propagieren Sie Deletions und Permission Changes schnell, kennzeichnen Sie Source Trust Levels, trennen Sie extern schreibbare Inhalte von autoritativen Corpora und filtern Sie abgerufene Chunks vor Generation. Behandeln Sie Source Metadata, Citations, Document Versions, Access Decisions und Retrieval Traces als zentrale Produktionsdaten, nicht als Debug-Extras.

Bauen Sie ein minimales Evaluation- und Operating Model vor Produktion. Pflegen Sie Golden Question-Answer Datasets, adversarial Prompts, poisoned-document Fixtures und Regression Tests für Retrieval Relevance, Context Precision/Recall, Faithfulness, Answer Correctness, Refusal Correctness und Sensitive-Data Leakage. Weisen Sie Source Owners zu, definieren Sie Reindexing- und Retention SLAs, monitoren Sie Retrieval- und Output-Anomalien, üben Sie Incidents und blockieren oder eskalieren Sie Antworten, die nicht in autorisierten, aktuellen, nachvollziehbaren Quellen grounded sind.

Quellen

• NVIDIA AI Red Team: Practical LLM Security Advice
• NIST AI 600-1: Generative AI Profile
• OWASP LLM01: Prompt Injection
• OWASP LLM02: Sensitive Information Disclosure
• OWASP LLM06: Excessive Agency
• LangSmith: Evaluate a RAG application
• Ragas: Available metrics
• Arize Phoenix: Evaluate RAG