Automate a Gemini 4 Carbon security audit

Since 10 November, any developer on the paid Gemini API tier can run a Gemini 4 Carbon security audit on their own code. But the Carbon you can buy isn't the version behind Google's hacking benchmarks. This guide covers what the public model will and won't do, plus a tested setup: a pull-request check, a full-repository scan and the review steps that keep AI bug reports honest.

Carbon is Google's newest frontier model, built for long reasoning jobs. Google's launch post says it spends more thinking tokens than Gemini 4 Argon to explore, verify and check edge cases. That's the behaviour an audit needs. It's also what makes an audit slow and expensive.

Two Carbons: the one you can buy and the one in the benchmarks

Google first released Carbon on 28 October, but only to vetted cyber defenders in its Fairwind Program. Our report on that staged rollout covers the launch claims. On 10 November the model opened to every paying developer, to Gemini for business customers and to Google AI Ultra subscribers.

The headline security scores didn't come with it. The model card says its cybersecurity results reflect access through the Fairwind Program. That covers 88.2% on SEC-bench Pro for finding bugs, 54.8% on ExploitGym for exploiting them and 71.0% on CWE-bench for patching them. In short, the cyber benchmark scores come from the Fairwind version.

The public model runs behind extra classifiers. Google's safety and security report sets the line plainly. Carbon will analyse known public exploits and discuss defensive coding. It will refuse outright to write functional, weaponized exploits.

The report adds two details that matter for auditors. With its safeguards on, Carbon blocked 100% of end-to-end exploit milestones in Google's agentic test runs. And its extra refusals cluster on "exploit-adjacent auditing prompts", not on everyday coding. Google also monitors for misuse and can limit or disable accounts.

So public Carbon refuses to write working exploits, but it will find and fix flaws. Google says it trained Carbon to favour discovering and patching over exploiting. Proving that a bug is exploitable is the job Google keeps for Fairwind. The Fairwind page lists the extra tasks it allows: exploit validation, threat simulation, reverse engineering and malware analysis.

Can Carbon hunt vulnerabilities on its own?

Google's own answer is a pipeline with people at the end of it. Its internal system, Project Fortify, runs four stages. First, agentic scanners find the candidate bugs. A triage agent checks each one against the real runtime to weed out noise. CodeMender writes a fix and tests it in a sandbox. Then human engineers review and merge the change.

Google reports Carbon's results for the first two stages. On its internal benchmark, Carbon hit 100% recall on scanning and 95% precision on triage. On open-source repositories, Google reports a relative gain in recall of more than 25% over Argon. Those are Google's numbers on Google's test, not an independent check.

The headline wins also came from Carbon for cyber, with researchers in the loop. Wiz used it to find zero-days at two large SaaS providers in under two hours. Google's Cloud Vulnerability Research team used it to prove two open-source bugs exploitable, comparable in severity to the PHP2Shell flaws.

Without that loop, results fall apart. Google's Mantis launch post says sloppy AI code scanning often produces hallucinated bugs, with true-positive rates under 7%. OpenAI's run of 948 Linux root exploits in 30 hours ended the same way: its patches still went to human experts. Autonomous finding works. Every finding still needs a human to confirm it.

The benchmark that looks most like an audit

Most security benchmarks hand the model a hint. CWE-bench, from Collinear AI, doesn't. Each task is a real open-source repository and one instruction: audit the code and fix what you find. A fix only counts if a programmatic check shows the exploit no longer works and every existing test still passes.

Version 1 has 120 tasks across 73 weakness types. Each model gets four one-hour attempts per task at high reasoning effort. Carbon leads it, and the board shows what that costs per attempt.

Collinear sums it up as 65 times the cost for 1.3 times the pass rate. Carbon's cost was also priced at the introductory rates, which end on 30 November. And even the leader fails about three tasks in ten. Five of the 120 beat every model tested.

There's a newer board too. CWE-bench v2 has 250 tasks and 185 weakness types, and doesn't list Carbon yet. Claude Fable 5.2 leads it at 75.0%, with Argon at 65.0%. Its 100 public tasks are open, so you can test any model yourself.

Collinear's notes on failures are the most useful part. Agents tend to miss a bug in one of four ways. They never reach the vulnerable code. They read it and call it harmless. They patch the right line without restoring the security property. Or they fix one flaw and leave its siblings. Its example is a Rust image decoder where blocking odd characters still left a crash in the arithmetic that follows.

Step 1: set the rules before the first scan

Before your first Gemini 4 Carbon security audit, decide what's in scope. Scan only code you own or have written permission to test. Remove secrets, keys and customer data from anything you send. Then pick what counts as proof. A finding is real when a test or a sandboxed run shows it, not when the model sounds sure.

Anything that runs model-written code needs a cage. Google's guide to running CodeMender in pull requests runs each exploit check as a one-off Cloud Run job. That job gets its own service account with almost no rights, and no network route out. The same post gives the rule for failures: if a check crashes or times out, mark it inconclusive, never safe.

Step 2: review every pull request with Carbon

The script below sends a diff to gemini-4-carbon and asks for findings in a fixed JSON shape. It needs a paid-tier API key, since Carbon has no free tier. Install the SDK first.

pip install google-genai pydantic
export GEMINI_API_KEY=your-paid-tier-key

Save the parts below as carbon_review.py. The first part defines what a finding must contain. The evidence field forces the model to show the path from attacker input to the line, which cuts vague warnings.

import sys
from typing import Literal

from google import genai
from pydantic import BaseModel, Field, ValidationError

class Finding(BaseModel):
    file: str
    line: int
    cwe: str = Field(description="CWE ID, for example CWE-89")
    severity: Literal["low", "medium", "high", "critical"]
    evidence: str = Field(description="Path from attacker-controlled input to this line")
    fix: str = Field(description="Smallest change that removes the flaw")

class Review(BaseModel):
    findings: list[Finding]
    not_checked: list[str] = Field(description="What the review could not settle")

The next part holds the instructions. They frame the job as defence of your own code, which keeps it away from the exploit-adjacent prompts Carbon refuses.

RULES = """You review pull requests for the team that owns this code.
Report a finding only when you can trace it from input an attacker controls
to a line in this diff. Give the CWE, that path and the smallest fix.
Do not write exploit code. If you are unsure, put it in not_checked."""

def main() -> int:
    diff = sys.stdin.read()
    if not diff.strip():
        print("Empty diff: nothing to review.")
        return 0
    if len(diff) > 400_000:
        print("Inconclusive: diff too large for one review. Scan the repo instead.")
        return 2

The call uses Google's Interactions API. Keep the client in a variable. In testing with version 2.33.0 of the SDK, a one-line genai.Client().interactions.create() closed its connection before sending, so every review failed.

    client = genai.Client()  # reads GEMINI_API_KEY; keep it in a variable
    try:
        interaction = client.interactions.create(
            model="gemini-4-carbon",
            system_instruction=RULES,
            input=diff,
            generation_config={"thinking_level": "medium", "max_output_tokens": 32768},
            response_format={
                "type": "text",
                "mime_type": "application/json",
                "schema": Review.model_json_schema(),
            },
            timeout=900,
        )
    except Exception as err:  # network, quota or a blocked request: never a pass
        print(f"Inconclusive: request failed ({err})")
        return 2

Those settings follow Google's migration notes. Keep at least 32,768 output tokens, because thinking counts against the limit. Allow 15 minutes before timing out. The last part fails closed: anything other than a complete, valid answer exits with code 2.

    if interaction.status != "completed":
        print(f"Inconclusive: status {interaction.status} {interaction.errors or ''}")
        return 2
    try:
        review = Review.model_validate_json(interaction.output_text or "")
    except ValidationError:
        print("Inconclusive: the answer did not match the schema.")
        return 2

    for f in review.findings:
        print(f"[{f.severity}] {f.file}:{f.line} {f.cwe}\n  why: {f.evidence}\n  fix: {f.fix}")
    for item in review.not_checked:
        print(f"[not checked] {item}")
    serious = [f for f in review.findings if f.severity in ("high", "critical")]
    return 1 if serious else 0

if __name__ == "__main__":
    sys.exit(main())

Run it on a branch before you open the pull request:

git diff origin/main...HEAD | python carbon_review.py
echo $?   # 0 clean, 1 serious finding, 2 inconclusive

I tested the script against a local stand-in for the API, with Google's own SDK. That checks the request format and all three exit codes, not Carbon's judgement. In CI, treat exit 2 as a failed check that a person clears.

Keep one limit in mind. A pull request can carry text aimed at the reviewer, such as a comment telling it to report nothing. Carbon scored 0% attack success on Gray Swan's prompt-injection test, yet Google says injection attacks on it are still possible. A clean result means no findings were reported. It isn't proof the change is safe.

Step 3: scan the whole repository with Mantis

For a full audit, use Mantis, the open-source harness behind part of Google's own scanning. It reads the repository's history for past fixes, builds a threat model and plans what to research. Then it reviews, critiques, reproduces and patches each finding. Fifteen stages run in all, ending in a scored report.

git clone https://github.com/google/mantis.git
cd mantis/reference && ./install.sh
export GEMINI_API_KEY=your-paid-tier-key
python3 scripts/configure.py --auto
python3 scripts/configure.py --test --probe
./run.sh path/to/your/code --model gemini-4-carbon \
  --max-tokens 2M --cache-discount 1 \
  --exclude vendor,testdata --focus "look for IDOR"

With GEMINI_API_KEY set, Mantis sends a bare gemini-* model name straight to the Gemini API. The --model flag overrides every stage, including the cheap ones that default to Flash-Lite. Without a cap, a run can use the default budget of 10 million tokens.

The cap above stops the run at 2 million tokens, counting cached tokens at full weight. Even if every token were billed as output, that's about $20 before 1 December and $40 after. The run pauses at the cap rather than failing, so you can resume it. For later scans, --scan-mode changed checks only edited files.

You should expect gaps in one stage. Mantis's reproduce step asks the model for a proof of concept. Public Carbon refuses working exploits, so some findings may arrive without a reproducer. Treat those as unconfirmed, not false. The Mantis README says the same thing from the other side: a failed reproduction doesn't prove a bug is fake.

Read the README's warnings before your first run. Google calls Mantis a demonstration, not a supported product, and says to run it only in isolated environments. It also says every finding must be checked by a security expert before anyone reports it.

If you pay for Google AI Ultra, Antigravity's new /swarm preview is the other route. You can pin Carbon to the coordinator, auditing and verifier roles and give file edits to lighter models. Google warns that swarms use quota much faster than a single chat.

Step 4: triage findings the way Google does

Fortify runs precision-first. For most code, a finding needs high confidence before anyone gets a patch, because false alarms teach developers to ignore the tool. For critical systems such as identity services and internet-facing proxies, teams tune for recall instead and accept more manual review.

Copy that split. Then put every high or critical finding through four checks:

• Reproduce it. Write a unit test that fails before the fix, or run the proof in your sandbox.

• Check the invariant. Ask what must always be true, then test the inputs the patch didn't mention.

• Run the full test suite. CWE-bench fails any fix that breaks existing behaviour, and so should you.

• Keep a human merge. Fortify ends with engineers reviewing every change, and so should your pipeline.

Never mass-file unverified reports to open-source maintainers. The Mantis README asks for exactly that restraint.

What a Gemini 4 Carbon security audit costs

Introductory prices run until 30 November: $2 per million input tokens and $10 per million output tokens, thinking included. Prices double on 1 December, to $4 and $20. The pricing page halves both rates for the Batch and Flex tiers, which suit nightly scans that nobody watches.

Carbon is a heavy reader and writer. Artificial Analysis ran it at the high thinking level and logged 205 million tokens across its index, against a median of 72.8 million. Each task took 25.5 minutes and cost $7.76 at the full price. Budget for long runs.

Two caching rules from the Carbon developer docs affect repeat scans. Explicit context caching isn't supported. Implicit caching is on by default for prompts of at least 4,096 tokens and takes 95% off cached input.

Google says Argon remains the better pick for most engineering work, at the same per-token price. On CWE-bench v1, though, Argon cost more per attempt than Carbon and fixed fewer bugs. On that test, at least, Carbon's longer thinking didn't make an audit dearer.

Where Carbon fits in a security audit

Carbon earns its price on the deep pass: a full-repository audit, authentication and payment code, and the verifier role in a multi-agent run. For high-volume pull-request checks, cheaper models come close. Claude Opus 5.5 fixed 67% of CWE-bench v1 tasks at $0.79 an attempt.

Before you commit a budget, run ten of CWE-bench v2's public tasks on Carbon and on one cheaper model. At Carbon's v1 average of $5.83 an attempt, ten tasks cost about $58 at introductory prices. The test answers the only question that matters: which model fixes your kind of bugs. Whatever it shows, keep the human merge. The top score on either CWE-bench board still leaves at least a quarter of the tasks unfixed.