Pilot Gemini 4 Carbon on one authorized vulnerability-remediation fixture with limited access, cited evidence, independent tests and human merge approval.

What changed on October 28

Google announced Gemini 4 Carbon on October 28 with a focus on long-horizon coding and cybersecurity. The company reports results for vulnerability discovery, exploit validation and patching, plus secure-code improvements over Gemini 4 Argon. These are vendor claims; DeepSecurity.io did not reproduce the benchmarks.

Access is the most important limitation. Google says Carbon is starting with a subset of cyber defenders and will expand to additional trusted partners through the Fairwind Program. It promises broader developer, business and consumer surfaces 'as soon as possible' but gives no general-availability date.

Reuters and The Hacker News covered the release on October 28–29. A focused Firecrawl search on October 30 returned Google's announcement first, followed by those independent reports and other same-day coverage. That signals current attention, not product effectiveness, adoption, search traffic or ranking.

A pilot access checklist covers Fairwind eligibility, authorized scope, an isolated lab, a named reviewer and a cost limit.
Confirm access, authority and containment before designing the first task.

1. Confirm access, price and authorized scope

Do not build a production plan around an announcement. Confirm that your organization has Carbon access, the available interface or API, supported region, logging, retention, model identifier, rate limits and contractual data controls. The Fairwind page may still describe earlier models; use the terms attached to your actual invitation.

Google lists introductory pricing of $2 per million input tokens and $10 per million output tokens, with cached input priced 95 percent lower. It says later pricing will be $4 and $20. Confirm current pricing on the access surface because the introductory period has no end date in the announcement.

Limit the pilot to code your organization owns or is authorized to test. Do not point exploitation features at public systems, customer environments or third-party repositories. Keep network access, production credentials and merge tokens out of the model's toolset.

A security team evaluates a frontier AI model against a synthetic repository inside an isolated lab separated from production.
AI-generated conceptual illustration: the first task stays inside a controlled vulnerability lab.
  • Use the model ID and terms shown in the actual invitation.
  • Select one owned or synthetic repository and one known finding.
  • Set token, time and tool limits before the run.

2. Give the model a known remediation fixture

Choose a small synthetic application or historical internal defect with a known root cause, safe tests and no live secret. Provide the relevant files, build instructions, threat model and expected security property. Keep the reference patch hidden from the model.

Example prompt: 'Analyze fixture CARBON-P1 using only the supplied repository and test evidence. Identify the root cause with file-and-line citations, describe the reachable impact without executing an exploit, propose the smallest patch and list tests that would falsify your conclusion. Do not access the network, run unapproved commands or modify production code.'

The useful output is a review packet: cited finding, assumptions, affected path, minimal diff, negative tests and unresolved questions. A benchmark score or confident explanation does not validate the local finding.

A remediation flow moves from a finding through source tracing and a patch proposal to independent tests and human merge approval.
The patch crosses the gate only after evidence and independent tests agree.

3. Validate the patch outside the model's narrative

Have a reviewer reproduce the cited path and inspect the diff. Run existing unit, integration and security tests plus a negative test for the original weakness. Use an independent scanner or reviewer where appropriate; do not let the same model generate the finding, grade the patch and approve the merge.

Test for behavior drift, disabled checks, broad refactors and unsupported dependencies. A patch can make the fixture pass while preserving the vulnerable path elsewhere or introducing a different authorization failure.

Google reports 88.2 percent on SEC-bench Pro, 54.8 percent on ExploitGym and 71.0 percent on CWE-bench, along with internal secure-code gains. Those figures describe Google's published evaluations, not the success rate you should expect on your code.

A human security reviewer compares vulnerable code, an AI-proposed patch, test results and an independent scan before approval.
AI-generated conceptual illustration: the model proposes; independent evidence and a reviewer decide.

4. Decide whether the feature earns a larger pilot

Score citation accuracy, root-cause correctness, patch validity, test quality, unsupported claims, reviewer corrections, token cost and elapsed analyst time. Include a benign control where the correct answer is that no vulnerability exists.

Stop if the model invents source evidence, attempts an unauthorized action, hides uncertainty, weakens a test or produces a patch reviewers cannot explain. Preserve the failed run and prompt with the fixture rather than tuning against it invisibly.

The closeout should state the exact Carbon model, access terms, fixture version, prompt, tool permissions, evidence, patch, tests, reviewer decision, cost and residual risk. Re-run the gate for a new model version or workload; limited early access is not an authorization for autonomous remediation.

A pilot scorecard measures cited findings, valid patches, test coverage, false claims and reviewer time.
Local evidence determines expansion; vendor benchmarks provide context only.

Put the insight into practice.

Deep Security helps organizations assess risk, validate controls, and build a practical plan to strengthen their defenses.

Talk with Deep Security