Google says Gemini 4 Carbon can find, test and help repair difficult software security flaws more effectively than its predecessor. Announced on 28 October 2026, the model is being introduced first to selected cybersecurity defenders, not released as an ordinary feature for every Gemini user. That restricted start is an important part of the story, because the same skills that help expose weak software can also increase the risks of misuse.
In the official Gemini 4 Carbon announcement, Google reports 88.2% on SEC-bench Pro for vulnerability discovery, 54.8% on ExploitGym for exploitation tests and 71.0% on CWE-bench for producing corrective patches. Those are results in defined evaluation settings. They are not proof that the model can automatically secure any live website or guarantee safe software.
What Gemini 4 Carbon is actually being asked to do
A security weakness can survive unnoticed in software long after a program has been released. Finding it may mean reading unfamiliar code, working out how different components interact and checking whether a suspicious pattern is genuinely exploitable. A human security analyst does more than search for a familiar keyword. The job may involve sustained investigation, false leads and difficult judgements about which findings matter.
Google positions Carbon as a stronger model for that longer chain of work. The company says internal teams have used it on multi-step engineering tasks that can last days, including locating the cause of subtle bugs and preparing fixes. This is company-reported experience, not an independent trial of widespread deployment across companies with different security practices.
In ordinary language, the claimed advance is that an AI assistant may be more useful through the complete security process. It might identify a possible weakness, gather evidence that the weakness matters and suggest code that addresses the underlying cause. That sequence is attractive to defenders because finding a problem without a practical repair leaves the software exposed.
Strong percentages still need their proper labels
One of the tests Google highlights is SEC-bench Pro, which measures AI agents on long-running tasks involving security bugs in major software projects. Its site explains the benchmark’s structure, versions and task limits. A percentage from such a test applies to a particular snapshot, environment and scoring method. It should not be treated as a general chance of success on an arbitrary company’s real code.
Google compares Carbon with Gemini 4 Argon, the earlier model released roughly two weeks before. Its stated results show Carbon ahead on the security evaluations it lists. Yet comparisons can depend on the tools, budget, prompts and safety constraints used in testing. Google specifically says the reported benchmark scores were obtained without guardrails, which makes it especially important not to confuse a controlled evaluation with normal product behaviour.
There is also a difference between discovering a vulnerability and using it to cause damage. In legitimate defensive testing, an organisation authorises the work, defines its scope and evaluates whether a reported weakness is real. Outside that context, the same technical capability may be abused. Publication of a high score does not settle how safely a model can be released to the general public.
Why access begins with selected defenders
Google says Carbon will initially be available to a subset of cybersecurity defenders through its Fairwind programme, with wider access phased in after further testing and feedback. The company also describes engagement with a US government voluntary pre-release testing process. It expects broader developer, business and consumer availability later, but has not established that those groups can all use Carbon today.
This resembles the staged access issue LiveAIWire covered with Gemini 4 Argon’s earlier cybersecurity launch. The new story is Carbon’s separate model release and revised performance claims. It should not be mistaken for evidence that the preceding security restrictions have disappeared or that a higher score automatically solves the underlying dilemma.
A second risk is overconfidence in a repair. An AI-generated patch may pass a narrow test while introducing unexpected behaviour elsewhere. Experienced teams normally review changes, run broader tests and monitor real systems after deployment. The fact that an automated tool proposes a fix should accelerate scrutiny, not replace it. The same principle applies whether the code comes from a human colleague or an advanced model.
LiveAIWire has also reported on AI-assisted discovery of flaws in PHP software, an example of how automation can help surface issues that deserve human investigation. Carbon’s announcement suggests ambition beyond isolated findings, but practical reliability must still be demonstrated under the conditions in which security teams actually work.
The real test is safer software, not a leaderboard
If Carbon can help responsible defenders shorten the time between identifying a serious fault and deploying a sound repair, the benefit could be felt by people who never interact with the model themselves. Those people care whether a website, workplace system or device remains trustworthy. They are unlikely to care which benchmark first suggested the improvement.
Security teams also face a prioritisation problem. Not every warning is a serious weakness, and a flood of incorrect reports can drain scarce attention from urgent issues. The quality of evidence, the ability to reproduce a problem and the maintainability of a proposed repair therefore matter at least as much as the number of findings an agent produces.
Google has announced a real new model and specific reported results. What remains unproven is how consistently those improvements transfer to independent security operations, how effective the protections will be under wider access and whether people can trust the generated fixes. Carbon is a notable development, but its restricted release is a reminder that better tools can require more careful deployment.
About the Author
Stuart Kerr is Technology Correspondent at LiveAIWire, covering artificial intelligence, cybersecurity and the social impact of emerging technology. LiveAIWire is an independent, human-led technology publication using AI-assisted research, editorial production and original AI-assisted editorial illustrations under his direction.