Penetrationstests von LLM-Integrationen: warum Standardmaßnahmen bei KI-Anwendungen nicht greifen

2. Juli 2025 · Aktualisiert 25. August 2026

Das Wichtigste in Kürze

Getestet wird nicht das Modell, sondern Ihre Integration: Prompt, Datenquellen, Werkzeuge und die Weiterverarbeitung der Ausgabe
Ein Sprachmodell trennt nicht zwischen Anweisung und Daten - deshalb ist indirekte Prompt Injection über Dokumente die gefährlichste Klasse
Ein WAF greift nicht: der Angriff ist grammatikalisch korrekter Fließtext ohne Signatur
Die tragfähige Absicherung liegt in den Rechten am Werkzeug, nicht im Vertrauen in den Text
Ohne einen zweiten Testnutzer mit anderen Rechten bleibt die wichtigste Befundklasse ungetestet

Ein Chatbot, der nur Texte formuliert, ist ein überschaubares Risiko. Sobald derselbe Chatbot an eine Wissensdatenbank angeschlossen wird, Tickets anlegen darf oder eine API aufruft, ist er kein Chatbot mehr, sondern eine neue Angriffsfläche mit Zugriff auf Ihre Systeme. Genau dieser Sprung ist in den letzten zwei Jahren in nahezu jedem Unternehmen passiert - meist schneller, als die Sicherheitsprüfung nachkam.

Dieser Artikel geht durch, welche Angriffsklassen bei LLM-Integrationen tatsächlich auftreten, warum klassische Schutzmaßnahmen dort nicht greifen, was wir bei einem Penetrationstest von KI- und LLM-Integrationen konkret prüfen und was Sie dafür bereitstellen müssen.

Warum LLM-Anwendungen eine eigene Testdisziplin sind

Bei einer klassischen Anwendung ist die Trennlinie klar: Code ist Anweisung, Eingaben sind Daten. Eine SQL-Injection funktioniert genau deshalb, weil diese Trennung an einer Stelle versehentlich aufgehoben wurde - und sie lässt sich mit vorbereiteten Statements strukturell wieder herstellen.

Bei einem Sprachmodell gibt es diese Trennung konzeptionell nicht. Systemprompt, Nutzerfrage, abgerufene Dokumente und Werkzeugausgaben landen als ein Strom von Token im selben Kontextfenster. Das Modell gewichtet sie statistisch, es erzwingt keine Regel. Es gibt kein Gegenstück zum vorbereiteten Statement.

Daraus folgt der Satz, der die ganze Disziplin zusammenfasst: Jeder Text, der in den Kontext gelangt, ist potenziell eine Anweisung. Ein hochgeladenes PDF, eine verarbeitete E-Mail, ein Kommentarfeld in einem Ticket, eine abgerufene Webseite, ein Datensatz aus der Vektordatenbank.

Die Angriffsklassen, die in der Praxis auftreten

Prompt Injection

Die direkte Variante ist bekannt: Ein Nutzer schreibt „Ignoriere alle vorherigen Anweisungen“ und probiert Formulierungen durch, bis eine durchgeht.

Die indirekte Variante ist die gefährliche. Die Anweisung steht nicht in der Nutzereingabe, sondern in einem Inhalt, den das System selbst holt: in einem hochgeladenen Lebenslauf, in der Signatur einer eingehenden E-Mail, in einer Produktbeschreibung, in einer Webseite, die ein Agent abruft. Der Nutzer gibt nichts Bösartiges ein - er stellt eine harmlose Frage, und das Modell führt die Anweisung eines Dritten aus.

Ein typisches Muster, das wir in Tests reproduzieren: Ein weiß formatierter Absatz in einem Dokument weist das Modell an, den Inhalt der bisherigen Konversation als Bild-URL an eine externe Domain anzuhängen. Der Nutzer sieht eine normale Zusammenfassung. Der Kontext ist abgeflossen. Die Details dieser Klasse dokumentieren wir im Wiki unter Prompt Injection und Markdown Exfiltration Channels.

Zu weit gefasste Handlungsbefugnis

Die Klasse mit der höchsten wirtschaftlichen Auswirkung. Ein Assistent, der Rechnungen bearbeitet, bekommt Schreibrechte auf das ERP. Ein Support-Agent bekommt die Berechtigung, Passwörter zurückzusetzen. Solange das Modell die Anweisungen bekommt, die Sie vorgesehen haben, funktioniert das. Sobald jemand über einen Fremdinhalt hineinschreibt, führt das System dessen Absicht mit Ihren Rechten aus.

Die Prüffrage lautet nie „kann das Modell manipuliert werden“ - das kann es immer -, sondern: was ist das Schlimmste, das eine erfolgreiche Manipulation auslösen kann? Siehe dazu Excessive Agency und Approval Gate Bypass.

Datenabfluss über RAG-Quellen

Der häufigste reale Befund in Unternehmensinstallationen und selten spektakulär: Die Berechtigungen werden nach dem Abruf angewendet statt davor. Der Vektorindex enthält die Dokumente aller Abteilungen, die Filterung passiert erst auf der Ergebnisliste - oder gar nicht.

Ein Mitarbeiter fragt nicht nach einem Dokument, auf das er keinen Zugriff hat. Er fragt: „Fasse zusammen, welche Gehaltsbänder für Teamleitungen gelten.“ Und bekommt eine Antwort. Kein Zugriffsprotokoll zeigt einen Verstoß, weil formal keiner stattgefunden hat.

Dazu kommen Cross-Session Context Bleed, wenn Kontext zwischen Sitzungen oder Mandanten übrig bleibt, und System Prompt Extraction, wenn sich die Anweisungen und häufig auch die eingebetteten Schlüssel und Endpunkte auslesen lassen.

Unsichere Weiterverarbeitung der Ausgabe

Die Ausgabe eines Modells wird routinemäßig behandelt wie eine vertrauenswürdige Antwort - und dann in eine Oberfläche gerendert, in eine Datenbankabfrage eingesetzt oder als Code ausgeführt. Damit ist die klassische Injection wieder da, nur mit dem Modell als Zwischenstation: Wenn das Modell dazu gebracht werden kann, ein <script>-Tag oder ein ; DROP TABLE zu produzieren, ist die Frage nur noch, was das nachgelagerte System damit macht. Siehe Improper Output Handling und Insecure AI-Generated Code.

Vergiftung von Daten und Index

Wenn Ihr System Inhalte automatisch indexiert - freigegebene Ordner, eingehende E-Mails, öffentliche Seiten - kann ein Angreifer Inhalte einspeisen, die dauerhaft im Index liegen und bei künftigen Abfragen als Kontext auftauchen. Der Angriff wird einmal ausgeführt und wirkt danach fortlaufend. Siehe RAG Index Poisoning.

Unbegrenzter Verbrauch

Weniger Vertraulichkeit, mehr Rechnung: Anfragen, die das Modell zu maximal langen Antworten, zu rekursiven Werkzeugaufrufen oder zu wiederholten Abrufen zwingen, treiben die Token-Kosten in die Höhe, ohne dass ein Alarm ausgelöst wird. Wie stark das ausschlagen kann, haben wir im Artikel Denial-of-Wallet-Angriffe auf RAG-Systeme beschrieben.

Warum WAF, Filter und Guardrails nicht reichen

Maßnahme	Was sie leistet	Warum sie hier nicht trägt
Web Application Firewall	Erkennt Signaturen in strukturierten Eingaben	Der Angriff ist grammatikalisch korrekter Fließtext ohne Signatur, in beliebig vielen Formulierungen und Sprachen
Sperrlisten für Schlagwörter	Fängt die naive Formulierung ab	Umschreibung, Silbentrennung, Base64, Emoji oder eine andere Sprache umgehen sie
Guardrail-Modelle	Sinnvolle erste Ebene gegen Standardangriffe	Selbst statistisch - was sich formulieren lässt, lässt sich umformulieren
„Wir nutzen ein sicheres Modell“	Reduziert manche Klassen an der Quelle	Die Befunde entstehen in Ihrer Integration, nicht im Modell
Klassischer Pentest der Anwendung	Deckt die umgebende Webanwendung ab	Prüft die Kette Prompt → Kontext → Werkzeug → Ausgabe nicht

Der Punkt ist nicht, dass diese Maßnahmen nutzlos wären. Der Punkt ist, dass sie alle auf der Text-Ebene arbeiten, und auf der Text-Ebene ist die Grenze nicht durchsetzbar. Durchsetzbar ist sie eine Ebene tiefer: bei den Rechten, mit denen ein Werkzeug ausgeführt wird.

Was wir konkret prüfen

Bereich	Geprüft wird
Systemprompt	Lässt er sich extrahieren, überschreiben oder umgehen? Enthält er Schlüssel, Endpunkte oder Geschäftsregeln, die nicht dorthin gehören?
Direkte Injection	Systematischer Durchlauf von Umgehungsmustern, mehrsprachig, mit Kodierungen und über mehrere Gesprächszüge hinweg
Indirekte Injection	Präparierte Dokumente, E-Mails, Webseiten und Datensätze in jedem Kanal, aus dem das System Kontext bezieht
Autorisierung im Abruf	Werden die Rechte des fragenden Nutzers vor dem Abruf angewendet? Lassen sich Inhalte anderer Mandanten oder Abteilungen rekonstruieren?
Werkzeuge und Agenten	Welche Aktionen sind ohne Freigabe möglich, lässt sich die Freigabe umgehen, eskaliert die Delegation zwischen Agenten?
Ausgabeverarbeitung	Wird die Modellausgabe irgendwo gerendert, ausgeführt oder in eine Abfrage eingesetzt - und ist sie dort behandelt wie nicht vertrauenswürdige Eingabe?
Sitzungsgrenzen	Kontextreste zwischen Sitzungen, Nutzern und Mandanten, Caching-Verhalten
Verbrauchsgrenzen	Rate Limits, Token-Obergrenzen, Rekursionsschutz bei Werkzeugaufrufen
Umgebende Anwendung	Die klassische Testabdeckung nach OWASP WSTG - Authentifizierung, Sitzungsverwaltung, API-Sicherheit

Die Abdeckung orientiert sich an den OWASP Top 10 for LLM Applications; die einzelnen Klassen mit technischer Beschreibung und Behebung stehen in unserem LLM-Wiki.

Ablauf, Aufwand und was Sie bereitstellen

Der Ablauf entspricht dem eines regulären Penetrationstests: Abstimmung von Umfang und Rules of Engagement, Aufklärung, Testdurchführung mit Nachweisen, Vertiefung, Bericht, Retest.

Ein Test einer abgegrenzten Chat- oder RAG-Anwendung umfasst typischerweise 5 bis 10 Personentage. Agentensysteme mit mehreren Werkzeugen liegen darüber, weil jede Werkzeugberechtigung einzeln zu prüfen ist.

Was Sie bereitstellen sollten:

Zugänge für mindestens zwei Nutzer mit unterschiedlichen Berechtigungen. Das ist keine Bequemlichkeit, sondern die Voraussetzung dafür, Autorisierungsfehler überhaupt nachweisen zu können. Ohne den zweiten Nutzer bleibt die häufigste ernsthafte Befundklasse ungetestet.
Eine Liste der angebundenen Werkzeuge und Datenquellen mit den Rechten, unter denen sie laufen.
Den Systemprompt, idealerweise. Wenn Sie ihn nicht herausgeben wollen, extrahieren wir ihn meist ohnehin - dann ist das der erste Befund.
Eine Testumgebung mit realistischen, aber nicht echten Daten.

Was Sie unabhängig vom Test tun sollten

Rechte am Werkzeug, nicht Vertrauen in den Text. Ein Werkzeug läuft mit den Rechten des fragenden Nutzers, nicht mit denen der Anwendung. Alles Weitere ist eine Verteidigung auf der falschen Ebene.
Autorisierung vor dem Abruf. Der Vektorindex darf nur zurückgeben, was der fragende Nutzer ohnehin sehen dürfte - Filterung nach dem Abruf ist keine Zugriffskontrolle.
Freigabe für alles Irreversible. Zahlungen, Löschungen, ausgehende Nachrichten, Rechteänderungen: ein Mensch bestätigt, und die Bestätigung zeigt, was konkret passieren wird.
Modellausgabe ist nicht vertrauenswürdige Eingabe. Überall dort behandeln, wo sie gerendert, ausgeführt oder in eine Abfrage eingesetzt wird.
Protokollieren, was das Modell veranlasst hat, nicht nur, dass es geantwortet hat. Ohne diese Spur ist ein Vorfall nicht rekonstruierbar.
Keine Geheimnisse in den Systemprompt. Er ist kein sicherer Speicher, sondern Kontext.

Wenn Sie KI-Funktionen für ein reguliertes Umfeld einführen: Der Wirksamkeitsnachweis nach NIS2 und die Sicherheitstests nach ISO 27001 Anhang A 8.29 gelten für KI-Komponenten genauso wie für den Rest Ihrer Anwendungslandschaft - eine Sonderregel, die KI ausnimmt, gibt es nicht.

LLM-Penetrationstests - häufige Fragen

Was ist ein LLM-Penetrationstest?

Ein LLM-Penetrationstest prüft nicht das Sprachmodell selbst, sondern Ihre Integration davon: den Systemprompt, die Datenquellen, aus denen der Kontext zusammengesetzt wird, die Werkzeuge und APIs, die das Modell aufrufen darf, und die Stellen, an denen seine Ausgabe weiterverarbeitet wird. Getestet wird, ob sich das Modell dazu bringen lässt, Daten preiszugeben, Berechtigungen zu überschreiten oder Aktionen auszulösen, die es nicht auslösen dürfte.

Was ist Prompt Injection?

Prompt Injection ist das Einschleusen von Anweisungen in Text, den das Modell als Kontext verarbeitet. Weil ein Sprachmodell alle übergebenen Token als einen Gesprächsverlauf betrachtet und keine harte Trennung zwischen Anweisung und Daten kennt, kann eine Anweisung in einem hochgeladenen Dokument, einer verarbeiteten E-Mail oder einer abgerufenen Webseite die ursprünglichen Vorgaben überschreiben. Die indirekte Variante über solche Fremdinhalte ist die gefährlichere, weil der Nutzer selbst nichts Bösartiges eingibt.

Reichen Guardrails und ein WAF nicht aus?

Nein. Eine Web Application Firewall arbeitet mit Signaturen über strukturierte Eingaben; ein Angriff auf ein Sprachmodell ist grammatikalisch korrekter Fließtext ohne Signatur und in beliebig vielen Formulierungen und Sprachen ausdrückbar. Guardrails sind eine sinnvolle erste Ebene, aber sie sind selbst statistisch und lassen sich umformulieren. Die tragfähige Absicherung liegt in der Architektur: Rechte am Werkzeug statt Vertrauen in den Text.

Was wird bei einem Test einer RAG-Anwendung konkret geprüft?

Ob die Zugriffsrechte des fragenden Nutzers auch beim Abruf der Dokumente durchgesetzt werden oder erst danach, ob sich über gezielte Fragen Inhalte aus fremden Mandanten oder Abteilungen rekonstruieren lassen, ob eingespeiste Dokumente Anweisungen an das Modell enthalten können, ob Kontext zwischen Sitzungen übrig bleibt und ob sich der Systemprompt extrahieren lässt.

Wie lange dauert ein LLM-Penetrationstest und was kostet er?

Ein Test einer abgegrenzten Chat- oder RAG-Anwendung umfasst typischerweise 5 bis 10 Personentage. Agentensysteme mit mehreren Werkzeugen und Delegation an weitere Agenten liegen darüber, weil jede Werkzeugberechtigung einzeln geprüft werden muss. Preislich beginnt ein Basistest bei rund 2.000 €; einen Festpreis nennen wir nach einem kurzen Scoping-Gespräch.

Was müssen wir für den Test bereitstellen?

Zugänge für mindestens zwei Nutzer mit unterschiedlichen Berechtigungen - das ist die Voraussetzung, um Autorisierungsfehler überhaupt nachweisen zu können -, eine Beschreibung der angebundenen Werkzeuge und Datenquellen, idealerweise den Systemprompt und eine Testumgebung mit realistischen, aber nicht echten Daten. Ohne den zweiten Nutzer bleibt die wichtigste Befundklasse ungetestet.

Menü