A Model That Finds Zero-Days Now Exists. Here's the Cloud Exposure Audit to Run This Week.

GPT-6 Astra shipped with the first Critical cybersecurity rating OpenAI has ever given a model, because it can autonomously find zero-days and build working exploits. The capability is gated for now, but the honest planning assumption is that some form of automated vulnerability discovery reaches adversaries sooner than anyone would like. I am not going to write a doom piece about that. I am going to give you the audit I actually ran on our own cloud this week, because the useful response to this news is not fear, it is a checklist you can finish in a few hours.

The thesis is simple: automated vulnerability discovery probes what is reachable, not what is important to you. So the single highest-value thing you can do is know and shrink what you expose. Here is how.

1. Inventory what is actually reachable from the internet

You cannot defend what you do not know is exposed, and every account exposes more than its owners think. Build the list:

• Public IPs and the instances behind them.
• Load balancers and what they route to.
• S3 buckets with any public access, and buckets fronting a CDN.
• Security groups allowing 0.0.0.0/0 on any port, and especially on anything that is not 443.
• API endpoints, admin panels, and dashboards reachable without a VPN.

Most teams find something here they forgot existed. That forgotten thing is exactly what automated discovery finds first.

2. Kill the exposure you do not need

For everything on that list, ask "does this need to be reachable from the entire internet." Usually a surprising amount does not:

• Dev and staging environments with public IPs that could sit behind a VPN.
• Admin interfaces open to the world that should be IP-restricted.
• Security groups with 0.0.0.0/0 that were "temporary" a year ago.
• Old load balancers and endpoints from services that no longer exist.

Every item you remove is one fewer thing any scanner, human or automated, can probe. This overlaps almost perfectly with the orphaned-resource cleanup I usually frame as cost work: the forgotten public bucket and the idle exposed load balancer are both a bill and an attack surface.

3. Measure and shrink your patch latency

If exploit development speeds up, the window between a vulnerability going public and being weaponized shrinks toward zero. Your patch latency, how long from "CVE published" to "patched in prod", becomes your dominant risk. Two moves:

• Actually measure it. Pick your last few notable patches and time them. Most teams are slower than they believe.
• Shorten it for internet-facing systems specifically. You do not need to patch everything in an hour; you need to patch the reachable things fast, because those are what gets probed.

4. Tighten the identities attached to exposed things

For anything reachable, check the blast radius if it were compromised: what IAM role or permissions does it carry? An exposed instance with an over-broad role turns a foothold into a full incident. Simulate the permissions of your internet-facing workloads and cut anything they do not need. Least privilege is not new advice; it is the advice that limits how far a successful exploit gets.

5. Make sure something independent would notice

You will not prevent every novel exploit if they get cheap to produce. So the last layer is detection, and it has to be independent of the thing being attacked:

• Anomaly alarms on API call velocity per identity (CloudTrail to metric filter to alarm is enough to start).
• Alerts on unexpected state changes and on spend spikes (a compromised account often shows up as a cost anomaly first).
• A watcher comparing real resource state to expected baselines, on separate credentials from your workloads, so a breach that changes something surfaces as drift within minutes. (That independent-verification pattern is one we built into ZopNight precisely because the system being attacked cannot be trusted to report its own compromise.)

The take

A model that autonomously finds and weaponizes zero-days now exists, and even gated, that resets the clock on defensive fundamentals. The response is not to panic, it is to spend an afternoon this week doing five boring things: inventory what you expose, remove what you do not need exposed, measure and shrink patch latency, tighten the identities on reachable systems, and confirm something independent would notice a breach. None of it is new. All of it just got more urgent, because the assumption underneath the old comfort, that finding novel exploits is slow and expensive, is the assumption that is expiring.

Run the exposure inventory in step one and I would bet you find at least one thing you forgot was public. What did you find? Mine was an old dev load balancer still routing to something, exactly the kind of forgotten reachable surface this whole exercise is about.