Claude Fable 5.2 vs Gemini 4 Carbon: Cybersecurity Capabilities

Research checked November 11, 2026. Claude Fable 5.2 and Gemini 4 Carbon deserve attention from security teams, but the first purchasing question is which deployment you can actually use. Anthropic’s headline cybersecurity results belong to Claude Mythos 5.2. Google’s specialized cyber results are associated with Carbon accessed through the Fairwind Program. Treating either as an ordinary public-model benchmark can lead to the wrong integration decision.

Our assessment is that both releases justify a controlled evaluation for defensive work. The available evidence does not establish a universal head-to-head cybersecurity winner. This review separates release facts, vendor measurements, and our proposed acceptance criteria; it does not report Penligent testing of either model.

What was released, and which cyber capability can you access?

Anthropic announced Fable 5.2 and Mythos 5.2 on November 9, 2026. They share an underlying model, while Fable has stronger domain safeguards. Anthropic says Fable blocks most cybersecurity tasks; Mythos access for security professionals is governed by its Cyber Verification Program. See the official Fable and Mythos 5.2 announcement.

Google introduced Carbon to verified defenders on October 28, 2026, then announced broader availability on November 10, 2026. Its initial release ve public availability announcement describe different access contexts. The Carbon model card explicitly identifies Fairwind access as the context for cybersecurity benchmark results.

The comparison unit we recommend is a deployment record: model version, access program, tool permissions, reasoning settings, time budget, and validation method. Keep that record beside every result. A product label alone is too little information for a reproducible selection.

What the published cybersecurity measurements actually show

Fable 5.2: the relevant cyber evidence belongs to Mythos

Anthropic reports 76.3% on CyScenarioBench ve 89.6% on CVE Rediscovery for Mythos 5.2. The latter uses pre-fix project snapshots and covered 1,829 published CVEs in its October evaluation. Anthropic also warns that labs’ CyScenarioBench scores use unique tasks. These are vendor results, not Fable scores, zero-day counts, or a directly comparable cross-vendor ranking. Source and evaluation caveats.

For a buyer, this makes the access check a prerequisite to any performance claim. If an account cannot run the assessed workflow with the intended model, the published score cannot settle its suitability. For source review or remediation, ask for a completed, independently checked artifact from the deployment you will purchase.

Carbon: distinguish discovery, exploitation validation, and repair

Google reports Carbon for cyber results across SEC-bench Pro for discovery, ExploitGym for exploitation, and CWE-bench v1 for remediation. It also reports 100% scanning recall and 95% triage precision in Project Fortify’s internal benchmark. These are measurements of particular tasks and systems; they are not a guarantee that Carbon will identify every vulnerability in a new application. Google’s November 10 announcement.

Bu Carbon Safety and Security Report, sections 7.1–7.2, adds useful conditions: ExploitGym uses 869 known-vulnerability challenges, single attempts, and six- or ten-hour limits. Google reports a 54.8% causal pass rate in its executive summary. CWE-bench v1 records 71.0% Pass@1, compared with Argon’s 68.0%. Treat these as separate measurements rather than adding or averaging them into one security score.

Two limitations that change the interpretation

First, improvement is task-dependent. Carbon’s safety report, section 3.2.2, records 12/14 CyScenarioBench V2 end-to-end challenges solved, compared with 13/14 for Argon, without out-of-model safeguards. That finding coexists with gains on other cyber benchmarks. It is a reason to test your task mix, not evidence of a general regression or a comparable ranking against Mythos. Report, section 3.2.2.

Second, benchmark version matters. CWE-bench v1 is archived. Its maintainers say it used 120 tasks and a simpler verifier, while v2 expanded the test and strengthened verification. A v1 percentage must stay labeled v1. Do not place Carbon’s 71.0% beside a v2 score and describe the difference as a model improvement.

Our comparison rule is to require the same benchmark revision, task set, scoring definition, agent environment, permissions, and resource budget before interpreting a numerical gap as a model advantage. If those conditions differ, keep the measurements in separate rows and describe what each demonstrates.

Reverse engineering and formal verification are distinct strengths to evaluate

Carbon’s safety report also records 83.6% Pass@1 on SRE-Bench, versus 51.3% for Argon, across 262 binary instances. The benchmark covers malware analysis, network protocols, firmware, game executables, and compression algorithms. That is evidence for bounded reverse-engineering tasks, rather than an unrestricted claim about every binary assessment. Report, section 7.1.5.

Separately, Google describes AlphaProof Code’s work on Signal’s cryptographic protocol implementation: human experts reviewed formal specifications, and Carbon-powered agents generated Lean proofs. This is a research framework combining models, formal tooling, and human judgment. Our assessment is that it supports investigating proof-assisted security engineering; it does not establish that a public Carbon prompt can certify an entire application.

Defensive skill does not establish resistance to malicious instructions

Carbon’s safety report describes zero successful attacks on a particular Gray Swan indirect-prompt-injection replay evaluation, while its coding-agent evaluation had slightly lower survival than Argon. The report also says further attempts could succeed on its RAG task evaluation. These results make the test setting essential: we would not interpret a zero observed attack rate as general immunity. Report, sections 6.1.3–6.1.7.

How to assess the capabilities a security team actually needs

The following criteria are a proposed evaluation method. They are not measured claims about Fable, Mythos, or Carbon. Use a repository you own or an isolated assessment environment with known expected outcomes. Keep public-model tests and verified-access tests as separate cohorts.

Source audit and vulnerability discovery

Give each candidate the same repository commit, build instructions, and task brief. Require every finding to name the affected code path, attacker-controlled input, prerequisite, trust boundary, and observable consequence. Include clean or already-fixed cases so the evaluation can penalize plausible but unsupported reports.

Score confirmed findings separately from hypotheses. Deduplicate multiple descriptions of the same root cause before calculating precision. Define recall against the known reference set only; do not imply that an incomplete reference set represents every possible vulnerability. Keep newly suggested issues outside the recall denominator until independently investigated.

Exploitability validation in an authorized lab

Require a minimal, non-destructive demonstration of the claimed security property inside the isolated environment. A model’s assertion that exploitation succeeded is insufficient. Save the application state before and after the test, the relevant traces, and a negative control where the prerequisite is absent or the fix is applied.

For an authorization issue, for example, the expected artifact can be a harmless request against two synthetic accounts demonstrating an access decision. Stop at the agreed evidence threshold. The assessment does not need production data, persistence, or an expanded attack chain to establish that the boundary failed.

Patching and regression risk

Evaluate a patch as a change to program behavior. Require the security regression check to fail before the patch and pass afterward. Run existing functional checks and inspect adjacent callers. Reject a repair that prevents the issue by disabling an intended feature unless that change was an agreed requirement.

Keep patch acceptance independent of the candidate’s self-review. Record whether the correction addresses the root cause, how much code changed, and whether an engineer can explain its effect. A concise patch with reproducible tests should carry more weight in this evaluation than an extensive unverified remediation narrative.

Reverse engineering and malware analysis

Use synthetic samples or an approved isolated corpus, and score bounded tasks such as recovering a file format, identifying a parser constraint, or explaining a function’s behavior. Request evidence from observed execution or disassembly. Do not infer competence from a generic malware summary or from a different model’s source-code benchmark.

Agent reliability and prompt injection

Test the workflow’s ability to distinguish task instructions from repository text, retrieved pages, and tool output. In an isolated test fixture, place a harmless conflicting instruction in a document and verify that it cannot redirect the agent outside scope. Include benign documents to check that the defense does not make ordinary work unusable.

Measure unauthorized action attempts separately from completed harmful outcomes. A blocked attempt still informs your tool-boundary design. Keep network destinations, secrets, and write permissions constrained by the environment, and inspect the action trace rather than relying on the final answer.

A practical acceptance plan for Fable and Carbon deployments

Before running the evaluation, agree on acceptance thresholds with the people who will review the results. The following sequence gives an engineering team a usable decision record without pretending to be a universal benchmark.

1. Establish identity and access. Record the requested model, any surfaced fallback, account program, and allowed actions. If the answering model is uncertain, mark attribution unresolved.
2. Freeze the cases. Include vulnerable code, patched code, clean controls, and at least one workflow matching your real application’s architecture. Keep hidden checks separate from the task prompt.
3. Equalize the operating budget. Set the same deadline, tools, retry policy, and maximum spend. Record reasoning settings explicitly rather than assuming names such as “high” mean equivalent computation.
4. Verify each result independently. Require the code path, prerequisite, reproduction record, and negative control for a finding. Require corrected behavior and functional checks for a patch.
5. Repeat before committing. Use multiple independent runs and report the count, spread, and failure modes. A single successful demonstration should remain a demonstration.
6. Choose for the workflow. Approve a deployment only when its access, quality, operating cost, and data-handling conditions meet the thresholds for that specific use.

We recommend an outcome ledger with separate states: confirmed finding, unconfirmed hypothesis, incorrect finding, safe refusal, tool failure, and unresolved attribution. A refusal is a workflow outcome that affects completion; it should not silently disappear from the denominator. Report quality conditional on completion alongside the overall task completion rate.

For an AI pentesting workflow, keep model choice alongside scope, validation evidence, and retest results. This is the evaluation approach we recommend to Penligent readers; it is not a claim that Penligent currently integrates either newly released model.

Watch a practical assessment workflow

The Penligent product walkthrough provides workflow context for an evaluation: scope, finding review, and report delivery. Use it to plan the artifacts your team needs to inspect alongside model outputs.

Cost and governance: evaluate the completed assessment

Anthropic lists standard Fable/Mythos 5.2 pricing at $8 input / $40 output per million tokens. Google lists public Carbon at $2 / $10 during its introductory period, then $4 / $20 after November 30, 2026. Google explicitly limits that price statement to public access. These are dated list prices, not a Fairwind quote or the cost of a completed security engagement. Anthropic pricing; Google pricing and footnote.

For procurement, model a complete run: reasoning and output tokens, failed attempts, tool compute, storage, and engineer review. Compare accepted findings or accepted repairs per total spend. Keep onboarding time separate, since an access program can determine when a workflow becomes available even when the inference price looks attractive.

Before submitting nonpublic source code, ask the provider for the applicable retention, monitoring, regional processing, and contractual terms for the exact channel. Document repository permissions and who can approve code changes. Treat these as purchasing questions to resolve, not assumptions that follow from a public launch announcement.

Which deployment should a security team shortlist?

For teams restricted to public access: evaluate public Fable and public Carbon on your actual permitted defensive tasks. Require observed completion and verified artifacts. Do not use specialized-access scores as a substitute for that test.

For verified vulnerability research teams: shortlist Mythos 5.2 and Carbon through their respective access programs, subject to availability and your requirements. The published evidence is strong enough to justify evaluation, but it does not eliminate the need for a matched task set and independent review.

For remediation-focused engineering teams: prioritize accepted patches, preserved behavior, and reviewer effort. Carbon’s disclosed repair evaluation is a useful starting point for designing an acceptance test. It does not establish that Carbon outperforms Mythos on the same repair workload.

For an immediate production decision: choose the deployment that meets your evidence, completion, access, and governance thresholds in the workload you have measured. Keep the alternative available for a later matched evaluation as access conditions and benchmark coverage develop.

Methodology: This is an AI-assisted review of linked primary sources checked on November 11, 2026, with an original proposed evaluation framework. Vendor and benchmark-maintainer results are attributed to their sources. Penligent did not run a head-to-head benchmark, discover new vulnerabilities, or validate provider integrations for this article.