Ein Chatfenster ist keine Sicherheitsgrenze

Support-Chatbots gelten in vielen Unternehmen noch immer als harmlose Effizienzschicht. Ein bisschen LLM, ein bisschen RAG, ein Chatfenster davor, und schon sollen Kunden schneller Antworten bekommen, Mitarbeiter weniger Tickets schreiben und interne Dokumentation endlich „nutzbar“ werden. Das klingt nach Produktivität. Sicherheitstechnisch ist es oft ein Rückbau. Denn dieselbe Oberfläche hängt plötzlich an verschiedenen Trust-Zonen, und die Trennung soll dann nicht mehr durch Architektur, Berechtigungen und harte Policy-Checks entstehen, sondern durch Sätze wie: Bitte keine internen Informationen an Kunden ausgeben.

Das ist keine belastbare Sicherheitsgrenze. Das ist die Verlagerung einer Autorisierungsfrage in einen Sprachkanal.

Das Problem ist nicht Halluzination, sondern fehlende Zonentrennung

Das Grundmuster ist erstaunlich konsistent:

Ein Unternehmen baut eine gemeinsame Sprachoberfläche.
Diese Oberfläche bedient verschiedene Nutzerklassen: Kunden, normale Mitarbeiter, interne Support-Rollen, teilweise sogar Admin-nahe Workflows.
Im Hintergrund hängt Retrieval auf internen Inhalten oder gleich ein Agent mit zusätzlichen Werkzeugen.
Anschließend soll das Modell aus Sprache ableiten, wer was sehen oder auslösen darf.

Das ist keine neue Sicherheitsarchitektur. Es ist eine alte Grenzverletzung in neuer Verpackung.

RAG erweitert Kontext. Es erweitert nicht Vertrauen.

Ein LLM ist kein Berechtigungssystem. Es ist auch keine belastbare Data-Loss-Prevention-Schicht. Und ein Systemprompt wie „gib niemals interne Inhalte aus“ ist keine technische Grenze, sondern eine Verhaltensanweisung an ein probabilistisches Sprachsystem, das gleichzeitig auf untrusted Input reagieren soll.

Wenn Kunden, Mitarbeiter und interne Wissensbestände über denselben dialogischen Kanal zusammengeführt werden, ist der eigentliche Fehler bereits passiert. Prompt Injection ist dann nicht der überraschende Sonderfall. Sie ist nur die Form, in der das Architekturproblem sichtbar wird.

Die Fälle unterscheiden sich im Detail, nicht in der Fehlerklasse

Die konkreten Vorfälle variieren. Mal geht es um private Kanäle, mal um interne Dateien, mal um sensible Antwortinhalte, mal um aktive Werkzeuge. Die Sicherheitsfrage dahinter bleibt aber bemerkenswert ähnlich: Wird Sprache benutzt, um Grenzen zu rekonstruieren, die technisch getrennt sein müssten?

Slack AI: eine Assistenzschicht über unterschiedlich geschützten Räumen

Bei Slack AI wurde berichtet, dass sich Inhalte aus privaten Channels per Prompt Injection abgreifen ließen. Das ist nicht deshalb relevant, weil ein Modell etwas „Unerlaubtes“ gesagt hat. Relevant ist die Konstruktion: dieselbe Assistenzschicht sitzt über Kommunikationsräumen mit unterschiedlicher Sichtbarkeit, und die semantische Steuerung soll ersetzen, was früher eine harte Trennung war.

Damit wird Sprachverarbeitung in eine Rolle gedrängt, für die sie ungeeignet ist. Sie soll Zugriffskontexte interpretieren, obwohl diese sauber modelliert und technisch durchgesetzt werden müssten.

Microsoft Copilot und Copilot Studio: Prompt-Patches beheben keine überdehnte Reichweite

Beim sogenannten Reprompt-Angriff auf Microsoft Copilot wurde sichtbar, wie schnell aus einem hilfreichen Assistenten ein Datenabflusskanal werden kann. Noch aufschlussreicher ist aber Copilot Studio: Wenn eine Prompt Injection geschlossen wird und der Datenabfluss trotzdem weiter möglich bleibt, dann spricht das eher gegen die Grundarchitektur als für die Notwendigkeit weiterer Prompt-Hygiene.

Man patcht sich hier nicht aus einem isolierten Bug heraus. Man läuft gegen ein Reichweitenproblem. Solange ein Agent oder Assistent zu viel Kontext, zu viele Datenpfade oder zu viele Werkzeuge in einem gemeinsamen Sprachinterface bündelt, bleibt die Oberfläche selbst policy-kritisch.

McKinsey: interner Bot, gleicher Denkfehler

Der McKinsey-Fall ist gerade deshalb nützlich, weil er das Thema aus der reinen Kundenperspektive herausholt. Hier geht es nicht nur um „Kunde sieht Interna“, sondern um die verbreitete Annahme, intern sei dieselbe Konstruktion schon ausreichend sicher.

Das ist sie nicht. Ein interner Chatbot, der breit lesen, suchen oder sogar schreiben kann, ist kein neutrales Komfortwerkzeug. Er ist ein zusätzlicher Zugriffspfad. Und wenn dieser Pfad über natürliche Sprache bedient wird, während Scope-Grenzen weich, indirekt oder nachträglich aufgesetzt sind, entsteht kein sauberer Supportprozess, sondern eine schwer kontrollierbare Seitenschnittstelle.

Lenovo: kundennahes Frontend, zu viel Reichweite im Backend

Beim Lenovo-Fall wird es wieder näher an der klassischen Support-Chatbot-Vorstellung: ein öffentliches oder kundennahes System, das zu viel preisgibt oder zu viel kann. Genau dort ist die Versuchung typischerweise am größten. Marketing will weniger Friktion, Support will weniger Last, Produkt will „smarte“ Antworten, und im Backend werden noch interne Quellen oder Werkzeuge angeschlossen.

Ab diesem Punkt ist das Chatfenster nicht mehr bloß Oberfläche. Es ist ein Zugriffspfad zwischen Zonen mit unterschiedlicher Vertraulichkeit.

Instruktionen sind keine Autorisierung

Das ist der eigentliche Kategorienfehler vieler dieser Systeme.

Sie sind so gebaut, als könne das Modell aus Sprache zuverlässig rekonstruieren:

welche Rolle das Gegenüber tatsächlich hat,
welche Datenklasse betroffen ist,
welche Antwortform zulässig ist,
und ob eine scheinbar harmlose Nachfrage in Wahrheit auf einen Policy-Bruch zielt.

Diese Hoffnung ist nachvollziehbar, weil sie Architekturarbeit in Prompt-Arbeit übersetzt. Sie bleibt trotzdem falsch.

Ein ordentliches System würde nicht fragen: „Kann das Modell höflich genug zwischen intern und extern unterscheiden?“

Es würde fragen:

Warum hängt derselbe Assistent überhaupt an mehreren Zonen?
Warum darf derselbe Retrieval-Pfad Inhalte mit unterschiedlicher Vertraulichkeit sehen?
Warum entscheidet Sprachinterpretation über Datensichtbarkeit?
Warum liegt der Default nicht auf Verweigerung, sobald Scope oder Rolle unklar sind?

Dort sitzt die eigentliche Sicherheitsfrage. Nicht im Prompt.

Support-Chats sind hostile policy surfaces

Das wird besonders gern verdrängt, weil Support kulturell als hilfreicher Kanal wahrgenommen wird. Technisch ist er das nicht. Ein Support-Chat ist eine hostile policy surface.

Dort landen:

Druck,
Mehrdeutigkeit,
falsche Identitätsbehauptungen,
absichtliche Umformulierungen,
Umgehungsversuche,
und jede Menge sozialer Störungen, aus denen ein Modell trotzdem eine saubere Policy-Entscheidung ableiten soll.

Wer in einem solchen Kanal gleichzeitig mit internem Wissen, Kundenkontext und womöglich noch Werkzeugen arbeitet, darf sich über Missbrauch nicht wundern. Das System wurde genau auf den Konflikttyp optimiert, den man an einer Sicherheitsgrenze vermeiden müsste.

Was tragfähiger wäre – und warum es selten beliebt ist

Die nüchterne Antwort ist unerquicklich, aber nicht kompliziert:

getrennte Assistenten oder zumindest hart getrennte Retrieval-Zonen,
keine sensiblen internen Quellen im gleichen Antwortpfad wie Kundenanfragen,
explizite Autorisierung vor sensibler Abfrage oder Aktion,
minimale Fähigkeiten statt Universal-Agent mit maximaler Reichweite,
Eskalation an Menschen, sobald Rolle, Datenklasse oder Absicht nicht sauber feststehen,
und vor allem: weniger Glaube daran, dass Sprachverständnis eine Sicherheitskontrolle ersetzen kann.

Das ist nicht besonders demo-tauglich. Es macht Systeme weniger magisch und deutlich bürokratischer. Genau das ist aber der Preis für belastbare Grenzen. Wer dieselbe Sprachoberfläche gleichzeitig als FAQ, Supportmitarbeiter, Wissensportal und Zugriffspfad auf interne Räume einsetzen will, kauft sich Reichweite auf Kosten von Steuerbarkeit.

Das ist kein KI-Mythos, sondern ein Berechtigungsproblem

Deshalb greift die Standarderzählung so oft daneben. Viele Diskussionen drehen sich sofort um Halluzinationen, Alignment oder Modellgehorsam. Das klingt modern, verdeckt aber häufig ein sehr altes Problem: schlechte Zonentrennung, schlechte Rechtebegrenzung, schlechte Architektur und zu viel Vertrauen in implizites Verhalten.

Das passt ziemlich direkt zu dem, was ich hier schon über Berechtigungen statt KI-Magie und über Gefahr ohne Mystik geschrieben habe: Das Problem entsteht selten dort, wo das Marketing die Magie vermutet. Es entsteht dort, wo alte Kontrollfehler mit maschineller Geschwindigkeit skaliert werden.

Der Support-Chatbot scheitert dann nicht daran, dass die KI plötzlich „böse“ wird. Er scheitert daran, dass Menschen ein System gebaut haben, das Kunden, Mitarbeiter, internes Wissen und aktive Fähigkeiten in denselben Sprachkanal kippt und danach erwartet, dass Statistik die Governance ersetzt.

Das ist keine überraschende Fehlleistung. Es ist ein vorhersehbarer Architekturfehler.

Quellen und Fälle

Für diese Fehlerklasse sind vor allem diese Fälle interessant:

Slack AI: Berichte über Prompt-Injection-bedingte Offenlegung aus privaten Channels
Microsoft Copilot / Reprompt: Datenabfluss über einen sprachgesteuerten Assistenten mit wertvollem Kontext
Microsoft Copilot Studio: Prompt Injection gefixt, Datenabfluss trotzdem weiter möglich
McKinsey: interner Chatbot mit breitem Datei-/Kontextzugriff als Angriffspfad
Lenovo: kundennaher Chatbot mit überzogenen internen Fähigkeiten beziehungsweise zu viel Sensitivität im Backend

Ein paar belastbare öffentliche Einstiegspunkte dazu:

Wer daraus nur den Schluss zieht, dass Prompt Injection „eben ein Risiko“ sei, macht es sich zu leicht. Die belastbarere Lesart ist nüchterner und unangenehmer: Viele Unternehmen behandeln Sprachoberflächen so, als könnten sie Autorisierung, Scope-Trennung und Trust Boundaries nachträglich semantisch rekonstruieren. Das können sie nicht.