Dreißig Jahre lang ruhte Anwendungssicherheit auf einer einfachen architektonischen Annahme: Code ist das eine, Benutzereingaben sind das andere, und die Aufgabe von Sicherheitstests besteht darin, zu prüfen, ob die Grenze zwischen beiden hält. SAST liest den Code. DAST und Pen-Tests prüfen die Eingaben. Fuzzer werfen Müll auf den Parser. Bobby Tables* wird sanitisiert, die Web Application Firewall (WAF) protokolliert den Versuch, das Audit schließt grün ab.
Dieses Modell ist heute auf eine sehr spezifische Weise unvollständig. In einer LLM-Anwendung ist die Grenze zwischen Code und Eingabe nicht erzwungen. Sie ist eine Empfehlung, die das Modell respektieren soll. Manchmal tut es das. Oft auch nicht.
Das ist keine Kritik an klassischen Sicherheitstests. SQL-Injection ist immer noch SQL-Injection, Broken Access Control ist immer noch Broken Access Control, und jede Zeile der OWASP Top 10 für Webanwendungen gilt unverändert für das umgebende System. Der Punkt ist enger gefasst: Das LLM selbst sitzt in diesem System als Komponente, deren Bedrohungsmodell zu nichts passt, was der bestehende Test-Stack jemals zu bewerten gedacht war. Es als bloß einen weiteren Endpunkt zu behandeln ist der Weg, auf dem Unternehmen mit einem sauberen Pen-Test-Bericht und einem Chatbot enden, der dazu überredet werden kann, Kundendaten an Angreifer zu mailen.
Klassische Injection-Schwachstellen existieren, weil Entwickler Daten in eine Steuerungsebene konkateniert haben: einen SQL-Query, einen Shell-Befehl, eine HTML-Seite. Die Lösung war am Ende, beides voneinander zu trennen – Parameterised Queries, Prepared Statements, escaped Output. Der Interpreter hat gelernt, Anweisungen von Daten zu unterscheiden, weil wir ihn dazu gezwungen haben.
LLMs haben diese Trennung nicht. Der System-Prompt, die abgerufenen Dokumente, die Nachricht des Nutzers, die Rückgaben von Tool-Aufrufen – all das kommt beim Modell als ein einziger Strom aus Tokens an. Weil LLMs jeden Inhalt im Prompt als potenzielle Anweisung behandeln, kann bösartiger Text, der in abgerufenen oder externen Daten eingebettet ist, traditionelle Vertrauensgrenzen umgehen. Es gibt kein Äquivalent zu einer Parameterised Query für natürliche Sprache. Es gibt, Stand heute, keine architektonische Lösung.
In der OWASP LLM Top 10 von 2025 wird Prompt Injection als größtes Risiko eingestuft. Dabei wird auch offen darüber diskutiert, warum dies so ist: Aufgrund des stochastischen Charakters, der der Funktionsweise von Modellen zugrunde liegt, ist unklar, ob es überhaupt narrensichere Methoden zur Verhinderung von Prompt Injection gibt. Das Centre for Emerging Technology and Security (CETaS) am Alan Turing Institute hat indirekte Prompt Injection als „den größten Sicherheitsmangel von generativer KI" bezeichnet – und die Formulierung hat sich gehalten, weil bisher niemand ein Gegenbeispiel geliefert hat. Das ist kein vorübergehender Stand der Technik. Es ist eine Eigenschaft, wie diese Technologie funktioniert.
Die praktische Konsequenz: Jede Eingabe an ein LLM ist eine potenzielle Anweisung, und jede Eingabequelle ist ein potenzieller Angreifer. Ein Support-Chatbot, der das hochgeladene PDF eines Kunden zusammenfasst, liest angreifergesteuerte Anweisungen. Ein Agent, der das Web durchsucht, tut dasselbe. Eine RAG-Pipeline, die aus einem Wiki abruft, das jeder im Unternehmen bearbeiten kann, ist genauso betroffen. Klassische Eingabevalidierung hilft hier nicht, denn der schädliche Inhalt ist nicht fehlerhaft – er ist wohlgeformte natürliche Sprache, die nur eben an das Modell adressiert ist und nicht an den Nutzer.
Im Juni 2025 hat Aim Security EchoLeak (CVE-2025-32711, CVSS 9.3) offengelegt – die erste öffentlich dokumentierte Zero-Click-Prompt-Injection gegen ein produktiv eingesetztes Enterprise-LLM-System. Ein Angreifer schickte eine unauffällig wirkende E-Mail an einen Microsoft-365-Copilot-Nutzer. Der Nutzer musste die Mail nie öffnen oder anklicken. Als der Nutzer Copilot später etwas Unzusammenhängendes fragte, holte Copilot die Mail im Rahmen des normalen RAG-Kontextaufbaus ab, und versteckte Anweisungen in der Mail leiteten sensible Unternehmensdaten über einen präparierten Referenz-Link aus, der über eine Microsoft-vertrauenswürdige Domain geroutet wurde. Keine Malware, kein Credential-Diebstahl, kein Buffer Overflow. Die Schwachstelle war kein Speicherfehler – sie bestand darin, dass Copilot seinen Posteingang genau so las, wie er entworfen war, und die Inhalte als Anweisungen behandelte.
Das Muster ist nicht isoliert. Google berichtete von einer relativen Zunahme von 32 % an bösartigen Prompt-Injection-Inhalten in seinen Scans des öffentlichen Webs zwischen November 2025 und Februar 2026. Unit 42 von Palo Alto hat dokumentiert, wie Angreifer indirekte Injection einsetzen, um KI-gestützte Werbeanzeigen-Prüfsysteme zu umgehen. Forscher haben Zero-Click Remote Code Execution gegen MCP-basierte agentische IDEs demonstriert, bei denen ein harmlos aussehendes geteiltes Dokument einen Agenten anweist, vom Angreifer kontrollierte Payloads abzurufen und auszuführen. Die wiederkehrende Form ist immer dieselbe: Die KI wird nicht gehackt. Sie wird angesprochen, von jemandem, der nicht ihr Eigentümer ist – und sie befolgt es.
Ein klassischer Pen-Test prüft das nicht. Er prüft, ob die Anwendung korrekt mit dem umgeht, was ein Angreifer als Nutzer schickt. Er prüft nicht, ob die interne Verarbeitung der Anwendung von Inhalten gekapert werden kann, die die Anwendung selbst abruft. Das ist ein anderer Test, mit anderen Eingaben, anderen Erfolgskriterien und anderen Nachweisen.
Die zweite Diskrepanz ist Determinismus. Eine SQL-Injection-Payload funktioniert oder funktioniert nicht. Wer sie zehnmal gegen denselben Endpunkt laufen lässt, erhält zehnmal dasselbe Ergebnis. Der Test besteht deterministisch, die Regression-Suite bleibt grün, und die WAF-Regel, die ihn fängt, fängt ihn jedes Mal.
LLMs verhalten sich nicht so. Derselbe Prompt kann unterschiedliche Outputs erzeugen – über Läufe hinweg, über Modelle hinweg, über Temperatur-Einstellungen hinweg, je nachdem, wann das letzte Guardrail-Fine-Tuning stattgefunden hat. Promptfoos Red-Team-Evaluation von GPT-5.2, durchgeführt wenige Stunden nach dem Modell-Release im Dezember 2025, meldete, dass die Erfolgsraten von Jailbreaks von einer Baseline von 4,3 % auf 78,5 % in Multi-Turn-Szenarien und 61,0 % in Single-Turn-Szenarien anstiegen. Akademische Übersichten zeigen Erfolgsraten von Prompt Injection von über 90 % gegen ungeschützte Systeme, und die AIShellJack-Studie zu agentischen Coding-Editoren (Cursor, GitHub Copilot) fand Angriffserfolgsraten zwischen 66,9 % und 84,1 % in realistischen Entwicklungsszenarien. Der International AI Safety Report 2026 hält fest, dass Angreifer mit zehn Versuchen aktuelle Schutzmaßnahmen bei Frontier-Modellen immer noch in etwa der Hälfte der Fälle umgehen können.
Das bricht die fundamentalste Annahme klassischer Sicherheitstests: dass eine Schwachstelle eine binäre Sache ist, die man bestätigen und schließen kann. Für ein LLM ist die richtige Maßeinheit nicht „bestanden" oder „nicht bestanden". Es ist eine Rate. Wie oft schafft es dieser Prompt, den System-Prompt zu extrahieren? Wie oft bringt dieses vergiftete Dokument den Agenten dazu, das falsche Tool aufzurufen? Wie oft landet dieser Multi-Turn-Angriff am Ende doch?
Das ist der Grund, warum Injection Success Rate als erstklassige Metrik in ernstzunehmenden LLM-Test-Programmen auftaucht – auch in unserem. Sie spiegelt wider, was das System tatsächlich ist: eine probabilistische Komponente, deren Sicherheitslage statistisch ausgedrückt werden muss. Ein einzelner fehlgeschlagener Versuch beweist nichts. Tausend Versuche, von denen 3 % erfolgreich sind, sagen genau, wie exponiert man ist – und liefern eine Vergleichsbasis über Modellversionen, Prompt-Änderungen und Guardrail-Updates hinweg.
Das verändert auch, was Regressionstests bedeuten. In einem deterministischen System behebt man einen Bug, schreibt einen Test und vertraut darauf, dass der Test ihn wieder fängt. In einem LLM kann derselbe Fix in Version 4.5 halten, in 4.6 schwächer werden und in 4.7 unbemerkt brechen. Kontinuierliche adversariale Evaluation ist nicht optional. Sie ist die einzige Möglichkeit zu wissen, ob die gestrige Mitigation heute noch greift.
Nichts davon macht Pen-Testing, SAST, DAST oder Threat Modelling überflüssig. Das LLM ist eine Komponente in einem Stack, der all das weiterhin braucht. Die LLM Top 10 ersetzt die klassische OWASP Top 10 nicht – sie ergänzt sie. Die Anwendung braucht weiterhin Schutz gegen Broken Access Control, Injection, kryptografische Fehler und alle klassischen Schwachstellen. Eine erfolgreiche Prompt Injection ist für einen Angreifer oft nur deshalb nutzbar, weil es zusätzlich Excessive Agency, schwaches Output Handling oder eine zu großzügig berechtigte Tool-Integration im nachgelagerten System gibt. Diese klassischen Lücken zu schließen bleibt die hebelstärkste Arbeit am System.
Klassische Sicherheitstests gingen von einer festen Grenze zwischen Code und Eingabe aus. LLMs löschen diese Grenze per Design. Solange die Architektur keine Parameterised Query für natürliche Sprache liefert, ist die einzig ehrliche Antwort: kontinuierlich testen, Erfolgsraten statt binärer Urteile messen, und jede Eingabe als potenzielle Anweisung behandeln.
-- Toni Gansel, SPIRIT-TESTING
Was sich ändert: Das LLM selbst braucht eine parallele Test-Disziplin mit drei Eigenschaften, die der klassische Stack nicht liefert.
Adversariale Eingabegenerierung: Jede Datenquelle wird als Angriffsfläche behandelt - nicht nur Nutzer-Eingaben, sondern auch E-Mails, Dokumente, Webseiten, RAG-Korpora, MCP-Tool-Antworten und alles andere, was das Modell verarbeitet.
Probabilistische Messung: Injection Success Rate, Jailbreak Rate, Refusal Consistency - ausgewertet im Maßstab und über Zeit verfolgt, nicht als einmaliges Audit.
End-to-End-Abdeckung des Blast Radius des Agenten: Eine Prompt Injection wirkt nur in dem Maße, in dem das Modell anschließend etwas tun darf. Die schwersten Vorfälle hatten alle Tool-Use, Memory oder ausgehenden Netzwerkzugriff, die den initialen Kompromiss verstärkt haben.
Für die meisten Unternehmen stellt sich nicht die Frage, ob LLM-spezifisches Sicherheitstesten hinzukommen muss, sondern wo es im bestehenden Programm einsortiert wird. Unsere Erfahrung zeigt: Es ersetzt nichts auf der Security-Roadmap, sondern fügt eine zusätzliche Schicht hinzu, für die die bestehende Roadmap nicht ausgelegt war. Pen-Tester finden pen-testbare Bugs. SAST findet Quellcode-Bugs. Keiner von beiden findet jedoch den Fall, in dem ein Angreifer einem Support-Agenten ein PDF mailt, das ihm leise sagt, die nächsten zwanzig Konversationen an eine externe Adresse weiterzuleiten.
Diesen Fall zu finden, ist eine andere Aufgabe. Sie braucht Experten, die die OWASP LLM Top 10 so gut kennen wie Pen-Tester die Top 10 für Webanwendungen. Sie müssen adversariale Korpora für die spezifische Domäne, in der der Chatbot operiert, aufbauen können und die resultierenden Fehlerquoten gegen Schwellenwerte messen können, auf die sich das Business tatsächlich geeinigt hat. Nichts davon ist exotisch. Im Jahr 2026 ist es schlicht das, was Sicherheitstests eines LLM-basierten Produkts ausmachen, wenn sie ernsthaft betrieben werden.
Klassische Tests bleiben notwendig. Sie sind nur nicht mehr ausreichend. Je früher diese Unterscheidung im Sicherheitsprogramm ankommt, desto kleiner ist das Fenster, in dem der nächste Vorfall vom Format EchoLeak jemanden unvorbereitet trifft.
Das Wichtigste zusammengefasst:
Klassische Sicherheitstests prüfen die Grenze zwischen Code und Eingabe. LLMs haben diese Grenze nicht.
Prompt Injection ist kein Bug, der gepatcht werden kann, sondern eine Eigenschaft der Technologie.
Die richtige Messgröße für LLM-Sicherheit ist keine binäre (bestanden/nicht bestanden), sondern eine Rate.
Jede Datenquelle, die ein LLM verarbeitet, ist eine potenzielle Angriffsfläche nicht nur Nutzereingaben.
Klassische Tests bleiben notwendig. Sie sind nur nicht mehr ausreichend.
Lassen Sie uns gemeinsam prüfen, ob Ihr aktuelles Sicherheitsprogramm die Angriffsfläche Ihrer LLM-Anwendungen wirklich abdeckt - mit einer strukturierten Analyse Ihrer bestehenden Test-Disziplinen und einem klaren Bild Ihrer tatsächlichen Risikolage. Sprechen Sie zur LLM-Sicherheit uns an.
Fußnote:
* Bobby Tables: Anspielung auf den XKCD-Comic Nr. 327, der SQL-Injection durch einen Schülernamen illustriert
Quellen zum Blogartikel sind: