KENSAI Forschung: RAG-Backend-Lecks sind ein Architekturfehler, kein Prompt-Unfall

RAG-Systeme leaken nicht, weil ein Prompt einmal komisch wurde. Sie leaken, weil Teams Backend-Verdrahtung, Debug-Spuren und Gesprächsreste an die Client-Schicht durchreichen und das dann Implementierungsdetail nennen.

Warum dieses Signal heute zählt

Ein aktuelles Audit eines medizinischen RAG-Chatbots ist wichtig, weil es zeigte, dass ganz normale, im Client sichtbare Oberflächen Prompts, Konfigurationsdetails, Schemas, Metadaten und sogar benachbarte Gesprächsverläufe offenlegen können. Dafür brauchte es kein spektakuläres Jailbreak-Theater. Neugier plus Browser-Inspektion reichten.

Was tatsächlich kaputt war

Der entscheidende Fehler lag nicht nur in der Modellausgabe. Das Produkt machte Backend-Artefakte über client-seitig einsehbare Pfade sichtbar und verwandelte private Betriebsdetails in öffentliche Hinweise. Ab dann lernen Angreifer, wie das System sensiblen Kontext abruft, routet und speichert.

Warum das ein Architekturbug ist

Wenn Prompts, Routing-Regeln, Retrieval-Metadaten und aktuelle Sitzungs-Spuren zu nah am Frontend liegen, sieht der Nutzer mehr als die Oberfläche beabsichtigt. Das ist kein Formulierungsproblem. Es ist ein Grenzproblem zwischen Zuständen. Lockere Plumbing schafft spätere Chancen für Prompt Injection, Steuerung und Exfiltration.

Was Teams jetzt tun sollten

Reduziert client-sichtbare Metadaten, trennt Debug-Oberflächen von der eigentlichen Nutzerausgabe, lasst flüchtige Spuren schnell verfallen und prüft browser-sichtbare Payloads so, als wären sie feindliche Offenlegungen. Was für die Benutzeraktion nicht nötig ist, darf nicht aus Bequemlichkeit mitgeschickt werden.

Das KENSAI-Fazit

Privatsphäre in Agentensystemen gewinnt man in Interfaces, Headern, Payloads und Zustandsgrenzen. Wenn der Browser mehr sehen kann, als der Nutzer braucht, ist das System bereits zu locker. Sicheres RAG ist auf die richtige Art langweilig: weniger Exposition, engere Nähte, weniger Überraschungen.