Die 'Critical'-Cyber-Schwelle: Was OpenAI mit Astra gerade ausgelöst hat
Am 7. August 2026 veröffentlichte OpenAI einen Beitrag mit dem Titel "Responding to the next frontier of critical cyber capabilities" und teilte der Presse mit, dass es Teile der internen Entwicklung an seinem unveröffentlichten Astra-Modell pausiere. Der Grund: vorläufige Evaluationen der letzten Tage veranlassten OpenAI zu dem Schluss, dass es derzeit nicht ausschließen kann, dass Astra die Critical-Cybersicherheits-Fähigkeitsstufe seines eigenen Preparedness Framework erreicht hat.
Das ist ein Novum. Das Preparedness Framework existiert seit Dezember 2023. Kein Frontier-Modell — weder GPT-4, GPT-4o, GPT-5.6 Sol, noch irgendein öffentlich benchmarktes Anthropic- oder Google-Modell — hat bisher sein eigenes Labor dazu veranlasst, die Critical-Flagge zu setzen. GPT-5.6 Sol landete auf der Cyber-Achse bei High und wurde mit Mitigationsmaßnahmen ausgeliefert. Astra ist der erste Kandidat, bei dem OpenAI schriftlich gesagt hat: vielleicht können wir das nicht so ausliefern, wie wir sonst alles ausliefern.
Diese Seite ist die praktische Erklärung, die (Stand jetzt) sonst niemand geschrieben hat. Kein News-Reblog. Was Critical technisch tatsächlich bedeutet, was operativ passiert, wenn ein Labor das sagt, warum das wichtig ist, selbst wenn du Astra nie anfasst, und wie es sich zu Anthropics parallelem Framework verhält, damit du die nächste solche Ankündigung ohne Übersetzer lesen kannst.
- Die vier Fähigkeitsstufen des Preparedness Framework verstehen (Low / Medium / High / Critical) und was eine Neubewertung auslöst
- Die genaue Definition von 'Critical cyber' kennen — sie ist viel enger und spezifischer als 'das Modell ist gut im Hacken'
- Die konkrete operative Reaktion sehen, die OpenAI auf Astra angewandt hat: isolierte Umgebungen, sandboxed Ausführung, Gewichts-Verschlüsselung, Chain-of-Thought-Monitoring, pausierte Arbeit
- OpenAIs Preparedness Framework auf Anthropics Responsible Scaling Policy / ASL-Ebenen abbilden, damit du beide in denselben Einheiten denken kannst
- Drei Dinge mitnehmen, die ein Entwickler, der auf Frontier-Modellen aufbaut, diese Woche tatsächlich ändern sollte
Was tatsächlich passiert ist, in einem Absatz
Zwischen etwa dem 1. und 7. August 2026 führte OpenAI eine Reihe interner Cybersecurity- und agentischer Coding-Evaluationen an Astra durch — der Modellfamilie, die es am 1. August mit zehn Lean-4-formalisierten mathematischen Beweisen angeteasert hatte. Die Evaluationen zeigten große Sprünge gegenüber vorherigen Modellen. Groß genug, dass OpenAIs Preparedness-Team zu dem Schluss kam, es könne derzeit die Möglichkeit nicht ausschließen, dass Astra auf der Critical-Cyber-Fähigkeitsstufe liegt. OpenAI kündigte öffentlich an, dass es die Sicherheitstests ausweitet, die Sicherheitskontrollen verschärft und einige interne Arbeiten pausiert, die den neuen Kontrollen nicht entsprachen. Es sagte auch, dass es weitere Tests mit Regierungsbehörden und unabhängigen KI-Sicherheitsorganisationen vor einem breiten Release durchführen wolle. Astra ist nicht abgesagt. Sein Release ist bedingt — entweder muss die geschätzte Fähigkeit gesenkt werden oder die Mitigationsmaßnahmen, die das Framework für ein Critical-Tier-Modell verlangt, müssen umgesetzt werden.
Für den Hintergrund zum Modell selbst siehe OpenAI Astra: das Preview-Feld-Notiz.
Das Preparedness Framework in 90 Sekunden
OpenAIs Preparedness Framework — die aktuelle Live-Version ist v2 — ist ein Dokument, das besagt: bevor wir ein Frontier-Modell ausliefern, evaluieren wir es in einer Reihe von verfolgten Fähigkeitsdomänen, und jede Domäne hat vier Stufen. Die Stufen sind domänenübergreifend einheitlich:
| Stufe | Bedeutung (vereinfacht) |
|---|---|
| Low | Basislinie. Modell erhöht die Angreiferfähigkeit nicht wesentlich. |
| Medium | Nicht-triviale Unterstützung für Angreifer. Auslieferung mit Standard-Mitigationsmaßnahmen. |
| High | Ernsthafte Unterstützung. Auslieferung nur mit den "High"-Sicherheits- und Deployment-Kontrollen (Gewichts-Isolierung, Deployment-Beschränkungen, Monitoring). |
| Critical | Modell kann autonom End-to-End-Operationen in der Domäne gegen gehärtete reale Ziele durchführen. Nicht ausliefern ohne dass zuvor eine spezifische Reihe vorab zugesagter Schutzmaßnahmen implementiert wurde. |
Die Domänen, die OpenAI derzeit unter Preparedness v2 verfolgt, umfassen (paraphrasiert): Cyber, biologisch / chemisch, KI-Selbstverbesserung und Modell-Autonomie. Jede hat ihre eigenen Definitionen für die vier Stufen. Ein Modell kann also zum Beispiel Medium bei Cyber und High bei Bio sein.
Das Framework ist eine Verpflichtung zum Prozess, kein Versprechen, dass das Modell in nichts jemals schlecht sein wird. Jeder kann das aktuelle PDF unter cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf lesen.
Warum die Stufe unterhalb von Critical (High) hier nicht ausreicht
GPT-5.6 Sol wurde bei High auf Cyber eingestuft und mit den Standard-High-Tier-Kontrollen ausgeliefert — Deployment-Gating, Missbrauchs-Monitoring, kein Fine-Tuning auf offensivem Handwerk, Gewichts-Sicherheit. Diese Kontrollen sind auf ein Modell kalibriert, das einen Angreifer wesentlich unterstützt, der aber noch den Großteil der Arbeit machen muss.
Critical ist ein anderes Regime. Ein Critical-Tier-Cyber-Modell ist eines, bei dem der Mensch für den interessanten Teil des Angriffs nicht in der Schleife ist. Die Kontrollen für ein High-Modell sind strukturell unzureichend, weil sie voraussetzen, dass der Mensch der Flaschenhals ist.
Was "Critical" auf der Cyber-Achse tatsächlich bedeutet
Das ist der Satz, den die Leute in den Nachrichten falsch lesen. OpenAIs eigene Formulierung ist eng:
Ein Modell, das funktionierende Zero-Day-Exploits für viele gehärtete, reale kritische Systeme ohne menschliche Hilfe entdecken und entwickeln kann, oder neuartige End-to-End-Cyberangriffsstrategien gegen gehärtete Ziele allein aus einem hochrangigen Ziel entwerfen und ausführen kann.
Zwei Dinge sind zu beachten.
Erstens: Es ist nicht "das Modell ist wirklich gut bei CTF-Challenges". CTFs sind vordesignte Puzzles mit vorgesehenen Lösungen. Critical erfordert neuartige End-to-End-Angriffe gegen gehärtete reale Systeme (gepatcht, überwacht, verteidigt). Das ist die Art von Arbeit, die üblicherweise staatlichen Red Teams zugeschrieben wird.
Zweitens macht "ohne menschliche Hilfe" viel aus. Ein Modell, das einem erfahrenen Operator helfen kann, schneller einen funktionierenden Zero-Day zu droppen, ist nicht automatisch Critical — das ist eindeutig High-Territorium. Die Critical-Latte ist Autonomie: Das Modell plant, entdeckt den Bug, waffnet ihn und landet ihn, allein aus einem Ziel wie "besorge und exfiltriere die Kundendatenbank von dieser URL."
Unter dieser Definition ist "wir können Critical derzeit nicht ausschließen" eine viel stärkere Aussage als "das Modell ist gut in Sicherheit." Es heißt: unsere Evaluationen fanden Fähigkeiten auf oder nahe dem Niveau, auf dem ein kompetenter Gegner dieses Ding auf ein gehärtetes Ziel richten und Shell-Zugriff ohne weiteren menschlichen Input erhalten könnte.
Die operative Reaktion, Schritt für Schritt
Wenn ein Labor die Worte ausspricht, sieht das im Büro so aus. OpenAIs Beitrag und die folgende Berichterstattung beschreiben die folgenden konkreten Maßnahmen:
- Astra wird in isolierte Entwicklungsumgebungen mit eingeschränktem Netzwerk- und Tool-Zugriff verschoben. Die Tool-Nutzungsoberfläche, die ein Critical-Tier-Modell nutzen würde, um das Risiko zu *demonstrieren* (beliebiger Internetzugang, Shell, Paket-Installation), ist genau die Oberfläche, die zuerst gekappt wird.
- Stärkerer Modell-Gewichts-Schutz und Verschlüsselung. Das ist keine Preparedness-Erfindung — es ist das Standard-'Insider-Diebstahl'-Bedrohungsmodell, das große Labore auf alle Gewichte anwenden, die sie als strategisch sensibel betrachten — aber Critical macht es explizit zur harten Anforderung.
- Jede Aktion, die das Modell in einer sandboxed Umgebung ausführt, wird protokolliert. 'Universell' bedeutet hier, dass das Monitoring alle interne Nutzung abdeckt, nicht nur externe Kunden. Sowohl Alignment- als auch Missbrauchs-Signale werden markiert.
- Chain-of-Thought (CoT) wird als Signal genutzt, nicht nur als Output. OpenAIs Beitrag nennt explizit CoT-Assessment, das Sicherheitsreviews auslösen kann — eine Möglichkeit, das Modell dabei zu erwischen, wenn es beispielsweise über das Umgehen seines eigenen Sicherheitstrainings nachdenkt, bevor der Plan zu einer Aktion wird.
- Jedes interne Team, das Astra nutzt und dessen Umgebung nicht den neuen Kontrollen entspricht, hört auf, es zu nutzen. Das ist der konkrete Preis, den das Labor bereit ist, in Entwicklerproduktivität zu zahlen, um die Option zu bewahren, das Modell auszuliefern.
- Die nächste Evaluationsrunde wird mit US-Regierungsbehörden (impliziert: CAISI / NIST AISI-Nachfolgeorganisationen) und einer kleinen Anzahl unabhängiger KI-Sicherheitsorganisationen durchgeführt, nicht nur mit OpenAIs internem Preparedness-Team. Das ist die Kontrolle, die verhindert, dass die Bewertung ein 'die eigene Hausaufgabe korrigieren' wird.
- Eines von drei Ergebnissen. (a) Externe Evaluationen kommen zu dem Schluss, dass das Modell tatsächlich High ist, nicht Critical — Auslieferung mit High-Tier-Kontrollen. (b) Modell ist Critical, aber mit spezifischen Mitigationsmaßnahmen (z. B. kein direktes Shell-Tool, kein Browsen auf beliebigen URLs, erzwungene Offenlegung für sicherheitsnahe Prompts) ist das Restrisiko akzeptabel — Auslieferung eines eingeschränkten Deployments. (c) Keines funktioniert — das Modell wird in seiner aktuellen Form nicht ausgeliefert. Nichts in OpenAIs Beitrag verpflichtet zu (c); die Sprache ist bewusst darauf ausgerichtet, wie es ausgeliefert wird, nicht ob.
OpenAI vs Anthropic: gleiche Form, andere Vokabeln
Anthropic betreibt ein paralleles Framework namens Responsible Scaling Policy (RSP), derzeit in v3.0. Statt Low/Medium/High/Critical pro Domäne verwendet Anthropic globale AI Safety Levels (ASL): ASL-1 bis ASL-5. Beide Frameworks versuchen, dasselbe Problem zu lösen und überschneiden sich grob Stufe für Stufe, wenn auch nicht eins zu eins.
Die grobe Zuordnung, so gut sie ohne Endorsement eines der beiden Labore formuliert werden kann:
| OpenAI Preparedness-Stufe | Anthropic ASL-Nachbarschaft | Was ausgeliefert wird |
|---|---|---|
| Low | ASL-1 / ASL-2 | Alles, mit Standard-Nutzungsrichtlinien. |
| Medium | ASL-2 | Auslieferung mit den heutigen Standard-Mitigationsmaßnahmen. |
| High | ASL-3 | Sowohl Deployment-seitige als auch Gewichts-seitige Kontrollen erforderlich. Anthropic aktivierte im Mai 2025 ASL-3-Schutz für Claude Opus 4. |
| Critical | ASL-4 (grob) | Die Stufe, an der Anthropic aktiv gefeilt hat, weil sich zeigt, dass sie tatsächlich schwer vorab zu spezifizieren ist. RSP v3 erkennt explizit an, dass die ASL-4/5-Definitionen der schwierige Teil sind. |
Die interessante Nuance ist, dass Anthropics öffentliche Position zu ASL-4 lautet: "wir haben noch nicht die Schutzmaßnahmen bereit, um ein Modell auszuliefern, das eindeutig ASL-4-Schwellen erreicht" — was ungefähr das ist, was OpenAI gerade laut über Astra gesagt hat, mit anderen Worten. Wenn du künftig eines der beiden Frameworks liest, ist die mentale Übersetzung:
"Critical cyber" (OpenAI) ≈ "ASL-4-artige autonome Fähigkeit" (Anthropic) ≈ "die Schutzmaßnahmen, die wir bereits haben, sind nicht die Schutzmaßnahmen, die das braucht."
Keines der Frameworks ist Magie. Es sind Prozessverpflichtungen. Der Wert liegt nicht darin, dass sie Fähigkeit verhindern — das tun sie nicht — sondern darin, dass sie das Labor zu einer expliziten, öffentlich sichtbaren Entscheidung zwingen, statt zu einem langsamen Default-Auslieferungs-Modus.
Drei nicht-offensichtliche Erkenntnisse für Entwickler
Du lieferst (noch) nicht Astra aus. Du lieferst auf Basis von Claude, GPT-5.6, Gemini oder etwas Lokalem aus. Hier ist, was sich für dich tatsächlich ändert.
1. Frontier-Releases werden hinter ihren eigenen Fähigkeitsankündigungen zurückbleiben
Das Astra-Ereignis ist die konkrete Instanz eines Musters, das häufiger werden wird. Labore werden eine Fähigkeit ankündigen (mathematische Beweise, ein Eval-Ergebnis, eine Demo) Wochen bevor das Modell mit dieser Fähigkeit ausgeliefert werden kann, weil Preparedness-artige Prozesse eine Lücke zwischen "wir haben die Gewichte" und "wir sind bereit, die Gewichte auszuliefern" erzwingen. Plane das ein: Wenn ein Anbieter ein Frontier-Modell vorab ankündigt, gestalte den Launch-Termin deines Produkts nicht darum herum. Gestalte um das aktuell ausgelieferte Modell herum, behandle das neue als Upgrade-Pfad.
2. Deine Tool-Oberfläche ist die Mitigation
Wenn eine Critical-Tier-Fähigkeit hinter einer eingeschränkten Tool-Oberfläche sitzt, kann das Modell trotzdem ausgeliefert werden — es kann nur keine beliebige Netzwerk-I/O oder beliebige Shell mehr. Das ist genau die Deployment-Form, zu der Labore aus anderen Gründen (Sicherheit, Kosten, Determinismus) ohnehin drängen. Wenn du einen Agenten baust, macht dieselbe Tool-Oberflächen-Hygiene, die ihn debuggbar macht, ihn auch deploybar in der Welt, in der das zugrundeliegende Modell Critical-in-irgendwas ist. Konkret: benannte, typisierte Tools mit engen Allow-Lists schlagen "gib ihm eine Shell." Cross-Link zu Vetting agent skills und MCP tool poisoning and rug pulls.
3. Das erhöht den Wert deiner Evals, nicht der des Anbieters
Anbieter-Preparedness- / RSP-Evals handeln vom Worst Case — kann dieses Ding autonom gehärtete Systeme angreifen. Das ist die falsche Frage für dein Produkt. Das Risiko deines Produkts ist nicht "kann das Modell Zero-Days entwickeln", sondern "tut das Modell, was meine Nutzer in meinem spezifischen Workflow brauchen, ohne Outputs zu produzieren, die meine Domäne als schädlich betrachtet." Anbieter-Evals werden das nicht beantworten. Die gesündeste Reaktion auf "Critical" ist, doppelt auf deine eigenen Evals deiner eigenen Flows zu setzen, damit du gegen was auch immer der Anbieter am Ende ausliefert (eingeschränkt, verzögert oder anders), am ersten Tag die Änderung gegen dein Produkt regressionstesten kannst. Siehe Supabase evals: agent benchmark für ein konkretes Muster.
Ein durchgearbeitetes Beispiel: wie ein "Critical-mit-Mitigations"-Deployment aussehen könnte
Wenn die externen Evaluationen Critical bestätigen, OpenAI aber trotzdem ausliefern will, ist die Deployment-Form hochgradig vorhersehbar. Etwa so:
Hypothetische Astra-Deployment-Einschränkungen (illustrativ)
- No raw shell / arbitrary code execution tool exposed to third-party developers - Browsing restricted to allow-listed content classes (docs, GitHub, package registries) and blocked from arbitrary URL fetch on request - All "security research" adjacent requests routed through a stricter refusal policy with mandatory logging and human review sampling - Fine-tuning API disabled for the Critical-tier model - API-only, no download, no on-device version, no self-hosted variant - Rate-limited and gated behind explicit enterprise agreements with reporting requirements - Independent monitoring org receives redacted misuse signals
Nichts davon ist für Astra bestätigt. Es ist die Form, die ein Critical-mit-Mitigations-Deployment haben muss, um die eigenen Verpflichtungen des Frameworks zu erfüllen. Wenn der eventuelle Release grob so aussieht, funktioniert das Framework. Wenn er nichts davon so aussieht, ist das ein Signal, dass die Einstufung doch unter Critical zurückgekommen ist.
Häufige Fehllesungen, die man vermeiden sollte
- "OpenAI hat Astra abgesagt." Nein. Es pausierte interne Arbeit, die den neuen Kontrollen nicht entsprach und erweiterte die Sicherheitstests. Es gibt keine Absage.
- "Astra kann alles hacken." Nein. Die Schwelle ist nicht "kann hacken." Sie ist "kann autonom End-to-End-Angriffe gegen gehärtete Ziele aus einem hochrangigen Ziel ausführen." Selbst die Ankündigung verwendet "cannot currently rule out", nicht "confirmed."
- "Das bedeutet, KI ist jetzt zu gefährlich für einen Release." Nein. Der ganze Sinn des Frameworks ist eine abgestufte Reaktion. Critical bedeutet nicht nicht auslieferbar, es bedeutet nicht auslieferbar ohne die spezifischen Kontrollen, die Critical erfordert.
- "Das Preparedness Framework ist ein Burggraben." Nein. Nichts in Preparedness schränkt das Modell eines anderen ein. Open-Weight-Labore (Meta, Mistral, DeepSeek, Qwen, MiniMax) haben ihre eigenen Fähigkeiten, ihre eigenen Entscheidungen und keine Verpflichtung, Preparedness zu übernehmen. Das Framework bindet das Labor, das es unterzeichnet hat, nicht das Feld.
Was als Nächstes zu beobachten ist
- Ob OpenAIs nächste Preparedness-Framework-Revision Cyber-Critical in feinere Bänder aufteilt (z. B. Critical-Autonom vs Critical-Assistiert). Derzeit legt die Definition viel Gewicht auf "ohne menschliche Hilfe" und die Realität ist ein Spektrum.
- Ob Anthropic seine RSP-v3.0-Stufen öffentlich explizit auf Preparedness-Stufen abbildet. Unabhängige Forscher tun dies bereits informell.
- Ob der nächste große Frontier-Release eines Labors (Anthropic, Google, xAI, DeepSeek) ein umgekehrtes Muster auslöst — ein Labor, das sagt "wir haben auf Critical-Cyber evaluiert und es hat nicht ausgelöst, hier sind die Zahlen."
- Ob die oben skizzierte eingeschränkte Deployment-Form zur Standard-Vorlage für den Versand von Frontier-Modellen generell wird, nicht nur für Critical-Tier-Modelle.
Schnellcheck
Check yourself
0/5Flashcards
Quellen & weiterführende Lektüre
- OpenAI — Responding to the next frontier of critical cyber capabilities (Ankündigung vom 7. Aug. 2026)
- OpenAI — Preparedness Framework v2 (PDF) — die Quelle der Low / Medium / High / Critical-Stufendefinitionen
- Anthropic — Responsible Scaling Policy und RSP v3.0 Ankündigung
- Anthropic — Aktivierung des AI Safety Level 3 Schutzes (Kontext für den High / ASL-3-Vergleich)
- Berichterstattung: TestingCatalog, Interesting Engineering, Crypto Briefing, StartupHub.ai
- AILmanac-Querverweise: OpenAI Astra preview field note · Anthropic cyber eval escapes · Hardening autonomous runs · Vetting agent skills