Sobald ein KI-Agent E-Mails, Webseiten oder Dateien auswertet und gleichzeitig Werkzeuge bedienen darf, kann eine versteckte Anweisung seinen Auftrag umlenken. OpenAI hat am 15. Juli 2026 GPT-Red vorgestellt: ein internes, automatisiertes Red-Teaming-System, das solche Prompt-Injection-Schwachstellen mit Self-Play suchen soll. Die veröffentlichten Resultate sind aufschlussreich, stammen aber aus klar abgegrenzten Simulationen. Sie belegen weder eine allgemeine Immunität noch reale Angriffe auf Kundensysteme.
Das Wichtigste in 30 Sekunden
- GPT-Red lässt ein angreifendes Modell und verteidigende Modelle über mehrere Runden gegeneinander antreten.
- Die verfügbaren Berichte beschreiben simulierte Umgebungen mit Web-Browsing, E-Mail, Kalender und Code-Bearbeitung.
- 84 gegenüber 13 Prozent, mehr als 90 gegenüber unter 23 Prozent und 3,8 Prozent stammen aus verschiedenen Tests. Sie ergeben keine gemeinsame Sicherheitsquote.
- Für Organisationen bleibt die praktische Aufgabe: Rechte klein halten, externe Inhalte nicht als vertrauenswürdig behandeln und kritische Aktionen kontrollieren.
Was OpenAI mit GPT-Red vorstellt
GPT-Red ist kein Werkzeug für Angreifer und auch kein Produkt, das Unternehmen einfach einschalten können. OpenAI beschreibt damit automatisiertes Red Teaming: Ein Modell soll Wege finden, ein anderes Modell oder einen Agenten von seinen vorgesehenen Regeln abzubringen. Der Zweck ist defensiv. Schwachstellen sollen sichtbar werden, damit Teams sie vor einem Einsatz oder im laufenden Betrieb nachbessern können.
Der Nachrichtenwert liegt in der Methode. OpenAI veröffentlichte den GPT-Red-Beitrag am 15. Juli. Der Originaltext war bei der Recherche im Browser wegen einer Cloudflare-Sperre nicht vollständig zugänglich. Titel, Datum und Veröffentlichungsanker ließen sich über den Suchindex verifizieren. Für Aufbau, Beispiele und Kennzahlen stützt sich dieser Beitrag daher zusätzlich auf zwei direkt gelesene Fachberichte sowie auf die zugängliche GPT-5.6-System Card.
Ein Wettkampf zwischen Angriff und Verteidigung
Self-Play funktioniert wie ein wiederholter Sicherheitscheck. Ein Modell übernimmt die Rolle des Angreifers und entwickelt Eingaben oder Situationen, die einen Agenten fehlleiten könnten. Andere Modelle verteidigen sich dagegen. Danach wird ausgewertet, welche Variante funktioniert hat, welche Schutzmaßnahme greift und was sich beim nächsten Durchlauf ändern muss.
Self-Play in vier Schritten
- Eine simulierte Umgebung bildet Browser, E-Mail, Kalender oder Code-Werkzeuge nach.
- Das Angreifer-Modell sucht nach einer Anweisung, die den Auftrag des Agenten umbiegen könnte.
- Das verteidigende Modell folgt seinen Schutzregeln oder verweigert die problematische Aktion.
- Erfolgreiche und abgewehrte Varianten fließen in den nächsten Test- und Verbesserungszyklus ein.
So lassen sich mehr Varianten erzeugen als mit einem kleinen Team und einzelnen handgebauten Tests. Trotzdem ist das keine Aussage darüber, dass eine reale Unternehmensumgebung schon sicher ist. Die berichteten Szenarien sind Simulationen. Sie dokumentieren keine produktiven Kompromittierungen, keine reale Angriffswelle und keine Übertragbarkeit auf jede Kombination aus Daten, Tools und Berechtigungen.
Warum Prompt Injection bei Agenten heikel ist
Bei einer Prompt Injection steht die problematische Anweisung nicht unbedingt im direkten Chat. Sie kann in einer Webseite, einer E-Mail, einer Datei oder einer Tool-Ausgabe stecken. Ein Agent soll dann etwa seine eigentlichen Regeln ignorieren oder einen anderen Arbeitsschritt ausführen. Die GPT-5.6-System Card beschreibt diesen Angriffstyp als adversariale Anweisung in Tool-Ausgaben, die System-, Developer- oder User-Instruktionen übersteuern soll.
Mit den Rechten des Agenten wächst auch das Risiko. Das BSI weist bei KI-Agenten darauf hin, dass sie mehrschrittig handeln und dafür Zugriff auf Dateien, Apps, Programme oder Onlinedienste erhalten können. Fasst ein Agent nur einen Text zusammen, bleibt der mögliche Schaden klein. Versendet er E-Mails, verändert Kalendertermine oder bearbeitet Dateien, kann eine fehlgeleitete Aktion weiter reichen.
Fake Chain-of-Thought und Vendy: Beispiele, keine Angriffe aus dem Alltag
Die Berichte nennen zwei greifbare Testszenarien. Beim sogenannten Fake Chain-of-Thought kann eine manipulierte Notiz im Arbeitskontext eine falsche Vorannahme vortäuschen. Im Vendy-Fall änderte GPT-Red in einer Demonstration Preise und stornierte eine Kundenbestellung. Beide Fälle stammen aus den von OpenAI beschriebenen Tests. Vendy war kein real kompromittierter Kundenagent, und die Beispiele beweisen nicht, dass jeder Agent auf diese Weise ausnutzbar ist.
Diese Unterscheidung ist zentral. Sicherheitsforschung braucht konkrete, auch unbequeme Demonstrationen. Aus einer Simulation wird aber erst dann eine Aussage über den Alltag, wenn Testmengen, Umgebungen, Rechte und Reproduzierbarkeit offenliegen. Für die hier genannten Vergleiche sind Testmengen, Rohdaten und exakte Nenner im zugänglichen Material nicht vollständig dokumentiert.
Was die veröffentlichten Zahlen messen – und was nicht
| Angabe | Belegter Testkontext | Keine zulässige Deutung |
|---|---|---|
| 84 % gegenüber 13 % | Eine veröffentlichte OpenAI-Messung weist erfolgreiche Angriffe in den beschriebenen GPT-Red-Test-Szenarien mit 84 Prozent gegenüber 13 Prozent für menschliche Red Teams aus. | Keine reale Angriffsprävalenz und keine allgemeine Trefferquote. |
| Mehr als 90 % gegenüber unter 23 % | Ein getrennter, veröffentlichter OpenAI-Vergleich ordnet die stärksten GPT-Red-Angriffe GPT-5 (2025) beziehungsweise GPT-5.6 zu. | Nicht mit dem 84/13-Vergleich oder 3,8 Prozent zusammenführen. |
| 3,8 % | Eine veröffentlichte OpenAI-Messung weist dies als verbleibenden Erfolg stärkerer Prompt Injections aus. | Keine Gesamtfehlerrate, kein Nullrisiko und keine Sicherheitsgarantie. |
| Sechsmal weniger Fehlschläge | Eine veröffentlichte OpenAI-Messung vergleicht direkte Prompt Injections mit dem besten Modell von vier Monaten zuvor. | Keine allgemeine Verbesserung um den Faktor sechs behaupten. |
Die Zahlen widersprechen sich nicht; sie beantworten unterschiedliche Fragen. Einen einzigen Sicherheitswert kann man daraus nicht bilden. Die zugängliche GPT-5.6-System Card enthält außerdem eigene Robustheitstests mit anderen Aufgaben und Metriken. Auch diese Ergebnisse gehören nicht in dieselbe Rechnung.
Was Teams daraus mitnehmen können
GPT-Red verlagert die Sicherheitsprüfung von einzelnen handgebauten Angriffen zu einem fortlaufenden Wettkampf zwischen Angriff und Verteidigung. Das kann mehr Varianten ans Licht bringen. Ob daraus in einem konkreten Unternehmen Schutz entsteht, entscheidet sich erst im Test mit den eigenen Datenquellen, Rechten und Freigaben.
Vier Schutzentscheidungen vor Agentenrechten
- Rechte minimieren: Ein Agent sollte nur auf die Daten und Werkzeuge zugreifen, die er für die konkrete Aufgabe braucht.
- Externe Inhalte abgrenzen: Webseiten, Anhänge und Tool-Ausgaben sind Eingaben, keine vertrauenswürdigen Anweisungen.
- Kritische Aktionen bestätigen: Versand, Löschung, Kauf, Preisänderung oder Rechtevergabe brauchen eine menschliche Freigabe.
- Tests wiederholen: Protokolle und wiederkehrende Red-Team-Tests zeigen, ob neue Tools oder Rechte neue Schwachstellen öffnen.
Aus GPT-Red entsteht keine neue deutsche oder europäische Compliancepflicht. Die Veröffentlichung macht deutlich, warum Sicherheitsarbeit bei Agenten nicht mit einem einmaligen Test erledigt ist. Wer mehr Automatisierung zulässt, muss genauer prüfen, welche Inhalte ein System liest, welche Werkzeuge es steuert und an welcher Stelle ein Mensch eingreift.
Offene Fragen nach der Veröffentlichung
Die offen zugänglichen Berichte lassen offen, wie gut sich die Ergebnisse in reale Arbeitsumgebungen übertragen lassen. Nicht vollständig sichtbar sind unter anderem Testmengen, Rohdaten und die Wirkung bei konkreten Kombinationen aus internen Dokumenten, Drittanbieter-Tools und Berechtigungsketten. Ebenso gibt es keinen Beleg dafür, dass GPT-Red öffentlich verfügbar ist.
Für Sicherheitsverantwortliche ist das dennoch kein Grund, den Ansatz abzutun. Automatisiertes Red Teaming kann helfen, wiederkehrende Tests breiter aufzusetzen. Es ersetzt aber weder sparsame Rechte noch klare Freigaben für riskante Aktionen. Diese Grenzen müssen im jeweiligen System selbst geprüft werden.
Weiterlesen
Quellen und weiterführende Informationen
- OpenAI: GPT-Red: Unlocking Self-Improvement for Robustness
- MIT Technology Review: Meet GPT-Red: an LLM super-hacker OpenAI built to make its models safer
- The Decoder: OpenAI is now using AI to attack its own AI, and it’s working better than humans ever did
- OpenAI Deployment Safety Hub: GPT-5.6 System Card
- BSI: KI-Agenten: Wenn Künstliche Intelligenz selbstständig handelt
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-07-16
