Google released Gemini 4 Carbon on 28 October 2026, starting with a small group of cyber defenders. In its launch post on the Google blog, Google reports 88.2% on SEC-bench Pro, a benchmark for finding vulnerabilities. If you ship software, treat Carbon as a faster reviewer for your security team, not as an agent you point at production. Keep your scope rules, your human sign-off and your change process exactly where they are.
What is Gemini 4 Carbon?
Gemini 4 Carbon is Google's newest frontier model, built for long-running agentic work and for security. Google calls it "our strongest model with state-of-the-art cybersecurity and long horizon capabilities." It follows Gemini 4 Argon, which also went to defenders before anyone else.
One line in the Google announcement deserves a second read. Google says Carbon can "run for days" on complex engineering tasks. That is impressive. It also means a model that keeps working for days will touch a lot of systems if nobody draws a line around it.
Who can use it today?
Only a subset of cyber defenders. Google says it will "gradually phase" in more trusted partners through the Fairwind Program, and that it is still "gathering feedback and iterating on guardrails" before it opens Carbon to developers, businesses and consumers.
The Fairwind Program page on Google DeepMind sets the rules for partners. It was written for Argon, and it is strict. Partner organisations may only give access to "internal cybersecurity, incident response, or penetration testing teams." They must track employee access and use. They agree to user-level authentication and phishing-resistant MFA. They cannot share, resell or redistribute access. Google says it prioritises governments, national cyber authorities and critical infrastructure operators.
I like that order. A model that is good at exploitation should reach defenders first. That is the right default, and it is one more lab saying so in public.
What do the security scores say?
Google reports three security results in the same Gemini 4 Carbon post. Each one measures a different step of the job.
- Finding flaws. 88.2% on SEC-bench Pro.
- Patching flaws. 71.0% on Collinear's CWE-bench.
- Exploiting flaws. 54.8% on ExploitGym, which Google calls a new state of the art.
Read them in order. Carbon is strongest at finding a problem, weaker at fixing it, and weaker again at exploiting it. That last score is still the reason access is gated. A model that can exploit a real share of known flaws is a tool you control with care, whoever holds it.
The patch score matters more to a team that ships software. Even at 71.0%, a large share of the patches on that benchmark were not good enough. If your process assumes the model's fix is right, you will merge some fixes that are wrong.
Google also reports 0.0% attack success on Gray Swan's prompt-injection test, against 0.7% for Argon. That is good news. But a benchmark of injection attempts is not your ticket queue, your logs, or the email someone forwards into the agent's context at two in the morning.
How much will it cost?
The introductory price matches Argon: $2 per million input tokens and $10 per million output tokens, according to Google's launch post. After the introductory period, Google says $4 per million input tokens and $20 per million output tokens will apply. Cached input is 95% off the input price.
Plan your budget on the second price, not the first. A long security run reads a lot of code and writes a lot of reasoning. Days of work add up, even at introductory rates.
Does a defender model make it safe to test production?
No. This is the point I want to make plainly. A defender model is not a licence to let an agent exploit production.
The model was trained to find and fix flaws. That says nothing about who in your company may run an exploit, against which system, and at what hour. Those are human decisions. They belong in writing before the agent starts, not in a chat thread after something has broken.
Penetration testing has always worked this way. A tester gets a scope letter, a window, a named contact and a way to stop. An agent needs the same paperwork. It is not more trustworthy than a human tester because it is faster. It is less predictable, because it will try things a person would not think of.
What should a security review still do?
- Own the scope. A named person signs off on which hosts, repositories and accounts the agent may touch. Everything else is out of bounds by default.
- Keep exploits off production. Prove an exploit against staging or a copy of the data. If it must run against production, a human runs it, with a rollback ready and the client told in advance.
- Review every patch like a person wrote it. Read the diff. Run the tests. Check that the fix closes the hole without opening a new one somewhere else.
- Log what the agent saw and did. Fairwind already asks partners to track access and use. Do the same inside your own team, for every model, not only this one.
- Treat findings as leads. Confirm each one before you file it, and before you tell a client. A false alarm costs trust you will need later.
None of this is new. It is the review we already run for human testers. A stronger model does not remove the need for it. It raises the number of findings, so the review has to keep pace.
What would I do this week?
If you are not in the Fairwind Program, nothing changes for you today. Use the time to write down your rules for agents in security work: what they may scan, who approves an exploit, where the results go and who reads them. We wrote about who owns those decisions in AI governance as an operating model, and the same thinking applies here.
If you are in the programme, start Carbon on the backlog of findings you already have. Let it propose fixes. Let a person check each one. Give it nothing live until you trust how it behaves on work you can verify.
Where Alongside fits
Deciding what a security agent may scan, who approves an exploit, and where the results go is the kind of work covered by Alongside's technical advisory. If the concern is the code the agent wants to change, a code audit provides a focused review of that code and its risks.