AI red teaming

Was es ist

AI red teaming ist das adversariale Testen eines KI-gestützten Systems: es bewusst so zu manipulieren wie ein Angreifer, um zu sehen, wozu man es drängen kann. Das entscheidende Wort ist System. Ziel ist nicht nur das Sprachmodell, sondern alles drumherum — die Retrieval-Schicht, die Prompt-Kette, die Tools, die es aufrufen kann, der Speicher, den es behält, und die Berechtigungen, mit denen es handelt.

Das ist eine andere Übung als eine Modell-Sicherheitsbewertung, die fragt, ob das Modell unsicheren Text erzeugt. AI red teaming stellt eine schärfere Frage: wozu lässt sich das System in dieser realen Umgebung, mit diesen Integrationen und diesen Berechtigungen, tatsächlich bringen?

Warum klassische AppSec zu kurz greift

Klassische Anwendungssicherheit unterstellt relativ vorhersehbare Grenzen: eine Eingabe kommt, Code verarbeitet sie, eine Ausgabe geht hinaus. Auch komplexe Software blieb beschränkt genug, um mit vertrauten Kontrollen durchdacht zu werden — Code-Review, Scannen, manuelles Testen, Policy-Durchsetzung.

KI-gestützte Anwendungen brechen dieses Modell, weil Verhalten nun von Tools, Retrieval, Speicher und delegierten Berechtigungen abhängt:

• Ein Chatbot kann Informationen aus einer Wissensbasis ziehen.
• Ein Copilot kann Daten aus mehreren internen Systemen zusammenführen.
• Eine LLM-App kann Anweisungen deuten, APIs aufrufen und einen nachgelagerten Workflow auslösen.
• Ein Agent kann all das tun, während er Speicher behält und mit delegiertem Zugriff handelt.

Darum existieren Rahmenwerke wie die OWASP-Listen für LLM- und agentische Anwendungen überhaupt: Diese Systeme tragen Risiken — Tool-Missbrauch, Identitäts- und Privilegienmissbrauch, Memory Poisoning —, die ältere AppSec-Denkweise nicht voll erfasst.

Nicht nur das Modell

Die Idee, die Sicherheitsverantwortliche am meisten verinnerlichen müssen: Ein Angreifer muss das Modell meist nicht besiegen. Oft braucht er nicht einmal, dass es sich sichtbar daneben benimmt. Es genügt, das umgebende System zu missbrauchen — die Retrieval-Schicht, die Prompt-Kette, den Ausführungspfad, das Berechtigungsmodell, den Speicher oder die Anwendungslogik, die eine Ausgabe in eine Aktion verwandelt.

KI-Systeme werden gerade deshalb Teil der Angriffsfläche, weil sie am Schnittpunkt von Daten, Vertrauen, Automatisierung und Aktion sitzen. Ein Scanner findet vielleicht einen Code-Bug. Ein Modell-Red-Team fängt vielleicht eine unsichere Ausgabe. Keiner sagt dir, was ein Angreifer end-to-end in der laufenden Umgebung tun kann — und in dieser Lücke lebt die echte Exposition.

Von schlechter Ausgabe zu schlechtem Ergebnis

KI-Risiko auf „Prompt Injection“ zu reduzieren erfasst nur einen Teil. Im Unternehmen führt manipulierter Kontext zu manipuliertem Verhalten, das zu Datenpreisgabe, gebrochener Autorisierung, unsicherer Tool-Nutzung und Workflow-Missbrauch führt. Das Problem ist nicht mehr eine schlechte Ausgabe, sondern ein schlechtes Ergebnis.

Dies sind erkennbare, wiederkehrende Fehlermuster über Produktions-KI-Systeme hinweg:

• Direkte Prompt Injection gegen einen Copilot.
• Indirekte Injection über eingebetteten oder fremden Inhalt, den das System liest.
• Leck des System-Prompts oder sensibler Instruktionen.
• Mandantenübergreifende Datenpreisgabe zwischen Kunden einer geteilten KI-App.
• Privilegieneskalation über Tool-Ausführungsketten.
• Gebrochene Autorisierung in KI-generierter Geschäftslogik und interne APIs, die bei KI-gestützter Entwicklung exponiert werden.

Keiner dieser Fälle verlangt, dass das Modell im karikaturhaften Sinn „jailbroken“ ist. Es sind gewöhnliche Sicherheitsfehler in neuem Gewand.

Was das Testen wirklich verlangt

Sinnvolles AI red teaming ist kontinuierlich und deckt den ganzen Ausführungspfad ab — Eingabeverarbeitung, Retrieval, Speicher, Tools, Berechtigungen, Geschäftslogik und nachgelagerte Workflows —, denn nur so lässt sich sagen, ob eine Schwäche bloß interessant oder tatsächlich ausnutzbar ist.

Das heißt, die ganze Kette nachzuzeichnen: Kann Prompt-Manipulation das Verhalten ändern; kann das geänderte Verhalten ein Tool auslösen; überschreitet diese Tool-Nutzung eine Grenze; und schafft das Ergebnis echtes Geschäftsrisiko. Es ist Ausnutzbarkeitstesten, keine statische Analyse und kein Modell-Bewertungswert. Und weil Prompts, Modelle, Integrationen und Workflows täglich wechseln, veraltet eine einmalige Bewertung fast sofort — das Testen muss Schritt halten.

Die Fragen, die zählen

Die nützliche Frage für Sicherheitsverantwortliche ist also nicht, ob ein KI-System abstrakt „sicher“ ist. Sie ist operativ, und es ist dieselbe Reihe, die ein Angreifer zuerst testet:

• Lässt sich ein Chatbot dazu manipulieren, eingeschränkte Informationen preiszugeben?
• Kann ein Copilot eine Mandantengrenze überschreiten?
• Lässt sich ein Agent zu einer Aktion drängen, die die Organisation nie wollte?

Das ehrliche Framing ist bescheiden: KI ist eine lebendige operative Schicht — teils Software, teils Entscheidungsmaschine, teils Operator. Die am besten aufgestellten Teams werden weder die sein, die die Einführung bremsen, noch die, die sie als „nur ein weiteres Feature“ behandeln; es werden die sein, die klar genug in diese Schicht sehen, um zu wissen, wozu sie sich bringen lässt, und die sie fortlaufend prüfen, während sie sich ändert.

CyberStrike ist eine KI-gestützte Penetrationstest-Plattform, derzeit im Early Access. AI red teaming auf der Plattform ansehen oder der Warteliste beitreten.