OpenAI stoppt Teile der Astra-Entwicklung

OpenAI hat Arbeiten an Teilen seines unveröffentlichten Modells Astra ausgesetzt, nachdem interne Tests einen kritischen Schwellenwert im Bereich Cybersicherheit erreicht haben. Das Modell kann laut Unternehmen eigenständig Schwachstellen finden und Angriffe auf gut geschützte reale Systeme ausführen. Für Unternehmen wirft das die Frage auf, wie viel Kontrolle sie über die KI-Systeme behalten, die sie einsetzen.

OpenAI stoppt Teile der Astra-EntwicklungBild: KI-generiert

Interne Prüfung führt zum Entwicklungsstopp

OpenAI hat die Arbeit an Teilen seines noch unveröffentlichten Modells Astra ausgesetzt. Auslöser war eine interne Sicherheitsüberprüfung, die dem Modell deutliche Fortschritte in zwei Bereichen bescheinigte: agentisches Programmieren, also das eigenständige Schreiben und Ausführen von Code über mehrere Schritte hinweg, und Cybersicherheit.

Nach Angaben des Unternehmens erreichte Astra den kritischen Schwellenwert für Cybersicherheit im sogenannten Preparedness Framework. Dieses interne Regelwerk hat OpenAI 2023 eingeführt, um Fähigkeiten neuer Modelle in Risikostufen einzuteilen. Wird die höchste Stufe erreicht, greifen zusätzliche Schutzmaßnahmen.

Konkret bedeutet die Einstufung: Das Modell kann Sicherheitslücken selbstständig identifizieren und Angriffe gegen real existierende, traditionell gut geschützte Systeme durchführen. OpenAI formuliert das vorsichtig und sinngemäß so, dass die vorläufigen Bewertungen eine ausreichend starke Leistung zeigen, um ein kritisches Fähigkeitsniveau derzeit nicht ausschließen zu können.

"Es ist wichtig, gegenüber der Öffentlichkeit und den Sicherheitsgemeinschaften transparent über diese potenzielle Fähigkeitsverschiebung zu sein." (OpenAI, sinngemäß übersetzt)

Was OpenAI jetzt unternimmt

Das Unternehmen hat nach eigenen Angaben strengere Sicherheitskontrollen eingeführt und alle internen Aktivitäten rund um Astra gestoppt, die diesen verschärften Vorgaben nicht genügen. Wie diese Schutzmechanismen technisch genau aussehen, nennt OpenAI nicht.

Bei der Bewertung des Modells arbeitet das Unternehmen mit zuständigen Regierungsbehörden und ausgewählten Organisationen aus dem Bereich KI-Sicherheit zusammen. Welche Behörden und Organisationen das sind, bleibt offen. Ebenso wenig ist bekannt, wann und in welcher Form Astra überhaupt für Kunden verfügbar sein wird.

Bemerkenswert ist der Zeitpunkt der Veröffentlichung. Unternehmen halten Produkte regelmäßig wegen Sicherheitsbedenken zurück, kommunizieren das aber selten öffentlich, solange sich das Produkt noch in der Entwicklung befindet.

Der Kontext: Modelle, die aus ihrer Sandbox ausbrechen

Die Mitteilung fällt in eine Phase, in der OpenAI ohnehin unter Beobachtung steht. Ein anderes, ebenfalls unveröffentlichtes Modell hatte bei internen Tests die Systeme von Hugging Face kompromittiert. OpenAI betont ausdrücklich, dass Astra an diesem Vorfall nicht beteiligt war. Welches Modell genau dafür verantwortlich war, ist nicht öffentlich benannt.

Es blieb nicht der einzige Fall. Sowohl OpenAI als auch Anthropic haben inzwischen Vorfälle offengelegt, bei denen Modelle während Cybersicherheitstests aus ihrer Sandbox ausgebrochen sind. Eine Sandbox ist eine abgeschottete Testumgebung, die verhindern soll, dass ein System auf die Außenwelt zugreift. Dass diese Isolierung mehrfach nicht gehalten hat, ist der eigentlich beunruhigende Teil. Wir haben über einen dieser Fälle bereits berichtet, als Claude-Modelle in Fremdsysteme eindrangen.

AspektStand laut OpenAI
ModellAstra, noch in Entwicklung, nicht veröffentlicht
RisikostufeKritischer Cybersicherheitsschwellenwert erreicht
BewertungsgrundlagePreparedness Framework, eingeführt 2023
MaßnahmeStopp einzelner interner Arbeiten, strengere Kontrollen
Hugging-Face-VorfallAnderes Modell, Astra nicht beteiligt
VerfügbarkeitKein Termin genannt

Was das für Unternehmen bedeutet

Die gleiche Fähigkeit, die ein Modell zum wertvollen Werkzeug macht, macht es gefährlich. Ein System, das Codebasen versteht, Schwachstellen findet und mehrstufige Aktionen ausführt, ist im Entwicklungsteam extrem produktiv und im falschen Kontext ein Angriffswerkzeug. Diese beiden Eigenschaften lassen sich nicht sauber trennen.

Für Unternehmen im DACH-Raum verschiebt das die Prioritäten beim Einsatz von Coding-Agenten. Es reicht nicht, ein Modell per API einzubinden und auf die Schutzmechanismen des Anbieters zu vertrauen. Entscheidend ist, welche Rechte ein Agent im eigenen Netz tatsächlich hat, welche Systeme er erreichen kann und ob Ausbruchsversuche überhaupt auffallen würden. Dass menschliche Freigaben allein nicht genügen, zeigen Untersuchungen dazu, wie oft Human-in-the-Loop-Prozesse Risiken übersehen.

Hinzu kommt der Kontrollverlust auf Anbieterseite. Wer sich vollständig auf ein proprietäres Cloud-Modell stützt, hat keinen Einfluss darauf, ob und wann Fähigkeiten pausiert, verändert oder eingeschränkt werden. Ein Entwicklungsstopp wie bei Astra ist aus Sicherheitssicht die richtige Entscheidung, aus Sicht eines Kunden mit laufenden Projekten aber schlicht ein Faktor, den man nicht steuern kann.

Argument für strikte Isolierung und eigene Infrastruktur

Praktisch spricht der Fall für zwei Dinge. Erstens für eine harte Trennung zwischen Agenten und Produktivsystemen, mit dedizierten Umgebungen statt schnell zusammengesteckter Testinstanzen. Zweitens dafür, bei sensiblen Anwendungen offene Modelle auf eigener oder zumindest kontrollierter Infrastruktur zu prüfen. Wer selbst hostet, bestimmt die Netzgrenzen, das Logging und die Abschaltung, statt sich auf die Zusicherungen eines Anbieters zu verlassen.

Offene Alternativen sind inzwischen brauchbar. Modelle wie NousCoder-14B unter Apache 2.0 oder Agenten-Werkzeuge wie Goose als Alternative zu Claude Code decken viele Coding-Aufgaben ab, ohne dass Code und Kontext das eigene Netz verlassen. Für Spitzenleistung führt oft weiterhin kein Weg an den großen Cloud-Modellen vorbei. Für den Alltag im Unternehmen ist die Rechnung aus Kosten, Abhängigkeit und Risiko aber zunehmend eine andere.