OpenAI überlässt einem Teil des Sicherheitsteams den "ersten Blick" nicht mehr Menschen, sondern dem Modell: Neue Warnmeldungen werden zunächst von der KI vorsortiert, Menschen kümmern sich erst um Entscheidungen mit hoher Tragweite. Am 17. August stellte Greg Brockman dieses Vorgehen in einem Sicherheitsbeitrag öffentlich vor und formulierte eine konkretere Forderung: Sicherheitsteams sollten KI nicht nur nutzen, um mehr Schwachstellen zu finden, sondern auch, um den Weg zur Behebung echter Schwachstellen zu verkürzen.
Es handelt sich nicht um eine eigenständig veröffentlichte Softwarefunktion. Es ist eher eine öffentliche Einordnung von OpenAI zum Tempo automatisierter Angriffe und Verteidigung: Modelle können Schwachstellen, Fehlkonfigurationen und übermäßig berechtigte Identitätsbeziehungen bereits zu Angriffspfaden verketten. Verteidiger, die weiterhin im Tempo klassischer Tickets arbeiten, laufen Gefahr, dass sich der Rückstau schneller zum Risiko entwickelt, als ihre Fähigkeiten mitwachsen.
Zuerst wird die Alarm-Triage automatisiert
OpenAI zufolge durchlaufen heute "fast alle" ersten Sicherheitswarnungen zunächst ein intelligentes System zur Vorsortierung, bevor Menschen hinzugezogen werden. Das Unternehmen verknüpft Erkennungsergebnisse zudem zunehmend mit automatisierten Reaktionen innerhalb klar definierter Grenzen, überlässt Entscheidungen mit großer Tragweite aber weiterhin Menschen.
Im Originalzitat heißt es: "The goal is to ensure we can detect and respond to security issues at machine speed." Vereinfacht gesagt bedeutet das: Die repetitive Vorprüfung, für die Maschinen geeignet sind, wird beschleunigt, während Rechteausweitungen, Änderungen an Produktivsystemen und die Bewertung von Vorfällen weiterhin dem Sicherheitspersonal obliegen.
Das persönliche Beispiel im Beitrag veranschaulicht die Arbeitsweise, die OpenAI fördern möchte: Brockman ließ das öffentlich verfügbare GPT-5.6 Sol seine private statische Website prüfen, wobei in rund 15 Minuten 13 Probleme gefunden wurden; anschließend half das Modell innerhalb von etwa einer Stunde bei der Behebung von Problemen rund um DNS, TLS, Abhängigkeiten und die Migration des Deployments. Das Beispiel stammt vom Firmenchef selbst und sollte nicht als allgemeiner Leistungsmaßstab gelten, zeigt aber die Richtung, in die "Erkennen - Verifizieren - Beheben" zu einem einzigen Arbeitsablauf verdichtet wird.
Zuerst den schmalsten Pfad scannen
OpenAI empfiehlt Unternehmen nicht, direkt ein unbemanntes Security Operations Center aufzubauen. Der vorgeschlagene Weg ist zurückhaltend: zunächst nur einen Lesezugriff auf ein Code-Repository, dann lässt man das Modell bereits geschlossene Warnmeldungen durchsehen; erst wenn sich der Prozess als zuverlässig erwiesen hat, folgen die Prüfung von Pull Requests, die Live-Triage von Warnmeldungen sowie das automatische Schließen klar abgegrenzter Fehlalarme.
Diese Reihenfolge ist bemerkenswert. Die größte Fehlerquelle bei Sicherheitsautomatisierung liegt selten darin, ob ein Modell Anomalien erkennen kann, sondern darin, mit welchen Rechten diese Anomalien verknüpft sind. Der Beitrag verweist wiederholt auf klassische Kontrollen wie minimale Rechtevergabe, Netzwerksegmentierung, Monitoring und sichere Releases. Nachdem KI in den Prozess integriert wurde, verlieren diese Kontrollen nicht an Bedeutung - im Gegenteil, sie müssen umso klarer definiert sein.
Für Entwicklerteams sollte die derzeit überprüfbare Kennzahl nicht nur lauten, "wie viele Probleme das Modell gefunden hat". Aussagekräftiger sind: wie lange es von der Entdeckung bis zur Bestätigung eines hochprioritären Problems dauert, ob Fixes mit Regressionstests einhergehen und ob automatisierte Aktionen stets innerhalb klarer Rechtegrenzen bleiben. Mit seiner neuen Aussage rückt OpenAI diese technischen Kennzahlen stärker in den Vordergrund der Erzählung rund um KI-Sicherheitsprodukte.
Quellen: Sicherheitsbeitrag von OpenAI; CocoLoop; geprüft wurden die KI-Alarm-Triage, die Grenze menschlicher Entscheidungen und das Beispiel der privaten Website.