A security team does not need an AI that sounds confident about a bug. It needs one that can find the vulnerable line, explain whether the weakness can actually be reached, propose a fix that will not break production and survive the next code review. Google’s new Gemini 4 Carbon has been designed to make that sequence less laborious. The awkward part is that most of the people who might want to test it cannot use it yet.
Google announced Gemini 4 Carbon on October 28, 2026 as its strongest frontier model, placing particular emphasis on cybersecurity and long tasks that require many steps. It reported an 88.2% score on SEC-bench Pro for vulnerability finding, 54.8% on ExploitGym and 71.0% on CWE-bench for patching. On version 5 of the Artificial Analysis Intelligence Index, Google said Carbon ranked first with a score of 59.
Those numbers are interesting. They are not the same thing as proof that a company can plug Carbon into its source repository and let it run a security programme unobserved. What each benchmark measures, the task setup and the model’s permissions all affect the meaning of the result. In cybersecurity, a model that finds a problem is only helpful if it does not create another one while fixing it.
The gap between the chart and a production repository
SEC-bench Pro, ExploitGym and CWE-bench cover different stages of security work. A vulnerability-finding test asks whether a model can locate a weakness. An exploitation test examines whether it can demonstrate a path through that weakness under controlled conditions. A patching benchmark asks whether the model can produce an effective repair. Putting all three on one press graphic makes for a strong launch argument, but the scores should not be read as three estimates of its chance of success on your company’s code.
Real repositories have complications that benchmark prompts often simplify. Some vulnerable functions are used only in unusual deployment configurations. A patch can pass a test suite yet alter an undocumented behaviour customers depend upon. Organisations have internal secrets, third-party libraries, old dependencies and inconsistent access controls. Security review means checking the model’s work against that messy reality.
Google also said it saw better secure-code generation and fewer fabrications in its internal working environments. Internal results are a legitimate part of a launch; they are not an independent audit. The firm has the responsibility to disclose what was tested and under which constraints. Readers should keep that caveat close to every claim of state-of-the-art capability.
Why Google has not simply opened the door
Unlike a general writing assistant, a powerful cybersecurity model has capabilities that can be useful to both defenders and attackers. Helping an organisation reproduce a flaw so it can be patched is a different task from helping an outsider exploit the same weakness. The technical steps can overlap even when the intent does not.
Google is beginning access with selected defensive partners and trusted users rather than offering everyone unrestricted use immediately. Its announcement describes measures intended to support security research while managing the risks of misuse. A restricted rollout also limits independent testing, which means early users should resist broad claims about its performance beyond the announced evaluations.
The responsibility will not stop with an access form. An organisation using such a model needs logs that record what it inspected, clear approval before any consequential action and a human who can decide whether a reported exploit is relevant. Sending sensitive source code to a remote service also creates privacy and contractual questions. The ability to find vulnerabilities faster does not automatically make it appropriate to upload every repository.
The question for smaller developers
Large technology companies often have dedicated red teams, application-security engineers and people who can test an automated patch in a staging environment. An independent game developer may be the entire security department. For them, a capable assistant could eventually be a valuable second pair of eyes on authentication, account systems, payment integrations and update mechanisms.
But the most useful workflow is also an ordinary one. The assistant flags a specific risk, points to the affected component, explains how to reproduce it safely and offers a limited fix. The developer runs tests, considers the impact and decides whether to merge. No ranking position on an AI leaderboard removes that final responsibility.
Carbon is worth watching because it moves the debate beyond models that merely recognise familiar vulnerability descriptions. Google's reported results suggest stronger ability to operate across longer sequences of technical work. Whether that translates into fewer security incidents will require access, repeatable independent evaluations and evidence from teams using it on real code.
The headline number is 88.2%. The real number is the count of vulnerabilities that get fixed without introducing a new outage. Google has published the former. The industry still needs time to measure the latter.
