Leitfaden

LLM-Pentest: die Checkliste für KI-Anwendungen vor dem Livegang

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Ein LLM-Pentest, oft auch AI Security Assessment genannt, prüft eine KI-Anwendung so, wie ein Angreifer sie angehen würde: nicht nur das Sprachmodell, sondern vor allem alles drumherum, also Prompts, angebundene Daten, Werkzeuge und Agenten, Konnektoren, Identitäten und Protokollierung. Die Checkliste dafür umfasst sieben Bereiche: Eingaben und Prompt-Injection, Datenabfluss und Berechtigungen, Tool- und Agentenrechte, Ausgabebehandlung, Lieferkette, Missbrauch und Kosten sowie Protokollierung. Wer diese Bereiche vor dem Livegang geprüft hat und die Befunde den OWASP-Listen für LLM- und Agenten-Anwendungen zuordnen kann, weiß, wo seine KI-Anwendung tatsächlich steht.

Was ein KI-Pentest prüft: das Modell oder die Anwendung?

Die meisten Unternehmen trainieren kein eigenes Modell. Sie binden ein Modell eines Anbieters per API an, geben ihm einen System-Prompt, verbinden es mit eigenen Dokumenten und lassen es Werkzeuge aufrufen. Das Modell selbst können Sie meist nicht ändern. Was Sie in der Hand haben, ist alles, was Sie darum herum gebaut haben. Genau dort setzt ein KI-Pentest an.

Das OWASP GenAI Security Project geht in seiner Top 10 für LLM-Anwendungen davon aus, dass sich ein Modell täuschen lässt. Die Frage ist also nicht, ob jemand das Modell zu einer unerwünschten Antwort bringt, sondern was dann passiert: Welche Daten kann es preisgeben, welche Aktionen auslösen, wohin wandert seine Ausgabe? Ein sinnvoller Scope listet deshalb jede Komponente einzeln auf:

Wichtig für die Abgrenzung: Getestet wird Ihre Anwendung in Ihrer Umgebung, mit schriftlicher Beauftragung. Die Infrastruktur des Modellanbieters gehört nicht dazu. Klären Sie vorab in dessen Nutzungsbedingungen, was bei Tests über die API zu beachten ist.

Die Checkliste: sieben Prüfbereiche

Die folgenden Punkte sind nach Angriffsfläche gegliedert, nicht nach OWASP-Nummer. Die Zuordnung zu den OWASP-Kennungen folgt im nächsten Abschnitt.

1. Eingaben und Prompt-Injection

Prompt-Injection bleibt das Kernrisiko: Ein Text, der wie eine Anweisung aussieht, lenkt das Modell um. Die direkte Variante kommt aus dem Chatfeld, die indirekte aus Inhalten, die die Anwendung selbst liest.

• Alle Eingangskanäle erfasst: Chat, hochgeladene Dateien, abgerufene Webseiten, E-Mails, Tickets, Bilder, Audio, Antworten von Werkzeugen.
• Direkte Umgehungsversuche gegen die Regeln des System-Prompts geprüft, in mehreren Sprachen und Kodierungen.
• Indirekte Injection über jede Quelle geprüft, die ein Dritter beschreiben kann, etwa ein Dokument in der Wissensbasis oder eine eingehende Mail.
• Getestet, was eine erfolgreiche Injection auslösen kann: Daten preisgeben, Werkzeuge aufrufen, Ausgaben manipulieren.

Wie man das methodisch und wiederholbar testet, beschreibt unser Beitrag Prompt-Injection testen. Für die MCP-Variante mit vergifteten Werkzeugbeschreibungen siehe Prompt-Injection und Tool-Poisoning bei MCP.

2. Datenabfluss und Berechtigungen

Ein Modell kennt keine Zugriffsrechte. Es gibt aus, was in seinem Kontext steht. Ob Nutzer A die Dokumente von Nutzer B sehen kann, entscheidet deshalb allein die Anwendung, bevor etwas in den Kontext gelangt.

• Die Suche in der Wissensbasis filtert nach den Rechten des anfragenden Nutzers, nicht nach denen eines Dienstkontos.
• Mandantentrennung mit zwei Testkonten aus verschiedenen Mandanten geprüft, auch in der Vektordatenbank.
• Keine Zugangsdaten, internen Adressen oder vertraulichen Regeln im System-Prompt, denn verborgener Kontext lässt sich oft herauslocken.
• Gedächtnis und Gesprächsverlauf: kein Übertrag zwischen Nutzern oder Sitzungen, der nicht gewollt ist.
• Abflusswege über die Ausgabe geprüft, etwa Links oder Bilder, deren Adresse Daten an einen fremden Server überträgt, sobald die Oberfläche sie lädt.

3. Tool- und Agentenrechte

Sobald das Modell handeln darf, wird jede erfolgreiche Manipulation zu einer Aktion. Hier liegt bei Agenten in der Regel der größte Schaden. Die Grundlagen beschreibt unser Überblick zur KI-Agent-Sicherheit.

• Jedes Werkzeug hat nur die Rechte, die seine Aufgabe braucht. Lesende Agenten haben keine Schreibrechte.
• Destruktive, ausgehende oder kostenpflichtige Aktionen brauchen eine Bestätigung durch einen Menschen, und der Bestätigungsdialog zeigt, was tatsächlich ausgeführt wird.
• Parameter von Werkzeugaufrufen werden serverseitig geprüft, nicht im Prompt.
• Der Agent handelt mit der Identität des Nutzers oder mit eng begrenzten Tokens, nicht mit einem breiten Dienstkonto, über das ein Nutzer mehr erreicht als selbst erlaubt.
• Bei mehreren Agenten: Nachrichten zwischen ihnen sind authentifiziert, und ein Agent übernimmt Anweisungen eines anderen nicht ungeprüft.

4. Ausgabebehandlung

Die Ausgabe eines Modells ist eine Eingabe aus unsicherer Quelle. Wird sie ungeprüft weiterverarbeitet, entstehen klassische Schwachstellen auf neuem Weg.

• Ausgaben, die im Browser landen, werden kodiert oder bereinigt, damit kein Skript ausgeführt wird.
• Ausgaben, die in Datenbankabfragen, Shell-Befehle, Dateipfade oder Vorlagen einfließen, werden wie jede Nutzereingabe behandelt.
• Vom Modell erzeugter Code läuft nur in einer abgeschotteten Umgebung ohne Zugriff auf Geheimnisse und internes Netz.
• Markdown-Darstellung so eingeschränkt, dass keine externen Ressourcen ungefragt geladen werden.

5. Lieferkette, Modelle und Plugins

• Herkunft und Version jedes Modells dokumentiert; Modellwechsel beim Anbieter werden bemerkt und neu getestet.
• Selbst gehostete Modelle und Adapter nur aus nachvollziehbarer Quelle, in Formaten, die beim Laden keinen Code ausführen.
• Plugins, Erweiterungen und MCP-Server geprüft wie jede Fremdsoftware: Wer pflegt sie, welche Rechte verlangen sie, sind Versionen fixiert? Siehe MCP-Server absichern.
• Klar geregelt, wer Inhalte in die Wissensbasis oder Trainingsdaten einspeisen darf, denn jede offene Schreibquelle ist ein Weg für vergiftete Inhalte.

6. Missbrauch und Kosten

OWASP führt unbegrenzten Ressourcenverbrauch als eigenes Risiko (Unbounded Consumption). Bei nutzungsabhängig abgerechneten Modellen bedeutet das: Wer die Anwendung missbraucht, verursacht nicht nur Last, sondern direkt Kosten.

• Ratenbegrenzung je Nutzer, je Schlüssel und je IP-Adresse, auch für nicht angemeldete Zugänge.
• Obergrenzen für Eingabelänge, Ausgabelänge und Kontextgröße.
• Agentenschleifen begrenzt: maximale Zahl an Schritten und Werkzeugaufrufen je Auftrag.
• Budgetgrenzen und Alarme beim Modellanbieter eingerichtet.
• Die Anwendung lässt sich nicht als kostenloser Zugang zum Modell für fremde Zwecke nutzen.

7. Protokollierung und Nachvollziehbarkeit

• Eingaben, abgerufene Quellen, Werkzeugaufrufe und Ergebnisse werden mit Nutzer, Zeitpunkt und Modellversion protokolliert.
• Auffälligkeiten wie gehäufte Ablehnungen, ungewöhnliche Werkzeugaufrufe oder Kostensprünge lösen einen Alarm aus.
• Protokolle enthalten oft personenbezogene und vertrauliche Daten. Zugriff, Aufbewahrung und Löschung sind geregelt.
• Nach einem Testangriff lässt sich aus den Protokollen rekonstruieren, was passiert ist. Genau das sollte der Pentest mitprüfen.

Zuordnung zu OWASP LLM Top 10 und Agentic Top 10

Zwei Listen des OWASP GenAI Security Project bilden den gängigen Ordnungsrahmen: die OWASP Top 10 für LLM-Anwendungen in der Fassung 2026 und die OWASP Top 10 für Agentic Applications für 2026. Die erste betrachtet das Modell als Baustein der Anwendung, die zweite den Agenten, der plant, handelt und sich erinnert. Die Tabelle zeigt, welche Einträge die sieben Prüfbereiche schwerpunktmäßig abdecken. Die Erklärung jedes Eintrags finden Sie in den verlinkten Leitfäden.

Ein Eintrag fehlt bewusst in der Checkliste: LLM07:2026 Misinformation. Ob ein Modell fachlich falsche Antworten gibt, ist eher eine Frage der Qualitätssicherung als eines Angriffs. Relevant für den Pentest wird es dort, wo sich Nutzer oder nachgelagerte Systeme ungeprüft auf Ausgaben verlassen.

Wer zusätzlich einen Rahmen für das Risikomanagement sucht: Das US-amerikanische NIST hat im Juli 2024 das Generative AI Profile veröffentlicht (NIST AI 600-1), ein Begleitdokument zum AI Risk Management Framework (AI RMF 1.0). Es führt Informationssicherheit als eigenes Risiko generativer KI und nennt dabei ausdrücklich Prompt-Injection und Data Poisoning. Als Maßnahmen beschreibt es unter anderem Red-Teaming und unabhängige externe Bewertungen. Das Dokument ist freiwillig anwendbar und ersetzt keinen Test, hilft aber, die Ergebnisse in ein Risikomanagement einzuordnen.

Was ein klassischer Web-Pentest abdeckt und was nicht

Eine KI-Anwendung ist zuerst eine Web-Anwendung mit API. Login, Sitzungsverwaltung, Objektberechtigungen und Schnittstellen müssen genauso geprüft werden wie bei jeder anderen Anwendung, etwa nach unserer API-Pentest-Checkliste. Was ein klassischer Test aber nicht abbildet, ist das Verhalten des Modells als Teil der Anwendung.

Ein methodischer Unterschied kommt hinzu: Modelle antworten nicht immer gleich. Ein Angriff, der beim ersten Versuch scheitert, kann beim fünften gelingen. Ein KI-Pentest wiederholt Angriffe deshalb mehrfach und dokumentiert, wie zuverlässig ein Befund auftritt. Wie ein Pentest grundsätzlich abläuft, beschreibt Penetrationstest: Ablauf, Dauer und Kosten.

Was im Bericht stehen sollte

Ein Bericht über einen KI-Pentest muss für die Geschäftsführung lesbar und für das Entwicklungsteam umsetzbar sein. Achten Sie auf diese Bestandteile:

• Geprüfter Stand. Modell und Version, Stand des System-Prompts, angebundene Datenquellen und Werkzeuge, Testzeitraum und Umgebung. Ändert sich eines davon, ist der Befund neu zu bewerten.
• Der ganze Angriffsweg je Befund. Woher die Eingabe kam, was das Modell daraus gemacht hat, welches Werkzeug oder welche Ausgabe betroffen war und was am Ende passiert ist.
• Reproduktion. Die verwendeten Eingaben im Wortlaut und wie oft der Angriff bei mehreren Versuchen gelang.
• Auswirkung und Schwere. Bezogen auf Ihre Daten und Abläufe, nicht abstrakt.
• Zuordnung. Die passenden OWASP-Kennungen, damit Befunde vergleichbar und nachverfolgbar sind.
• Empfehlung im System. Rechte einschränken, Bestätigung einführen, Ausgabe kodieren, Filter vor den Kontext setzen. „Prompt verbessern“ allein ist selten eine belastbare Maßnahme.
• Nicht Geprüftes. Was ausdrücklich außerhalb des Scopes lag oder aus Zeitgründen nicht getestet wurde.
• Nachtest. Bestätigung, ob die Korrekturen wirken.

Wie ein solcher Bericht konkret aussieht, zeigt unser Musterbericht zu einer geprüften MCP-Anbindung.

So bereiten Sie Ihr Team vor

Je besser die Vorbereitung, desto mehr Prüfzeit fließt in echte Angriffswege statt in Zugangsfragen.

• Scope schriftlich. Welche Anwendung, welche Umgebung, welche Komponenten aus der Tabelle oben, welche Werkzeuge dürfen tatsächlich ausgeführt werden. Schreibende und ausgehende Aktionen am besten in einer Testumgebung.
• Testkonten. Mindestens zwei Konten je Rolle und, bei mandantenfähigen Anwendungen, Konten in zwei verschiedenen Mandanten. Nur so lässt sich prüfen, ob Daten über Grenzen hinweg sichtbar werden.
• Testdaten. Künstliche Daten statt echter Kundendaten, dazu einige Dokumente mit eindeutigen Markierungen. Taucht eine Markierung später an der falschen Stelle auf, ist der Abfluss belegt.
• Einblick in den Aufbau. System-Prompt, Liste der Werkzeuge mit ihren Rechten, Architekturskizze. Ein Test mit diesem Wissen findet in derselben Zeit mehr als ein reiner Blindtest.
• Grenzen und Ansprechpartner. Ein Kostenrahmen für Modellaufrufe während des Tests, Abbruchkriterien und eine erreichbare Ansprechperson.
• Protokolle eingeschaltet. Damit nach dem Test geprüft werden kann, ob Ihr Monitoring die Angriffe gesehen hätte.

Häufige Fragen

Weiterlesen

• AI Red Teaming erklärt
• Die OWASP Top 10 für LLM-Anwendungen 2026, praktisch erklärt
• Die OWASP Top 10 für Agentic Applications, praktisch erklärt
• Prompt-Injection testen
• Leistung: KI-Pentest und MCP-Sicherheit

Quellen

• OWASP GenAI Security Project: Top 10 for LLM Applications 2026
• OWASP GenAI Security Project: Vorstellung der Top 10 for LLM Applications 2026
• OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
• OWASP MCP Top 10
• NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)