LLM-Pentesting: die neuen Angriffsflächen

Wer KI in eine Anwendung einbaut, vergrößert die Angriffsfläche, oft ohne es zu merken. Ein Sprachmodell verarbeitet Sprache, und Sprache lässt sich manipulieren, auf Wegen, die ein klassischer Penetrationstest gar nicht erst betrachtet. Sobald ein Modell Dokumente liest, Werkzeuge bedient oder im Namen einer Nutzer:in handelt, wird aus einer praktischen Funktion ein mögliches Einfallstor. Deshalb prüfen wir KI-Anwendungen gezielt auf diese neuen Schwachstellen, bevor es jemand anderes tut.

Warum klassische Tests nicht reichen

Klassische Sicherheitstests suchen nach technischen Lücken in Code und Infrastruktur: ein offener Port, eine SQL-Injection, eine fehlende Zugriffsprüfung. Diese Tests bleiben wichtig, greifen bei Sprachmodellen aber zu kurz. Denn hier kommt eine zweite Ebene dazu: Die Sprache selbst wird zur Eingabe und damit zum Angriffsvektor. Eine harmlos aussehende Anweisung in einem Dokument, einer E-Mail oder auf einer Webseite kann ein Modell von seinem eigentlichen Auftrag abbringen.

Drei Eigenschaften machen das Testen anspruchsvoll. Erstens sind Modelle nicht deterministisch: Dieselbe Eingabe kann unterschiedliche Antworten erzeugen, ein Angriff klappt vielleicht erst beim dritten Versuch. Zweitens vermischen sich Anweisung und Inhalt, das Modell unterscheidet nicht zuverlässig zwischen „das ist Kontext" und „das ist ein Befehl". Drittens reicht die Angriffsfläche über das Modell hinaus, in die angebundenen Datenquellen, Werkzeuge und Berechtigungen. Wer nur den Prompt betrachtet, übersieht die Hälfte.

Vier Angriffsflächen, die wir prüfen

1. 01

   Prompt Injection

   Eingeschleuste Anweisungen, die das Modell von seinem eigentlichen Auftrag abbringen, über Eingaben, hochgeladene Dokumente oder Webinhalte. Besonders heikel ist die indirekte Injection, bei der die Anweisung erst in einer Quelle steckt, die das Modell später liest.

2. 02

   Jailbreaks und Guardrail-Umgehung

   Versuche, Schutzregeln auszuhebeln und unerwünschte oder unsichere Ausgaben zu provozieren, etwa über Rollenspiele, Umformulierungen oder das Verschachteln der eigentlichen Absicht in einen harmlosen Kontext.

3. 03

   Datenabfluss und Prompt Leaking

   Abfluss sensibler Daten, interner System-Prompts oder Inhalte aus angebundenen Wissensquellen. Ein Modell, das zu viel Kontext sieht, kann zu viel davon preisgeben.

4. 04

   Agenten- und Tool-Missbrauch

   KI-Agenten, die angebundene Werkzeuge oder Aktionen unbeabsichtigt oder manipuliert auslösen, im schlimmsten Fall mit echten Folgen: eine E-Mail wird verschickt, ein Datensatz geändert, eine Zahlung angestoßen.

Wie wir prüfen

Wir testen entlang realistischer Szenarien, nicht nach Checkliste. Orientierung geben etablierte Kataloge wie die OWASP Top 10 für LLM-Anwendungen, den Rest macht Erfahrung: Wir denken wie ein Angreifer, der eure konkrete Anwendung vor sich hat. Automatisierte Tests decken die Breite ab, manuelle Prüfung die kreativen Fälle, die kein Skript findet. Entscheidend ist der Kontext: Ein Chatbot ohne Anbindung ist etwas völlig anderes als ein Agent mit Schreibrechten im CRM.

Absichern heißt mehr als testen

Ein Test zeigt Lücken, schließt sie aber nicht. Deshalb denken wir die passenden Gegenmaßnahmen gleich mit: eine klare Trennung von Anweisung und Inhalt, minimale Rechte für angebundene Werkzeuge (least privilege), Filterung und Validierung der Ausgaben, ein Mensch als Freigabe vor kritischen Aktionen und Monitoring, das auffälliges Verhalten sichtbar macht. Sicherheit ist kein einmaliger Test, sondern Teil der Architektur.

Am Ende bekommt ihr einen verständlichen Bericht mit priorisierten Maßnahmen: verantwortungsvoll, nachvollziehbar und ohne Alarmismus. Ziel ist nicht, Angst zu machen, sondern eure KI-Anwendung belastbar zu machen, bevor sie in Produktion geht. Mehr dazu, wie wir KI ehrlich und ohne Lock-in einsetzen, lest ihr auf unserer KI-Seite.