KI-Sicherheits-CTF: reproduzierbare Übungslabore bauen und Agenten-Exploits bewerten

Ein KI-Sicherheits-CTF stellt Teilnehmenden gezielt verwundbare KI-Agenten zur Verfügung, die sie über Prompt Injection, Tool-Missbrauch oder vergiftete Wissensquellen kompromittieren sollen. Wer solche Wettbewerbe selbst aufsetzt, steht vor zwei Kernfragen: Wie wird das Labor reproduzierbar, sodass jede Person dieselbe Ausgangslage vorfindet? Und wie lässt sich ein Exploit fair bewerten, wenn das Zielsystem ein nichtdeterministisches Sprachmodell ist? Dieser Artikel beantwortet beides aus der Praxis des Red Teamings für agentische Systeme.

Was ist ein KI-Sicherheits-CTF und wofür braucht man ihn?

Ein KI-Sicherheits-CTF (Capture the Flag) ist ein Übungsformat, in dem ein bewusst verwundbarer KI-Agent das Angriffsziel bildet. Statt einen klassischen Webserver zu kompromittieren, manipulieren die Teilnehmenden das Verhalten eines Agenten entlang der realen Angriffsfläche von KI-Agenten: Sie bringen ihn dazu, eine geheime Zeichenkette (die Flag) preiszugeben, ein verbotenes Werkzeug aufzurufen oder Daten zu exfiltrieren, die er eigentlich schützen sollte. Der Reiz liegt darin, dass die Angriffsfläche nicht im Code, sondern in der Sprache und im Kontext liegt.

Der praktische Nutzen ist dreifach. Erstens schult ein solches Format Verteidigerinnen und Verteidiger darin, typische Angriffsmuster gegen Agenten konkret zu erkennen, bevor diese in der Produktion auftreten. Zweitens liefert es reproduzierbare Belege dafür, welche Schutzmaßnahmen einem Angriff standhalten und welche nicht. Drittens schafft es ein gemeinsames Vokabular zwischen Entwicklung, Sicherheit und Management, das abstrakte Risiken in greifbare Angriffsschritte übersetzt.

Wichtig ist die Abgrenzung: Ein CTF ist kein Ersatz für ein kontinuierliches Red-Team-Programm, sondern dessen verdichtete, lehrreiche Form und eine Speiche der breiteren Red-Team-Framework-Praxis für KI-Agenten. Er eignet sich hervorragend für Schulungen, interne Wettbewerbe und das Onboarding, ersetzt aber nicht die laufende Beobachtung produktiver Systeme.

Wie baut man ein reproduzierbares Sicherheitslabor für Agenten?

Reproduzierbarkeit bedeutet hier, dass zwei Personen denselben Agenten mit derselben Konfiguration, denselben Werkzeugen und denselben Daten angreifen — und dass ein Lauf von gestern morgen noch dieselbe Ausgangslage hat. Das ist anspruchsvoller als bei klassischen CTFs, weil ein Sprachmodell von Natur aus variierende Antworten erzeugt. Ein reproduzierbares Sicherheitslabor legt deshalb alles fest, was sich festlegen lässt, und macht den Rest transparent.

Konkret heißt das: Modellversion, Systemprompt, Werkzeugdefinitionen, eingebettete Dokumente und die Decodierungsparameter gehören in eine versionierte Konfiguration. Wer mit einem gehosteten Modell arbeitet, notiert die exakte Modellkennung und friert sie ein, da Anbieter ihre Modelle still aktualisieren. Wer maximale Kontrolle braucht, betreibt ein Modell mit offenen Gewichten lokal, etwa über eine containerisierte Laufzeit. Beide Wege sind legitim — entscheidend ist, dass die Wahl dokumentiert und für alle gleich ist.

Drei technische Bausteine haben sich bewährt:

• Containerisierung pro Challenge. Jede Aufgabe läuft in einem eigenen Container mit definiertem Agenten, festgelegten Werkzeugen und einer isolierten Datenablage. So lässt sich der Zustand nach jedem Versuch sauber zurücksetzen.
• Determinismus, wo möglich. Wer die Temperatur auf null setzt und einen festen Seed verwendet, reduziert die Streuung der Modellantworten erheblich. Vollständig deterministisch wird ein LLM dadurch selten, aber die verbleibende Varianz bleibt beherrschbar.
• Zustandsrücksetzung zwischen Versuchen. Gespräche, Dateisysteme und Vektordatenbanken werden nach jedem Angriff in den Ausgangszustand zurückversetzt, damit kein Versuch den nächsten kontaminiert.

Ein häufiger Fehler ist, die Werkzeuge des Agenten nur zu simulieren. Wenn ein Agent eine Datei „lesen“ soll, der Werkzeugaufruf aber nur einen statischen Text zurückgibt, fehlt genau jene Angriffsfläche, die in der Realität zählt. Besser ist es, echte, aber gekapselte Werkzeuge bereitzustellen: ein echtes Dateisystem im Container, eine echte, aber leere Suchschnittstelle, eine echte Datenbank mit präparierten Inhalten.

Welche Challenge-Typen gehören in einen Agenten-CTF?

Ein guter CTF deckt das Spektrum agentischer Schwachstellen ab und steigert sich von leicht erkennbaren zu subtilen Angriffen. Die folgenden Kategorien bilden ein bewährtes Grundgerüst, das sich an den Risikoklassen der OWASP-Liste für LLM-Anwendungen orientiert.

Challenge-Typ	Angriffsidee	Lernziel
Direkte Prompt Injection	Den Systemprompt durch Nutzereingaben überschreiben	Grenze zwischen Anweisung und Daten verstehen
Indirekte Prompt Injection	Schadanweisung in einem vom Agenten gelesenen Dokument verstecken	Vertrauensgrenze zu externen Inhalten erkennen
Tool-Missbrauch	Agent zu einem nicht vorgesehenen Werkzeugaufruf bewegen	Berechtigungen und Werkzeug-Allowlists prüfen
Datenexfiltration	Geheime Kontextdaten über Ausgaben herausschleusen	Ausgabefilter und Geheimnistrennung testen
Rechteausweitung	Über verkettete Werkzeuge mehr Rechte erlangen	Least-Privilege im Agentendesign begreifen
RAG-Vergiftung	Vektorspeicher mit manipulierten Inhalten füttern	Integrität der Wissensbasis absichern

Ein eigenes, reichhaltiges Feld ist die Prompt-Injection-CTF-Disziplin. Hier lohnt sich eine Staffelung: Eine Einstiegsaufgabe gibt die Flag bereits bei naiver Aufforderung preis, eine mittlere Stufe verlangt das Umgehen eines simplen Schlüsselwortfilters, und die Königsdisziplin konfrontiert die Teilnehmenden mit einem Agenten, dem eine zweite Modellinstanz als Ausgabewächter vorgeschaltet ist. Diese Progression vermittelt nicht nur den Angriff, sondern auch, warum oberflächliche Abwehrmaßnahmen scheitern.

Bei indirekter Prompt Injection entfaltet das Format seine größte didaktische Wirkung. Die Teilnehmenden dürfen den Agenten gar nicht direkt anweisen — sie müssen ihre Nutzlast in eine Webseite, eine E-Mail oder ein PDF einbetten, das der Agent im Rahmen seiner Aufgabe verarbeitet — derselbe Aufbau, den ein Prompt-Injection-Red-Team-Labor systematisch durchspielt. Genau dieser Angriffsweg ist in produktiven agentischen Systemen am gefährlichsten und am schwersten zu erkennen, weil die Schadanweisung niemals durch ein Eingabefeld der Angreiferin läuft.

Wie bewertet man die Ausnutzung eines Agenten fair?

Das Scoring ist der Punkt, an dem sich KI-CTFs am stärksten von klassischen unterscheiden. Eine klassische Flag ist ein eindeutiger String, der entweder stimmt oder nicht. Bei einem Agenten kann derselbe Angriff einmal funktionieren und beim nächsten Lauf scheitern, weil das Modell anders antwortet. Ein faires Scoring muss diesen nichtdeterministischen Charakter einkalkulieren, statt ihn zu ignorieren.

Die robusteste Grundlage ist ein zielbasiertes Scoring, bei dem nicht der genaue Wortlaut der Modellantwort zählt, sondern ein überprüfbarer Effekt. Hat der Agent das verbotene Werkzeug tatsächlich aufgerufen? Wurde die Geheimdatei wirklich geöffnet? Erscheint die exakte Flag-Zeichenkette in der Ausgabe? Diese Bedingungen lassen sich maschinell und eindeutig prüfen, weil sie an Werkzeugaufrufe oder an einen festen String gebunden sind, nicht an die Formulierung.

Für die verbleibende Varianz haben sich zwei Verfahren bewährt:

• Best-of-N-Wertung. Ein Exploit gilt als gelungen, wenn er innerhalb einer festgelegten Zahl von Versuchen mindestens einmal die Zielbedingung erfüllt. Das spiegelt die Realität wider, in der eine Angreiferin ihren Angriff schlicht wiederholt.
• Erfolgsquote als Metrik. Statt eines Ja/Nein-Werts wird festgehalten, in wie vielen von N standardisierten Läufen der Angriff greift. Eine Erfolgsquote von 9 zu 10 ist aussagekräftiger als ein einzelner Treffer und erlaubt es, robuste von zufälligen Exploits zu unterscheiden.

Eine reine Bewertung durch ein weiteres Sprachmodell — der sogenannte LLM-as-Judge — ist verlockend, weil sie flexibel ist, für die Punktevergabe in einem Wettbewerb aber riskant. Ein Modell-Richter lässt sich seinerseits durch eine geschickte Nutzlast manipulieren, und seine Urteile streuen. Wer ihn dennoch einsetzt, sollte ihn nur zur Vorsortierung verwenden und jede gewertete Flag durch eine deterministische Prüfung bestätigen.

Transparenz schließt das Scoring-Design ab: Die Teilnehmenden müssen wissen, ob nach Erfolgsquote oder Best-of-N gewertet wird, wie viele Versuche pro Aufgabe erlaubt sind und ab wann ein Effekt als „Exploit“ zählt. Ein verstecktes Bewertungsschema untergräbt die Glaubwürdigkeit des gesamten Wettbewerbs.

Welche Infrastruktur und welche Leitplanken braucht das Labor?

Da ein Agenten-CTF echte Werkzeuge bereitstellt, braucht er eine ernsthafte Eindämmung. Ein erfolgreicher Tool-Missbrauch könnte sonst aus der Übung ausbrechen. Die folgenden Leitplanken sind nicht optional, sondern Voraussetzung für einen verantwortungsvollen Betrieb.

Die Ausführungsumgebung jedes Agenten gehört in eine Sandbox ohne ungefilterten Netzzugang. Werkzeuge, die nach außen wirken — Webabrufe, Dateiversand, Shell-Zugriff —, werden durch gekapselte Stellvertreter ersetzt, die nur innerhalb des Labors agieren. Ein Agent, der eine „E-Mail versendet“, schreibt in Wahrheit in ein internes Postfach, das die Wertung auslesen kann. So bleibt der Angriff real beobachtbar, ohne realen Schaden anzurichten.

Ratenbegrenzung und Protokollierung sind die zweite Säule. Jeder Versuch, jeder Werkzeugaufruf und jede Modellantwort sollten vollständig protokolliert werden — nicht nur für die Wertung, sondern auch, damit Verteidigerinnen hinterher nachvollziehen können, welcher Prompt welchen Effekt ausgelöst hat. Diese Protokolle sind oft der lehrreichste Teil des gesamten Wettbewerbs.

Schließlich gilt eine klare Betriebsregel: Das Labor läuft auf eigener, isolierter Infrastruktur, niemals mit produktiven Zugangsdaten oder echten Kundendaten. Präparierte Geheimnisse und Flags sind erkennbar künstlich, damit sie selbst bei einem Datenabfluss keinen realen Wert besitzen. Diese Trennung schützt sowohl die Organisation als auch die Teilnehmenden.

Wie überführt man CTF-Erkenntnisse in echte Verteidigung?

Ein CTF erzeugt seinen eigentlichen Wert erst in der Nachbereitung. Jeder erfolgreiche Angriff ist ein dokumentierter Angriffsweg, der sich in einen Regressionstest verwandeln lässt. Wer die siegreichen Prompts samt der gemessenen Erfolgsquote archiviert, baut sich nach und nach eine Sammlung realer Angriffsmuster auf, gegen die jede neue Version des produktiven Agenten geprüft werden kann.

Aus dieser Sammlung entsteht idealerweise eine automatisierte Testsuite. Die im Labor festgelegten, reproduzierbaren Aufgaben werden zu wiederholbaren Sicherheitstests im Entwicklungsprozess: Vor jeder Auslieferung läuft der Agent gegen die gesammelten Injektions- und Exfiltrationsversuche, und die Erfolgsquote der Angriffe darf einen festgelegten Schwellenwert nicht überschreiten. So wird aus einem einmaligen Wettbewerb ein dauerhaftes Frühwarnsystem.

Wichtig bleibt die ehrliche Einordnung der Grenzen. Ein CTF prüft die Schwachstellen, die seine Gestalter vorhergesehen haben. Neue Angriffsklassen, die im Wettbewerb nicht abgebildet wurden, bleiben unentdeckt. Deshalb gehört zu einem reifen Programm sowohl der strukturierte CTF als auch das offene, kreative Red Teaming, das bewusst nach dem Unerwarteten sucht. Beide Formate ergänzen einander; keines ersetzt das andere.

Wer ein KI-Sicherheits-CTF aufbaut, investiert also nicht in ein Spiel, sondern in eine messbare, reproduzierbare Disziplin: definierte Labore, faire Bewertung und ein wachsender Bestand an Angriffsmustern, der die Verteidigung agentischer Systeme über die Zeit nachweisbar härtet.