The 'Critical' Cyber Threshold: What OpenAI Just Triggered With Astra
On 7 August 2026 OpenAI published a post titled "Responding to the next frontier of critical cyber capabilities" and told the press it was pausing parts of internal development on its unreleased Astra model. The reason: preliminary evaluations from the past few days made OpenAI conclude it cannot currently rule out that Astra has reached the Critical cybersecurity capability level of its own Preparedness Framework.
That is a first. The Preparedness Framework has existed since December 2023. No frontier model — not GPT-4, not GPT-4o, not GPT-5.6 Sol, not any Anthropic or Google model that has been publicly benchmarked — has previously prompted its own lab to raise the Critical flag. GPT-5.6 Sol landed at High on the cyber track and shipped with mitigations. Astra is the first candidate that has made OpenAI say, in writing, maybe we cannot deploy this the way we deploy everything else.
This page is the practical explainer that (as of this writing) no one else has written. Not a news reblog. What Critical actually means as a technical definition, what happens operationally when a lab says it, why this matters even if you never touch Astra, and how it lines up against Anthropic's parallel framework so you can read the next such announcement without a translator.
- Understand the Preparedness Framework's four capability tiers (Low / Medium / High / Critical) and what triggers a re-evaluation
- Know the exact definition of 'Critical cyber' — it is much narrower and more specific than 'the model is good at hacking'
- See the concrete operational response OpenAI applied to Astra: isolated environments, sandboxed execution, weight encryption, chain-of-thought monitoring, paused work
- Map OpenAI's Preparedness Framework onto Anthropic's Responsible Scaling Policy / ASL levels so you can reason about the two in the same units
- Take away three things a builder shipping on top of frontier models should actually change this week
What actually happened, in one paragraph
Between roughly 1 and 7 August 2026 OpenAI ran a set of internal cybersecurity and agentic-coding evaluations on Astra — the model family it teased on 1 August with ten Lean-4 formalized math proofs. The evaluations showed large jumps over prior models. Large enough that OpenAI's Preparedness team concluded it could not currently exclude the possibility that Astra sits at the Critical cyber capability level. OpenAI publicly announced it was expanding safety testing, tightening security controls, and pausing some internal work that did not meet the new controls. It also said it plans to run further testing with government agencies and independent AI safety organisations before a broad release. Astra is not cancelled. Its release is conditional on either lowering the estimated capability, or standing up the mitigations that the framework requires for a Critical-tier model.
For background on the model itself see OpenAI Astra: the preview field note.
The Preparedness Framework in 90 seconds
OpenAI's Preparedness Framework — the current live version is v2 — is a document that says: before we ship a frontier model, we evaluate it in a set of tracked capability domains, and each domain has four tiers. The tiers are common across domains:
| Tier | Meaning (simplified) |
|---|---|
| Low | Baseline. Model does not meaningfully lift attacker capability. |
| Medium | Non-trivial uplift for attackers. Ship with standard mitigations. |
| High | Serious uplift. Ship only with the "High" security and deployment controls (weight isolation, deployment restrictions, monitoring). |
| Critical | Model can autonomously carry out end-to-end operations in the domain against hardened real-world targets. Do not deploy without a specific set of pre-committed safeguards being in place first. |
The domains OpenAI currently tracks under Preparedness v2 include (paraphrased): cyber, biological / chemical, AI self-improvement, and model autonomy. Each has its own definitions for the four tiers. So a model can, for example, be Medium on cyber and High on bio.
The framework is a commitment about process, not a promise the model will never be bad at anything. Anyone can read the current PDF at cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf.
Why the tier below Critical (High) is not enough here
GPT-5.6 Sol was placed at High on cyber and shipped with the standard High-tier controls — deployment gating, misuse monitoring, no fine-tuning on offensive tradecraft, weight security. That set of controls is calibrated to a model that meaningfully assists an attacker who still has to do most of the work.
Critical is a different regime. A Critical-tier cyber model is one where the human is not in the loop for the interesting part of the attack. The controls for a High model are structurally insufficient because they assume the human is the bottleneck.
What "Critical" on the cyber track actually means
This is the sentence people are misreading in the news. OpenAI's own framing is narrow:
A model that can discover and develop working zero-day exploits for many hardened, real-world critical systems without human help, or devise and execute novel end-to-end cyberattack strategies against hardened targets from only a high-level goal.
Two things to notice.
First, it is not "the model is really good at CTF challenges." CTFs are pre-designed puzzles with intended solutions. Critical requires novel end-to-end attacks against hardened real systems (patched, monitored, defended). That is the class of work usually attributed to state-actor red teams.
Second, "without human help" is doing a lot of work. A model that can help a skilled operator drop a working zero-day faster is not automatically Critical — that is squarely High territory. The Critical bar is autonomy: the model plans, discovers the bug, weaponises it, and lands it, given only a goal like "get and exfiltrate the customer database from this URL."
Under that definition, "we cannot currently rule out Critical" is a much stronger statement than "the model is good at security." It is: our evaluations found capability at or near the level where a competent adversary could point this thing at a hardened target and receive shell access with no further human input.
The operational response, step by step
When a lab says the words, what happens in the office looks like this. OpenAI's post and follow-up reporting describe the following concrete actions:
- Astra moves to isolated development environments with restricted network and tool access. The tool-use surface a Critical-tier model would use to *demonstrate* the risk (arbitrary internet access, shell, package installation) is precisely the surface that gets cut first.
- Stronger model-weight protection and encryption. This is not a Preparedness invention — it is the standard 'insider theft' threat model that big labs apply to any weights they consider strategically sensitive — but Critical explicitly raises it to a hard requirement.
- Every action the model takes in any sandboxed environment is logged. 'Universal' here means the monitoring covers all internal usage, not just external customers. Alignment and misuse signals both get flagged.
- Chain-of-thought (CoT) is used as a signal, not just an output. OpenAI's post specifically calls out CoT assessment that can trigger security reviews — a way to catch the model reasoning about, say, evading its own safety training before the plan reaches an action.
- Any internal team using Astra whose environment does not meet the new controls stops using it. This is the concrete cost the lab is willing to pay in developer productivity to preserve the option to ship the model.
- The next round of evaluations is run with US government agencies (implied: CAISI / NIST AISI-lineage bodies) and a small number of independent AI safety organisations, not just OpenAI's internal Preparedness team. This is the check that keeps the assessment from being marking your own homework.
- One of three outcomes. (a) External evaluations conclude the model is actually High, not Critical — ship with High-tier controls. (b) Model is Critical, but with specific mitigations (e.g. no direct shell tool, no browsing on arbitrary URLs, forced disclosure for security-adjacent prompts) the residual risk is acceptable — ship a constrained deployment. (c) Neither works — the model does not ship in its current form. Nothing in OpenAI's post commits to (c); the language is deliberately about how it will ship, not whether.
OpenAI vs Anthropic: same shape, different vocabulary
Anthropic runs a parallel framework called the Responsible Scaling Policy (RSP), currently at v3.0. Instead of Low/Medium/High/Critical per domain, Anthropic uses global AI Safety Levels (ASL): ASL-1 through ASL-5. The two frameworks are trying to solve the same problem and roughly overlap tier-for-tier, though not one-to-one.
The rough alignment, as best it can be stated without either lab endorsing the mapping:
| OpenAI Preparedness tier | Anthropic ASL neighborhood | What ships |
|---|---|---|
| Low | ASL-1 / ASL-2 | Anything, with standard use policies. |
| Medium | ASL-2 | Ships with today's default mitigations. |
| High | ASL-3 | Deployment-side and weight-side controls both required. Anthropic activated ASL-3 protections for Claude Opus 4 in May 2025. |
| Critical | ASL-4 (roughly) | The tier Anthropic has been actively refining because it turns out to be genuinely hard to specify pre-emptively. RSP v3 explicitly acknowledges the ASL-4/5 definitions are the hard part. |
The interesting nuance is that Anthropic's public position on ASL-4 has been "we don't yet have the safeguard set ready to deploy a model that clearly meets ASL-4 thresholds" — which is roughly what OpenAI just said out loud about Astra, with different words. When you read either framework going forward, the mental translation is:
"Critical cyber" (OpenAI) ≈ "ASL-4-ish autonomous capability" (Anthropic) ≈ "the safeguards we already have are not the safeguards this needs."
None of the frameworks are magic. They are process commitments. The value is not that they prevent capability — they don't — but that they force the lab into an explicit, publicly-visible decision point instead of a slow default towards shipping.
Three non-obvious takeaways for builders
You are not (yet) shipping Astra. You are shipping on top of Claude, GPT-5.6, Gemini, or something local. Here is what actually changes for you.
1. Frontier releases are going to lag their own capability announcements
The Astra event is the concrete instance of a pattern that will get more common. Labs will announce a capability (mathematical proofs, an eval score, a demo) weeks before the model is deployable at that capability, because Preparedness-style processes force a gap between "we have the weights" and "we're comfortable shipping the weights." Roadmap this in: if a vendor pre-announces a frontier model, do not design your product's launch date around it. Design around the currently-shipping model, treat the new one as an upgrade path.
2. Your tool surface is the mitigation
When a Critical-tier capability sits behind a restricted tool surface, the model can still be shipped — it just can't do arbitrary network I/O or arbitrary shell. That is exactly the deployment shape labs already push towards for other reasons (safety, cost, determinism). If you're building an agent, the same tool-surface hygiene that makes it debuggable also makes it deployable in the world where the underlying model is Critical-on-something. Concretely: named, typed tools with narrow allow-lists beat "give it a shell." Cross-link to Vetting agent skills and MCP tool poisoning and rug pulls.
3. This raises the value of your evals, not the vendor's
Vendor Preparedness / RSP evals are about the worst case — can this thing autonomously attack hardened systems. That is the wrong question for your product. Your product's risk is not "can the model develop zero-days," it is "does the model do what my users need on my specific workflow, without producing outputs my domain considers harmful." Vendor evals will not answer that. The healthiest response to hearing "Critical" is to double down on your own evals of your own flows, so that whatever the vendor ends up shipping (constrained, delayed, or otherwise), you can regression-test the change against your product on day one. See Supabase evals: agent benchmark for one concrete pattern.
A worked example: what a "Critical-with-mitigations" deployment could look like
If the outside evaluations confirm Critical but OpenAI still wants to ship, the deployment shape is highly predictable. Something like:
Hypothetical Astra deployment constraints (illustrative)
- 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
None of this is confirmed for Astra. It is the shape of what a Critical-with-mitigations deployment has to look like to satisfy the framework's own commitments. If the eventual release looks broadly like this, that is the framework working. If it looks nothing like this, that is a signal the classification came back below Critical after all.
Common misreadings to avoid
- "OpenAI cancelled Astra." No. It paused internal work that didn't meet the new controls and extended safety testing. There is no cancellation.
- "Astra can hack anything." No. The threshold is not "can hack." It is "can autonomously carry out end-to-end attacks against hardened targets from a high-level goal." Even the announcement uses "cannot currently rule out," not "confirmed."
- "This means AI is now too dangerous to release." No. The framework's whole point is a graded response. Critical does not mean unshippable, it means unshippable without the specific controls Critical requires.
- "The Preparedness Framework is a moat." No. Nothing in Preparedness restricts anyone else's model. Open-weight labs (Meta, Mistral, DeepSeek, Qwen, MiniMax) have their own capabilities, their own choices, and no obligation to adopt Preparedness. The framework binds the lab that signed it, not the field.
What to watch next
- Whether OpenAI's next Preparedness Framework revision splits cyber-Critical into finer bands (e.g. Critical-Autonomous vs Critical-Assisted). Right now the definition puts a lot of weight on "without human help" and reality is a spectrum.
- Whether Anthropic explicitly maps its RSP v3.0 tiers to Preparedness tiers publicly. Independent researchers already do this informally.
- Whether the next big frontier release from any lab (Anthropic, Google, xAI, DeepSeek) triggers a reverse pattern — a lab saying "we evaluated for Critical cyber and it did not trigger, here are the numbers."
- Whether the constrained-deployment shape sketched above becomes the default template for frontier-model shipping generally, not just for Critical-tier models.
Quick check
Check yourself
0/5Flashcards
Sources & further reading
- OpenAI — Responding to the next frontier of critical cyber capabilities (7 Aug 2026 announcement)
- OpenAI — Preparedness Framework v2 (PDF) — the source of the Low / Medium / High / Critical tier definitions
- Anthropic — Responsible Scaling Policy and RSP v3.0 announcement
- Anthropic — Activating AI Safety Level 3 protections (context for the High / ASL-3 comparison)
- Reporting: TestingCatalog, Interesting Engineering, Crypto Briefing, StartupHub.ai
- AILmanac cross-links: OpenAI Astra preview field note · Anthropic cyber eval escapes · Hardening autonomous runs · Vetting agent skills