Angriffsmöglichkeiten, Systemverhalten und reale Schwachstellen in produktiven KI-Integrationen

Der produktive Einsatz von Large Language Models (LLMs) in Unternehmen nimmt deutlich zu. Dabei reicht das Spektrum von öffentlich erreichbaren Chatbots auf Unternehmenswebsites bis hin zu internen Assistenzsystemen, die auf Wissensdatenbanken, Dokumentenablagen oder proprietäre Datenquellen zugreifen. Technisch betrachtet entstehen dadurch hybride Systeme, die klassische Softwarearchitekturen mit probabilistischen Sprachmodellen kombinieren.

Die Sicherheitsanalyse solcher Systeme unterscheidet sich grundlegend von traditionellen Penetrationstests. Der wesentliche Unterschied liegt im Charakter des Modells selbst: Ein LLM ist eine Blackbox. Der Weg vom Input zum Output ist nicht deterministisch nachvollziehbar. Das Modell berechnet Token-Wahrscheinlichkeiten auf Basis seines Trainings und des aktuellen Kontexts. Welche Teile eines Prompts stärker gewichtet werden, wie interne Sicherheitsinstruktionen priorisiert werden oder wie konkurrierende Anweisungen aufgelöst werden, ist nicht transparente einsehbar - insbesondere bei proprietären Cloud-Modellen.

Diese Intransparenz hat direkte sicherheitstechnische Konsequenzen. Während klassische Software auf klar definierte Kontrollflüsse, Bedingungen und reproduzierbare Logik setzt, reagiert ein LLM kontextsensitiv und statistisch. Zwei nahezu identische Eingaben können unterschiedliche Ausgaben erzeugen. Sicherheitsmechanismen, die rein auf textuelle Instruktionen im Prompt basieren, stellen daher keine robuste technische Isolation dar.

Vom Prompt zur Antwort: Technische Realität

In produktiven Umgebungen wird ein Benutzerinput selten isoliert an das Modell übergeben. Typischerweise entsteht ein zusammengesetzter Prompt, der aus Systemanweisungen, Entwicklerlogik, Benutzeranfrage und gegebenenfalls aus extern abgerufenen Kontextinformationen besteht. Für das Modell ist dies letztlich ein zusammenhängender Textblock. Es existiert keine echte, technisch erzwungene Trennung zwischen „Sicherheitsrichtlinie" und „Benutzereingabe".

Das Modell verarbeitet alles sequenziell als Text. Genau hier liegt der Kern vieler Angriffe.

Prompt Injection als strukturelles Problem

Prompt Injection ist kein klassischer Injection-Angriff im Sinne von SQL oder Command Injection, sondern eine Manipulation der textuellen Entscheidungsgrundlage des Modells. Da Sicherheitsregeln häufig ebenfalls als Text formuliert sind („Beantworte keine vertraulichen Fragen", „Gib keine internen Informationen preis"), kann ein Angreifer versuchen, diese Anweisungen durch neue Instruktionen zu relativieren oder zu überschreiben.

Das Modell besitzt keine inhärente Fähigkeit, zwischen legitimer Policy und schadhafter Anweisung eindeutig zu unterscheiden. Es bewertet Token-Wahrscheinlichkeiten. Wenn eine manipulierte Benutzeranweisung semantisch stark formuliert ist oder geschickt kontextualisiert wird, kann sie die ursprünglich gesetzten Sicherheitsinstruktionen überlagern.

Da der interne Entscheidungsprozess nicht transparent ist, erfolgt die Sicherheitsprüfung hier zwangsläufig adversarial: Man testet systematisch, wie sich konkurrierende Instruktionen auswirken und ob Schutzmechanismen tatsächlich robust sind oder nur scheinbar existieren.

Interne LLMs und das Risiko durch Dokumentenanalyse

Besonders relevant werden diese Fragestellungen bei internen LLM-Systemen, die mit Retrieval-Augmented Generation (RAG) arbeiten. In solchen Architekturen werden Unternehmensdokumente -- etwa PDFs, Office-Dateien, Wiki-Inhalte oder CRM-Daten -- automatisch analysiert, in Text umgewandelt, vektorisiert und in einer Datenbank indexiert.

Wird später eine Benutzeranfrage gestellt, sucht das System semantisch passende Dokumente und fügt deren Inhalte dem Prompt als Kontext hinzu. Das Modell generiert darauf basierend seine Antwort.

Technisch bedeutet das: Der Inhalt von PDF-Dateien wird vollständig extrahiert und dem Modell als Text zur Verfügung gestellt. Dabei gehen visuelle Trennungen, Formatierungen oder semantische Struktur oft verloren. Auch versteckte Textbereiche oder Metadaten können indexiert werden, sofern sie nicht explizit gefiltert werden.

Hier entsteht ein besonders kritisches Angriffsszenario. Wenn ein Angreifer in der Lage ist, manipulierte Inhalte in ein indexiertes Dokument einzubringen -- etwa in ein internes Wiki, ein freigegebenes PDF oder eine gemeinsam genutzte Dokumentenablage -- kann er schadhafte Instruktionen platzieren, die später vom LLM verarbeitet werden.

Da das Modell nicht zwischen „Benutzerprompt" und „Dokumentkontext" unterscheidet, kann eine im PDF platzierte Anweisung Teil der Entscheidungsgrundlage werden. Die eigentliche Angriffsoberfläche ist damit nicht mehr das Chat-Interface, sondern die Dokumentenbasis des Unternehmens.

Ein praxisnahes Szenario ergibt sich im Recruiting-Prozess: Bewerbungen werden häufig über öffentlich erreichbare Webformulare eingereicht. Lebenslauf (CV) und Cover Letter werden als PDF hochgeladen, automatisiert gespeichert und intern abgelegt. Greift die HR-Abteilung später über ein internes LLM-System auf diese Dokumente zu -- etwa zur Zusammenfassung von Profilen oder zum Vergleich von Kandidaten – werden die Inhalte dieser PDFs vom System ausgelesen und verarbeitet.

Platziert ein Angreifer nun gezielt schadhafte Instruktionen im Lebenslauf oder im Anschreiben, können diese über den Dokumenten-Index in das interne LLM gelangen. Der Angriffspfad verläuft damit von einer öffentlich erreichbaren Upload-Funktion über das Dokumentenmanagement bis in ein internes KI-System. Technisch handelt es sich um eine indirekte Injection, die nicht über das Interface des LLM erfolgt, sondern über einen vorgelagerten Geschäftsprozess.

Viele Organisationen berücksichtigen dieses Risiko nicht, da sie davon ausgehen, dass Dokumente lediglich als Informationsquelle dienen. Tatsächlich werden sie jedoch integraler Bestandteil des Prompts und damit potenzieller Angriffsvektor.

Zugriffskontrolle und Datenexfiltration

Ein weiteres strukturelles Problem interner LLM-Systeme liegt in der Zugriffskontrolle. Das Modell selbst kennt keine Berechtigungen. Es verarbeitet lediglich den Kontext, der ihm vom Backend übergeben wird.

Wenn das Retrieval-System Dokumente abruft, ohne eine saubere Dokument-Level-Access-Control durchzusetzen, kann es passieren, dass dem Modell Inhalte übergeben werden, die der anfragende Benutzer eigentlich nicht sehen dürfte. Das Modell wird diese Inhalte dann unter Umständen in seiner Antwort verwenden oder zumindest indirekt darauf referenzieren.

Angriffe erfolgen hier häufig iterativ. Durch geschicktes Nachfragen, Umformulierungen oder Kontextverschiebungen lassen sich Informationen schrittweise rekonstruieren. Selbst wenn keine vollständigen Dokumente ausgegeben werden, können Fragmente oder Zusammenfassungen sensible Inhalte preisgeben.

Das Kernproblem ist architektonisch: Sicherheitslogik darf nicht dem Modell überlassen werden, sondern muss vor der Kontextgenerierung technisch erzwungen werden.

Tool-Integration und aktive Systemeingriffe

Mit der Einführung von Function Calling oder Tool-Integrationen verschiebt sich das Risikoprofil weiter. Das Modell generiert nicht mehr nur Text, sondern strukturierte Aufrufe an Backend-Funktionen. Diese können Datenbankoperationen ausführen, Tickets erstellen oder externe APIs ansprechen.

Wenn solche Funktionsaufrufe nicht strikt validiert und serverseitig autorisiert werden, kann ein Angreifer über manipulierte Prompts indirekt Aktionen auslösen. Besonders kritisch wird es, wenn Backend-Service-Accounts über weitreichende Rechte verfügen und das Modell als Vermittler agiert.

In diesem Kontext wird deutlich: Ein LLM ist kein sicherheitsbewusster Akteur. Es folgt statistischen Mustern. Jede sicherheitsrelevante Entscheidung muss außerhalb des Modells technisch abgesichert sein.

Kontext- und Session-Isolation

Ein weiterer technischer Aspekt betrifft die Verwaltung von Konversationskontexten. Viele Systeme speichern Chat-Historien oder nutzen Caching-Mechanismen, um Antworten effizienter zu generieren.

Wenn Kontextdaten nicht sauber isoliert werden, kann es zu Vermischungen zwischen Nutzern oder Sitzungen kommen. In Multi-Tenant-Umgebungen. stellt dies ein erhebliches Risiko dar. Da das Modell selbst keine Mandantentrennung kennt, muss diese strikt im Backend durchgesetzt werden.

Grundlegende technische Erkenntnis

LLM-Systeme sind keine klassischen Softwarekomponenten mit klarer Entscheidungslogik, sondern probabilistische Textverarbeitungssysteme. Sie besitzen kein intrinsisches Sicherheitsverständnis und keine verlässliche Trennung zwischen Instruktion und Daten.

Sobald interne Dokumente automatisiert analysiert, indexiert und in Prompts integriert werden, erweitert sich die Angriffsfläche erheblich. Manipulierte PDF-Inhalte, indirekte Prompt Injection über Wissensdatenbanken und unzureichende Zugriffskontrollen gehören zu den realistischsten Risiken in produktiven Unternehmensumgebungen.

Die Sicherheitsbewertung solcher Systeme erfordert daher ein architektonisches Verständnis der gesamten Verarbeitungskette – vom Dokumenten-Parsing über Retrieval-Mechanismen bis hin zur Tool-Ausführung.

Der kritische Punkt liegt nicht allein im Modell, sondern in der Art und Weise, wie es mit Daten, Kontext und Systemfunktionen verbunden wird.