Gemini 4 Carbon’s Security Benchmarks Come With an Asterisk

Two weeks. That’s the gap between Gemini 4 Argon shipping and Google DeepMind announcing its replacement, Gemini 4 Carbon, on October 28. If you blinked during Argon’s launch cycle, you already missed it as the current flagship.

Carbon’s pitch is narrower than “better at everything,” and that’s what makes it worth a second look. Google built this one for cybersecurity defense and long-horizon agentic work specifically — tasks that run for days, not minutes, and where the payoff is finding a real bug in someone’s codebase, not writing a snappier function. The headline numbers: 88.2% on SEC-bench Pro, a benchmark for finding actual vulnerabilities in real-world software; 71% on CWE-bench, which measures whether a model’s patch for a given weakness class actually works; and 54.8% on ExploitGym, which tests whether a found vulnerability can be turned into a working exploit, at a ten-hour runtime budget.

Line those three numbers up and you get a shape, not just a scoreboard. Carbon is good at finding bugs, decent at fixing them, and weaker — though not bad — at proving they’re actually exploitable. That gap between 88.2% and 54.8% is the gap between “this looks like a vulnerability” and “I can show you working code that breaks it,” which is exactly the gap that separates a useful triage tool from something that hands attackers a ready exploit.

The caveat Google put in its own announcement

Google’s own framing includes a detail worth sitting with: these benchmark numbers were produced “without guardrails.” That’s Google’s phrase, not a leak or a third party’s speculation. It means the production version you’d actually get access to, with whatever safety restrictions ship alongside it, is not guaranteed to hit 88.2% on anything. The number describes the model’s raw capability ceiling under test conditions, not what a customer calling the API will see.

That distinction matters more here than it would for a coding or writing benchmark, because the capability being measured — finding and exploiting software vulnerabilities — is the same capability an attacker wants. A guardrail that meaningfully reduces exploit-generation capability is a guardrail that also reduces the SEC-bench Pro score. Google hasn’t published what Carbon scores with the guardrails that ship in the actual product, which is the number that would tell you what you’re really getting.

Who actually gets to use it

Access starts this week through Google’s Fairwind Program, aimed at vetted cybersecurity defenders, with wider rollout promised but no date attached. That’s a reasonable way to ship a model whose benchmark description doubles as a capability demonstration for offensive security work — you don’t want this sitting behind a self-serve signup form on day one. But it also means the 88.2% figure is, for now, not independently reproducible by anyone outside that program. Treat it the way you’d treat any vendor-reported number before a third party gets hands-on access: directionally informative, not verified.

If you lead a security team evaluating whether to apply for Fairwind access, the practical question isn’t “is 88.2% good” — it obviously is, relative to GPT-6 Astra and Gemini 4 Argon on Google’s own comparison. The question is whether your vulnerability backlog looks like SEC-bench Pro’s test set, which skews toward well-scoped, discoverable classes of bugs in real-world codebases. A model that’s strong at that is genuinely useful for triage at scale. It is not, based on anything Google has published so far, a model you point at your whole codebase and walk away from unsupervised — the ExploitGym number alone tells you roughly half of what it flags as exploitable won’t hold up, and that’s before guardrails take any further bite out of the number.

What the two-week cadence actually tells you

Set the benchmark question aside for a second and look at the release calendar. Argon shipped, then Carbon replaced it as the flagship two weeks later. That’s not a yearly model refresh with a press cycle built around it — that’s closer to a point release. Google frames Carbon as a response to specific weaknesses Argon had in long-horizon security tasks, not a ground-up retrain, and the timeline backs that framing up: you don’t retrain a frontier model from scratch in fourteen days.

What that means practically: if you’re building on Gemini for security tooling, don’t assume today’s model version is the one your pipeline will be calling in a month. A two-week replacement cycle for the flagship is fast enough that version pinning and re-validation against your own test set, not just Google’s published numbers, needs to be a recurring task, not a one-time setup step. The same SEC-bench Pro score on a future Gemini 4 release doesn’t guarantee the same behavior on your specific codebase, and the model underneath the API endpoint can change faster than your own eval suite does.

Sources

Google DeepMind on X: Gemini 4 Carbon announcement (October 28, 2026).

The Decoder: Google DeepMind releases Gemini 4 Carbon just two weeks after Argon with gains across the board (retrieved October 30, 2026).