10 wesentliche Sicherheitsschichten für robuste RAG-Pipelines

RAG-Pipelines funktionieren oft wie ein offenes Schatzhaus und setzen sensible Daten durch ungeprüfte Eingabeaufforderungen und nicht validierte Ausgaben frei. Ohne mehrschichtige Sicherheit können diese Systeme versehentlich Kreditkartennummern in Protokollen preisgeben, Anweisungsüberschreibungen zulassen oder autoritativ klingende Halluzinationen ohne Quellenangaben erzeugen. Die Lösung besteht nicht nur darin, Schwachstellen zu beheben – sondern eine sicherheitsorientierte Architektur zu schaffen, bei der jede Schicht erkennt, was andere übersehen.

Eine zweistufige Verteidigung: Eingabe- und Ausgabeschutz

Jeder RAG-Workflow lässt sich auf zwei kritische Kontrollpunkte reduzieren: Eingabeschutz, der eingehende Benutzernachrichten bereinigt, und Ausgabeschutz, der Antworten vor der Auslieferung validiert. Diese Phasen bilden eine doppelte Firewall – eine schützt das System vor böswilliger Manipulation, die andere schützt Benutzer vor falschen oder schädlichen Antworten. Keiner dieser Kontrollpunkte ist optional, und das Auslassen eines davon setzt die Pipeline erheblichen Risiken aus.

Eingabeschutz: Absicherung der Grundlage

Die ersten fünf Schichten greifen ein, bevor Abfrage, Neurangierung oder Synthese überhaupt beginnen. Ihr Ziel ist es, zu verhindern, dass schlechte Daten das LLM oder das Einbettungsmodell erreichen.

#### Schicht 1: Validierung von Nachrichtengröße und -struktur

Die grundlegendste, aber wirksamste Schutzmaßnahme ist die Validierung von Größe und Format. Bevor der Inhalt analysiert wird, muss das System Nachrichten ablehnen, die vernünftige Grenzen überschreiten – sei es in Zeichenanzahl, Zeilendichte oder Bytegröße.

def validate_length(message: str, max_chars: int = 10_000) -> bool:
    if not message or not message.strip():
        raise ValueError("Leere Nachricht")

    # UTF-8-Byte-Längenprüfung erkennt Missbrauch von Mehrbyte-Zeichen
    if len(message.encode("utf-8")) > max_chars * 4:
        raise ValueError("Nachricht zu groß")

    if len(message) > max_chars:
        raise ValueError(f"Überschreitet {max_chars} Zeichenlimit")

    # Verhindert Anweisungsstapelung durch übermäßige Zeilenumbrüche
    if message.count("\n") > 50:
        raise ValueError("Zu viele Zeilen")

    return True

Diese Schicht läuft in weniger als einer Millisekunde und stoppt Angriffe, die Unicode-Zeichen missbrauchen, um Größenlimits zu umgehen – wie das Senden von 10.000 Emojis, um eine Speicherüberlastung auszulösen.

#### Schicht 2: PII-Erkennung und -Schwärzung

Sensible Daten wie Kreditkartennummern, E-Mail-Adressen oder Sozialversicherungsnummern sollten niemals ungeprüft in die Pipeline gelangen. Microsofts Presidio-Bibliothek kombiniert Regex, NLP und Kontextbewertung, um PII dynamisch zu erkennen und zu behandeln.

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

def scan_pii(text: str) -> dict:
    results = analyzer.analyze(
        text=text,
        language="en",
        entities=["PHONE_NUMBER", "EMAIL_ADDRESS", "CREDIT_CARD", "US_SSN", "PERSON", "LOCATION", "IP_ADDRESS"],
        score_threshold=0.5
    )
    if not results:
        return {"has_pii": False, "text": text}

    redacted = anonymizer.anonymize(
        text=text,
        analyzer_results=results,
        operators={
            "CREDIT_CARD": OperatorConfig("replace", {"new_value": "<CREDIT_CARD>"}),
            "US_SSN": OperatorConfig("replace", {"new_value": "<SSN>"}),
            "EMAIL_ADDRESS": OperatorConfig("replace", {"new_value": "<EMAIL>"}),
            "PERSON": OperatorConfig("replace", {"new_value": "<PERSON>"}),
        }
    )
    return {
        "has_pii": True,