Red-Teaming für LLM-Anwendungen: Angriffe simulieren, bevor es andere tun

Jede öffentlich erreichbare LLM-Anwendung wird getestet. Die Frage ist nur, von wem zuerst: von neugierigen Nutzern, die ausprobieren, wozu sich der Assistent überreden lässt, von Wettbewerbern, die Schwächen dokumentieren, oder von Angreifern, die gezielt nach einem Weg zu Daten und Aktionen suchen. Red-Teaming bedeutet, diese Angriffe selbst zu simulieren, systematisch und unter kontrollierten Bedingungen, bevor es andere unter unkontrollierten tun.

Der Unterschied zum klassischen Sicherheitstest liegt in der Angriffsfläche. Bei einer herkömmlichen Anwendung greift man Code und Infrastruktur an. Bei einer LLM-Anwendung kommt eine dritte Fläche hinzu: das Sprachverhalten des Systems selbst. Anweisungen in natürlicher Sprache, präparierte Dokumente, manipulierte Webinhalte, all das sind Eingaben, gegen die keine Firewall hilft. Diese Fläche testet kein herkömmlicher Pentest, und genau deshalb braucht es ein eigenes Vorgehen.

Erst das Schadensmodell, dann die Angriffe

Der häufigste Fehler beim Einstieg ist, mit einer Liste bekannter Jailbreak-Prompts aus dem Netz zu beginnen. Solche Listen testen das Basismodell, nicht die eigene Anwendung. Interessant ist aber die eigene Anwendung: Was kann sie, was darf sie, und was wäre schlimm.

Deshalb beginnt sinnvolles Red-Teaming mit einem Schadensmodell. Welche Daten sind über die Anwendung theoretisch erreichbar, etwa Inhalte anderer Kunden oder interne Dokumente. Welche Aktionen kann sie auslösen, etwa Nachrichten versenden oder Datensätze ändern. Welche Aussagen wären geschäftlich oder rechtlich heikel, etwa verbindlich klingende Zusagen oder Auskünfte außerhalb der eigenen Zuständigkeit. Aus diesem Modell entstehen konkrete Angriffsziele in der Sprache der eigenen Anwendung: den Assistenten dazu bringen, Daten eines anderen Mandanten zu nennen, oder eine Aktion auszulösen, die eine Freigabe erfordert hätte. Erst mit solchen Zielen wird aus Herumprobieren ein Test.

Prompt Injection und Jailbreaks in realistischen Szenarien

Zwei Angriffsklassen verdienen besondere Aufmerksamkeit, und sie werden oft verwechselt. Ein Jailbreak zielt auf das Verhalten des Modells: Der Angreifer versucht über die direkte Eingabe, Regeln und Rollenvorgaben auszuhebeln, etwa durch Rollenspiele, hypothetische Rahmungen oder schrittweises Aufweichen. Eine Prompt Injection zielt auf den Datenfluss: Die feindliche Anweisung steckt nicht in der Nutzereingabe, sondern in Inhalten, die die Anwendung verarbeitet, in einer E-Mail, einem hochgeladenen Dokument, einer abgerufenen Webseite.

Für Anwendungen mit Tool-Zugriff ist die zweite Klasse die gefährlichere. Ein Assistent, der E-Mails liest und beantworten kann, verarbeitet mit jeder E-Mail potenziell fremde Anweisungen, und eine erfolgreiche Injection löst dann nicht nur eine falsche Antwort aus, sondern eine Aktion. Realistisches Red-Teaming testet deshalb beide Wege: direkte Eingaben über alle Kanäle, die Nutzer erreichen, und präparierte Inhalte über alle Kanäle, die die Anwendung liest. Wer nur das Chatfenster testet, testet die halbe Angriffsfläche.

Automatisierte Suiten und manuelle Sessions

Für die Durchführung haben sich zwei Formen etabliert, und sie ersetzen einander nicht. Automatisierte Angriffs-Suiten fahren Kataloge von Angriffsmustern in Varianten gegen die Anwendung und bewerten die Antworten maschinell. Ihre Stärke ist die Breite und die Wiederholbarkeit: Sie laufen bei jedem Release und erkennen, wenn eine früher abgewehrte Technik plötzlich wieder funktioniert. Ihre Schwäche ist die Fantasie, denn sie finden nur Varianten dessen, was im Katalog steht.

Manuelle Sessions bringen genau diese Fantasie ein. Menschen, die die Anwendung und ihren fachlichen Kontext kennen, versuchen in konzentrierten Sitzungen gezielt, die definierten Angriffsziele zu erreichen, und kombinieren dabei Wege, auf die kein Katalog kommt: Fachjargon, mehrstufige Gespräche, Wissen über interne Abläufe. Solche Sessions sind teurer, finden aber regelmäßig die Schwachstellen, die wirklich wehtun. Das Bindeglied zwischen beiden Formen ist einfach: Jeder manuelle Fund wird als Testfall in die automatisierte Suite übernommen und bleibt damit dauerhaft geprüft.

Findings nach Schadenspotenzial priorisieren

Am Ende einer Testrunde steht eine Liste von Funden, und nicht alle sind gleich wichtig. Eine Anwendung, die sich zu einem alberten Gedicht überreden lässt, hat ein anderes Problem als eine, die Daten eines fremden Mandanten preisgibt. Die Priorisierung folgt zwei Achsen: dem tatsächlichen Schaden und dem Aufwand des Angriffs.

Beim Schaden steht Datenabfluss und das Auslösen ungewollter Aktionen ganz oben, gefolgt von falschen oder heiklen Aussagen mit Außenwirkung, erst danach kommen kosmetische Regelverstöße ohne echte Folgen. Beim Aufwand gilt: Was mit einer einzigen simplen Eingabe reproduzierbar gelingt, wiegt schwerer als ein Angriff, der viele Vorbedingungen und Glück erfordert. Jeder Fund braucht dokumentierte Reproduktionsschritte, denn nur ein reproduzierbarer Fund lässt sich beheben und die Behebung überprüfen. Eine Einstufung nach Schweregraden macht die Liste dann zur Arbeitsgrundlage statt zur Sammlung von Anekdoten.

Wiederkehrender Prozess statt Einmal-Audit

Das größte Missverständnis beim Red-Teaming ist der Gedanke, es einmal zu erledigen. Jede Änderung am Prompt, jeder Modellwechsel, jedes neue Tool und jede neue Datenquelle verschiebt die Angriffsfläche. Ein bestandener Test von vor drei Monaten sagt über den heutigen Stand wenig aus.

In der Praxis bewährt sich ein Rhythmus auf drei Ebenen: Die automatisierte Suite läuft an jeden Release gekoppelt, wie andere Tests auch. Manuelle Sessions finden in festen Abständen statt und zusätzlich nach größeren Änderungen, etwa einem neuen Tool mit Schreibrechten. Und Beobachtungen aus der Produktion, gemeldete oder in Logs entdeckte Umgehungsversuche, fließen laufend als neue Testfälle ein. Dazu gehört eine benannte Verantwortlichkeit, denn ein Prozess ohne Besitzer schläft ein, meist genau in dem Quartal, in dem er gebraucht worden wäre.

Fazit

Red-Teaming für LLM-Anwendungen ist kein exotisches Spezialgebiet, sondern die konsequente Übertragung einer alten Einsicht: Systeme testet man gegen die Angriffe, denen sie ausgesetzt sein werden. Der Weg dorthin beginnt beim Schadensmodell der eigenen Anwendung, führt über realistische Tests beider Angriffsklassen, kombiniert automatisierte Breite mit manueller Tiefe und priorisiert Funde nach tatsächlichem Schaden. Vor allem aber ist es ein wiederkehrender Prozess, der sich mit der Anwendung weiterentwickelt. Wer ihn etabliert, erfährt von seinen Schwachstellen aus dem eigenen Testprotokoll. Wer ihn auslässt, erfährt davon aus anderen Quellen, und die suchen sich den Zeitpunkt aus.