ARGUS Proof-3

Gemini 4 Argon

What the public cyberoffensive assurance record establishes

INDEPENDENT RECONSTRUCTION · GOOGLE DEEPMIND · CYBEROFFENSIVE MISUSE · BROAD ROLLOUT 13 OCTOBER 2026

Explore the interactive assurance graph The seven gapsAbout ARGUS

// The finding

Google’s public record makes its reason for mitigating inspectable, along with unusually concrete capability results, guarded test outcomes and adverse red-team findings. It supports the statement that Google made a pre-launch cyber safety case and a below-CCL residual-risk assessment. It does not independently establish the bridge from those results to that judgement, the full coverage of the 13 October deployment, or how well post-launch monitoring works against sustained misuse.

ARGUS records seven open public-assurance gaps. They are requests for inspectable evidence, not findings that controls failed or that internal evidence does not exist.

Organisation
Google DeepMind
System
Gemini 4 Argon
Risk domain
Cybersecurity / cyberoffensive misuse
Release boundary
Broader public rollout beginning 13 October 2026
Separate phase
Restricted Fairwind rollout, 30 September 2026
Research filed
14 October 2026
Claim
P3-C-001
Status
Technical reconstruction complete. Presentation checked against the filed registers. No independent fidelity audit; not externally peer reviewed.

Scope

The claim under examination

ARGUS takes Google DeepMind’s own words as the single root claim, P3-C-001, exactly as the Gemini 4 Argon model card prints them:

“Cybersecurity CCL: We cannot rule out that Gemini 4 Argon has reached this CCL, and we therefore developed a safety case for its cyberoffensive capabilities that we assess lower risk to below the cybersecurity CCL level.”

Google DeepMind, Gemini 4 Argon Model Card, “Frontier Safety Assessment”, PDF p.11. The card’s cyber table marks the CCL “cannot be ruled out” (pp.12–13).

A CCL is a Critical Capability Level in Google’s Frontier Safety Framework: here, enough uplift with high-impact cyber attacks to cause additional expected harm at severe scale, absent mitigation. The sentence makes three separate claims, and ARGUS keeps them apart. The full safety report (§3.2.2, pp.34–40) elaborates this position without displacing it; it describes the residual risk as “substantially below” the CCL.

  1. CLAUSE 1

    Potential inherent capability

    GOOGLE SAYSGoogle cannot rule out that the unmitigated model has reached the cybersecurity CCL.

    ARGUS READSA conservative modal determination. It is neither a confirmed threshold crossing nor a ruling-out.

  2. CLAUSE 2

    A developed safety case and safeguards

    GOOGLE SAYSGoogle reports developing a cyberoffensive safety case before launch and deploying mitigations under it.

    ARGUS READSThe existence and described layers of the case are public assertions. The complete model-specific case is not separately inspectable.

  3. CLAUSE 3

    Residual risk below the CCL

    GOOGLE SAYSGoogle assesses its mitigations as lowering cyber risk below the CCL level.

    ARGUS READSThis is Google’s risk judgement. ARGUS has not independently verified it, and it is not a measurement or a public certification.

The Executive assurance graph gives a readable route from the claim to each gap, with a branch reader built from the executive checklist. The Full graph renders all 53 nodes and 69 warranted relationships, with every evidence record’s conditions, limits, page-linked sources and provenance.

ARGUS Proof-3 executive assurance graph: root claim P3-C-001, supported by arguments A-001 to A-003 and qualified by A-004 to A-007, the seven open public-assurance gaps G-001 to G-007, and eleven selected evidence nodes, two marked adverse.

Select any node to inspect its register record, configuration, limitations, provenance and relationships. Drag to pan, scroll or pinch to zoom.

P3 uses five relationship types: supports, qualifies, conditions, assumed_by and limits. Three arguments support the root; four qualify it.

Findings

What the public evidence supports

Google’s report gives concrete numbers. They come from three different settings and measure different things: scenarios, segments, modeled multipliers, per-query rates, per-objective rates, hours and requests. ARGUS never pools them, and none of them is a deployment-wide probability of harm. Each figure below links to its PDF page.

QSR (query success rate) counts individual attack prompts that produce an actionable breach. OSR (objective success rate) counts harmful goals for which the attacker gets at least one breach across all attempts. A low QSR and a high OSR can both be true of the same test.

Unmitigated Model C

The model without out-of-model production safeguards: a capability test, not a test of the deployed system.

  • 12/12

    end-to-end CyScenarioBench scenarios solved

    A challenge count, not repeated trials. Two solves took unintended routes, which may overstate intended-task performance. Report p.37

  • 77/82

    scenario segments solved

    Read from Figure 3.2. The benchmark is saturated, so it no longer upper-bounds capability. Report p.37

  • 9x–100x

    modeled unmitigated cost uplift across 22 historical attack chains

    Geometric mean about 16.7x. A modeled multiplier, not observed harm; Google calls the quantitative scores substantially uncertain. Report p.37

  • TAC-4

    no challenges at this tier

    The cost model assumes TAC-4 performance from the measured time horizon and reliability. Report p.34

Guarded endpoints, latest mitigations

Google’s safeguarded evaluations in §3.3, run by Google.

  • 100%

    of CyScenarioBench and ExploitBench milestones refused

    The milestone denominator is not supplied. Report p.57

  • 0.4%

    malicious violation rate, cyber conversational set

    About 1,000 examples over 1 to 5 turns; chart value from Figure 3.9. Report p.57

  • 53.9%

    benign cyber refusal rate, same set

    The utility cost of a deliberately wider safety margin, which Google acknowledges; chart value from Figure 3.9. Report p.57

  • 1% / <1%

    query success rate (QSR), static / adaptive attacks

    Per-query actionable breach. Figure 3.10, with 95% Jeffreys intervals whose endpoints are not printed. Report p.60

  • 20%

    objective success rate (OSR) in both chart groups

    At least one breach per harmful seed objective across attempts. Prose separately reports adaptive OSR of 0% single-turn, 40% multi-turn and 20% combined. Report p.60

External red teams, guarded endpointsADVERSE

Tests run by external parties and narrated in Google’s report. The graph marks both as adverse findings.

  • 10% QSR

    Gray Swan, 25 high-severity cyber tasks, Shade attacker at high thinking

    Google reports 10% per-query success, down from 14% on the cited predecessor. Report p.62

  • 56% OSR

    Gray Swan, objective-level success, same test

    More than half of seed objectives reached at least one success (chart value, Figure 3.10; 76% on the predecessor). Retry budget and task-level results are not printed. Report p.60

  • 12 breaks

    Trajectory Labs: 9 technique families, 38 hours, over 4,000 requests

    No new universal jailbreak in that window. One detailed success took about 7 hours, 900 turns and more than 160 sessions, plus substantial human planning. Report p.62

Within one test, against the cited predecessor

Google compares Argon with an earlier Gemini model on the same test and metric. Those pairs are the only comparisons shown here; bars on different rows are different tests and are not comparable with each other. Lower is better for the defender.

Internal adaptive attacks, combined · OSR (p.61)

Gemini 4 Argon20%
Cited predecessor70%

Internal adaptive attacks, multi-turn · OSR (p.61)

Gemini 4 Argon40%
Cited predecessor80%

Gray Swan cyber evaluation · OSR (p.60)

Gemini 4 Argon56%
Cited predecessor76%

Gray Swan cyber evaluation · QSR (p.62)

Gemini 4 Argon10%
Cited predecessor14%

What the numbers support, and what they do not

The unmitigated results are substantial risk signals, and they make Google’s decision to mitigate as if the CCL could be reached coherent. They do not confirm a crossing: the report labels its quantitative scores uncertain, has no TAC-4 challenges, and notes that novel attacks could exceed its historical reference class.

The guarded results give meaningful, bounded support for safer responses and higher attacker friction, with a real cost to benign users. The external results show that “near-zero per query” is not “no objective can be reached”. Google says so itself: safeguards impose friction rather than eliminate risk, persistent actors may achieve partial bypasses, and reactive detection has discovery lag (p.63).

Dual-use capability results elsewhere in the report (ExploitBench 87% best-of-three, 86% internal vulnerability discovery, 72% internal exploitation pass@1; pp.213–215) reinforce why safeguards matter. They are not guarded misuse tests.

The missing link

The bridge from results to the below-CCL judgement

Steps 1 to 3 are on the public record, and step 5 is Google’s stated judgement that, with these safeguards, cyber risk sits below the CCL. Step 4 is what connects them. The Frontier Safety Framework calls for it to be an explicit residual-risk and governance determination (FSF p.10). The public record says a case was developed and gives the conclusion; it does not show that reasoning.

  1. STEP 1

    Capability

    Cannot rule out the CCL; 12/12 unmitigated scenarios; ~16.7x modeled uplift

    Public

  2. STEP 2

    Safety case

    Developed before launch; layered classifiers, probes, monitoring, weight security

    Described

  3. STEP 3

    Guarded tests

    Strong direct-request coverage; low QSR; 56% Gray Swan OSR; 12 Trajectory breaks

    Public, mixed

  4. STEP 4

    Acceptance

    Criteria, residual-uplift calculation, adverse-result dispositions, decision record

    Not public · G-002

  5. STEP 5

    Below CCL

    Google’s residual-risk assessment for the 13 October release

    Google’s judgement

What is missing, in the gap register’s words

Versioned case or sufficiently detailed safe summary; risk acceptance criteria, counterfactual baseline, modeled residual uplift/harm and uncertainty, treatment of 12 manual breaks and objective-level successes, weight-security dependency, decision date and accountable governance function, review outcome, and explicit reasoning for the broader October 13 footprint. The report is public evidence of what Google says it did, not the full case record.

The internal case and decision may be complete and well supported. The public report is consistent with that; it cannot independently establish it. Read G-002 in the graph.

Release boundary

Two rollouts, two configurations

30 SEPTEMBER · RESTRICTED

Fairwind trusted access

Google announced Argon for trusted defenders and internal teams without cyber guardrails, with broad availability still to come (30 September post). The report describes Fairwind’s tailored mitigations and continuous monitoring that permit specialised dual-use work (pp.12–13).

A distinct phase and configuration. Its access terms are never used as broad-release terms, and its evidence is not pooled with broad-release guardrail tests.

13 OCTOBER · BROAD

The release this case examines

Google began a broader rollout across API and AI Studio, Antigravity, the Gemini app and AI Mode (launch post), with Gemini for business on the model card, p.4, and separately expanded Fairwind (safety post).

The report says inference safeguards may be used as appropriate and that intervention style depends on surface. No public per-surface configuration map exists (G-004).

The 14 October capture and the release-day bytes

  1. 17 Apr 2026

    Frontier Safety Framework v3.1 published

    General process, not Argon-specific fulfilment evidence.

  2. 30 Sep 2026

    Restricted Fairwind rollout announced

    Trusted defenders and internal teams, described as without cyber guardrails; broad release still to come. The retrieved post was modified on 1 October.

  3. 13 Oct 2026

    Broad rollout begins; Fairwind expanded separately

    Launch post 16:00 UTC, safety post 18:00 UTC. API and AI Studio, Antigravity, the Gemini app and AI Mode; the model card adds Gemini for business. Access may vary.

  4. 14 Oct 2026

    ARGUS captures the six sources

    09:44 to 09:50 UTC. These bytes are hashed; the exact 13 October bytes and serving configuration are not authenticated.

The card and report carry only “October 2026” as their date, and the 13 October posts link them. That strongly supports their availability on release day, but the next-day copies cannot by themselves prove the exact release-day wording or the served model and guardrail versions. Model C, the final release candidate, is the tested checkpoint (Table 3.8, pp.161–162). No change is evidenced: this gap (G-007) concerns custody, not a claim that anything was edited.

Open links

Seven open public-assurance gaps

Seven gaps derived from this Argon cyber case. A gap means the inspected public record does not let an independent reader complete a material inference. It does not mean Google lacks private evidence, a control failed, a policy was breached or a cyber incident occurred. The reason for a particular omission is UNKNOWN_REASON unless the source expressly gives one. General sensitivity concerns in the FSF do not establish a document-specific withholding reason. Evidence IDs resolve in the evidence register; graph IDs are in the typed graph.

Open each gap for its full investigation, quoted from the gap register: why it matters, what is missing, what would close it, the alternative reading, and the evidence it cites.

G-001CCL uplift model inspectability

Why it matters

The root's inherent-capability premise is a cannot-rule-out assessment, relying on the relation between sandbox performance, historical attack costs and possible severe harm. The report's 12/12 end-to-end solves and ~16.7x geometric-mean modeled cost uplift are substantive, yet two solves were unintended, TAC-4 tasks were absent, the 22 chains were selected for severity and recency with stated exceptions, and novel AI-shaped attack chains could yield greater reductions. A reader cannot inspect how uncertainty was propagated or how subject-matter experts mapped these results to the qualitative CCL.

Missing public evidence

Complete safe 22-chain/23-step mapping and weights, baseline elicitation and supervision-adjustment rules, sensitivity to TAC-4/time horizon and unintended solves, uncertainty range, and model-specific criterion-to-evidence decision record. The report describes the method but does not provide this full audit trail or a numerical cyber cutoff.

Evidence that would narrow or close it

Redacted model code or an auditable aggregate input/output table; pre-specified sensitivity cases for TAC-4, omitted/novel chains, unintentional solves and human supervision; uncertainty intervals; a dated expert rationale explaining why these results support “cannot rule out.” A numeric cutoff is not required if the qualitative rule and its application can be audited.

Alternative interpretation

Conservatism may make unresolved TAC-4 and saturation sufficient reason to mitigate without proving a crossing. The unintentionally solved tasks could overstate intended-task scores, while an unsaturated harder benchmark could show still greater capability. Neither direction changes Google's modal status into a confirmed threshold crossing.

Reason missing

UNKNOWN_REASON for unavailable detailed model and adjudication. No source-specific redaction explanation was found. Possible sensitivity is not asserted as the cause.

Graph links and observed evidence

P3-A-001, P3-D-002, P3-U-001/002. Observed evidence: P3-E-002, E-004–008, E-024. Report §3.2.2, PDF pp.34–40; FSF cyber definition, p.12.
Read this branch in the Executive graph →Isolate it in the Full graph →
G-002Safety-case and risk-acceptance bridge

Why it matters

Google's conclusion that safeguards reduce cyber risk below the CCL is a residual-risk judgment distinct from unmitigated capability and from the existence of controls. FSF v3.1 calls for an acceptable-risk determination informed by effectiveness, deployment scope, circumvention, other models and historical harm, with a supplemental safety case if a CCL is reached. The report says a case was developed and gives a summary conclusion; it does not expose the complete Argon-specific argument that turns ~16.7x modeled unmitigated uplift plus observed bypasses into an accepted below-CCL result.

Missing public evidence

Versioned case or sufficiently detailed safe summary; risk acceptance criteria, counterfactual baseline, modeled residual uplift/harm and uncertainty, treatment of 12 manual breaks and objective-level successes, weight-security dependency, decision date and accountable governance function, review outcome, and explicit reasoning for the broader October 13 footprint. The report is public evidence of what Google says it did, not the full case record.

Evidence that would narrow or close it

A dated public or independently audited case summary with claim/argument/evidence chain, quantitative or qualitative residual-risk calculation, stress cases, adverse-result dispositions, scope-specific acceptance rationale and governance sign-off by role. Sensitive operational details could be inspected under controlled access with a public findings summary.

Alternative interpretation

The internal safety case and decision may be complete and well supported. The public report's conclusion is consistent with that possibility; it cannot independently establish it. The FSF may permit a proportionate qualitative assessment rather than a single numerical bound.

Reason missing

UNKNOWN_REASON. FSF §5.2 discusses confidentiality/security conditions for some disclosures, but does not state why this Argon case or decision record is not fully public.

Graph links and observed evidence

P3-A-002/006, P3-D-006. Observed evidence: P3-E-001, E-003, E-013–014, E-019–020, E-023. Report §3.2.2.6, p.40; FSF §2.1.2, p.10.
Read this branch in the Executive graph →Isolate it in the Full graph →
G-003Adverse bypass disposition and robustness denominators

Why it matters

Positive direct coverage (0.4% cyber conversational violation; 100% refusal of reported agentic milestones) and lower QSR coexist with 20% internal objective success, 40% multi-turn adaptive OSR, 56% Gray Swan OSR and 12 Trajectory Labs breaks. QSR, OSR, tasks, turns, requests and sessions measure different things. The publisher's four severity axes—uplift, universality, operational friction and discoverability—are sensible, but the public reader cannot see their case-level application or how the remaining successes affect residual risk.

Missing public evidence

Per-test seed/query and retry denominators, interval endpoints and assignment of the chart's 95% Jeffreys intervals; task-level success classes and safe four-axis adjudications; break-disposition and mitigation retest results; comparable baselines; operator-effort distribution beyond the one 7-hour example; exact endpoint/control versions. No exploit transcripts are requested for public release.

Evidence that would narrow or close it

Sanitized per-objective results with seed and query counts, uncertainty, task-family coverage, severity decisions, treatment of the 12 breaks, and before/after retests of fixes. An independent reviewer could verify a secure full log set and publish aggregate findings.

Alternative interpretation

High OSR can coexist with low real-world attacker utility if successes are narrow, expensive, or low uplift; the 7-hour/900-turn example supports that possibility. Conversely, persistent attackers may invest greater effort than test budgets, and Gray Swan's 56% OSR is materially adverse. Neither interpretation is proved by the aggregates alone.

Reason missing

UNKNOWN_REASON for missing denominators, case adjudications and retests. Avoid inferring concealment or asserting an unobserved exploit consequence.

Graph links and observed evidence

P3-A-003/004, P3-U-003/004. Observed evidence: P3-E-009–012, E-014. Report §3.3.2 and Fig. 3.10, pp.59–63.
Read this branch in the Executive graph →Isolate it in the Full graph →
G-004October broad-release configuration and Fairwind separation

Why it matters

The 30 September restricted phase explicitly promised trusted defenders and internal teams access without cyber guardrails; the 13 October phase begins broad access and also expands Fairwind. The report says safeguards may be used depending on surface and interventions differ. Its guarded test endpoints cannot establish which classifier, activation probe, CoT monitor, account control or policy was active for each public API, app, Antigravity, AI Mode or business route, nor exact comparability of Fairwind monitoring. Model C is a final candidate, not a publicly versioned serving manifest.

Missing public evidence

Dated per-surface rollout/configuration matrix for October 13; model/guardrail/policy versions, default and optional controls, access tiers, exceptions, enforcement and monitoring, and mapping to each guarded evaluation. Separate Fairwind eligibility, tailored controls and auditable isolation from broad public routes are needed at the level safe to disclose.

Evidence that would narrow or close it

A versioned deployment attestation or controlled audit covering first-party and API routes, with tested-versus-served configuration mapping, rollout windows and exception handling; separate Fairwind operating-configuration summary. A post-release change log would preserve later configuration changes without backdating them.

Alternative interpretation

A common backend could make controls effectively uniform across broad routes; the public documents do not establish that. Fairwind may be strongly governed despite permitting cyber tasks; its trusted-access safeguards cannot be treated as equivalent to ordinary public guardrails.

Reason missing

UNKNOWN_REASON for the absent matrix and serving manifests. The two release-phase descriptions themselves are public; their distinction is established, not an omission.

Graph links and observed evidence

P3-A-005, P3-D-001/003/005, P3-U-005. Observed evidence: P3-E-013, E-015–018, E-022. Model card distribution, p.4; report §2.5.1, pp.12–13; September post; October broad launch.
Read this branch in the Executive graph →Isolate it in the Full graph →
G-005Monitoring, enforcement and update effectiveness

Why it matters

Google explicitly says safeguards impose friction rather than eliminate risk, sophisticated actors may partly bypass them and reactive improvement has discovery lag. Account monitoring and enforcement therefore bear weight in the below-CCL argument, especially against long-horizon decomposition and repeated attempts. Public architecture alone does not show whether post-launch controls interrupt harmful trajectories soon enough.

Missing public evidence

Cyber-specific detection and false-negative estimates, review/enforcement latency, account re-entry or repeat-offender controls, incident and near-miss aggregates, time from novel jailbreak discovery to mitigation and retest, and triggers for re-reviewing the safety case as the rollout grows.

Evidence that would narrow or close it

Privacy-preserving operational metrics by surface and risk tier, blinded detection exercises, red-team campaigns that include account churn and multi-session behavior, documented response-time distributions, and post-launch safety-case update summaries. User logs and exploit recipes need not be published.

Alternative interpretation

Layered classifiers may catch most harmful continuations before account action is needed; account enforcement may still materially lower repeated misuse. Equally, a small persistent actor could exploit detection lag. Current public summaries do not quantify either outcome.

Reason missing

UNKNOWN_REASON for Argon-specific operational metrics. The report gives no specific privacy or security withholding rationale for them.

Graph links and observed evidence

P3-A-006, P3-D-004, P3-U-004. Observed evidence: P3-E-013–014, E-017, E-020. Report §2.3, p.11; §3.3.3, p.63.
Read this branch in the Executive graph →Isolate it in the Full graph →
G-006Independent cyber assurance and reproducibility

Why it matters

Faculty, Gray Swan and Trajectory Labs performed distinct tests; Irregular co-developed a benchmark; AISI and NIST CAISSI participated. These are real external inputs. But the report expressly says external evaluators do not decide FSF thresholds, and Google's SMEs integrate results. The inspected corpus contains no independently authored Argon cyber report confirming the CCL judgment, safeguard robustness at broad-release settings or residual-risk decision. Many seed, trial, harness, judge and uncertainty details are incomplete publicly.

Missing public evidence

Independently authored cyber findings with tested checkpoint/control version and access conditions; full safe method manifests, task/seed counts, retries, sampling, judge validation, uncertainty/sensitivity and discrepant findings; independent review of the safety-case inference with funding/access/editorial disclosures.

Evidence that would narrow or close it

Publish evaluators' own bounded reports or independent audit summaries, with safe aggregate methods and adverse findings; supply reproducibility packets or controlled audit access for model versions, scoring and calculations. Repetition by Google and independent assessment should be distinguished.

Alternative interpretation

Independent testers may have more detailed reports or private access; the public report's narrative could faithfully summarize them. External test execution already adds confidence in observations, but it is not independent endorsement of Google's CCL or below-CCL judgment.

Reason missing

UNKNOWN_REASON. The FSF's general confidentiality/security caveat does not identify why specific cyber methods or reports are absent. AISI/CAISSI participation must not be presented as corroborating results not printed here.

Graph links and observed evidence

P3-A-007/001, P3-U-006. Observed evidence: P3-E-004–012, E-021–022. Report §§3.1.3–3.1.4, pp.20–21; Faculty summary, pp.39–40; guarded tests, pp.59–62.
Read this branch in the Executive graph →Isolate it in the Full graph →
G-007Exact release-time source and serving custody

Why it matters

The root is anchored to the 13 October public release, but the retained card and report were retrieved on 14 October, show only “October 2026” as publication date, and warn/allow that model-card content may evolve. The October 13 posts link the documents and date the rollout, but the retrieved HTML/PDF bytes do not independently prove the exact release-day text or the specific model/guardrail serving version. The September post was modified on 1 October, further limiting exact 30 September byte claims.

Missing public evidence

Authenticated on-or-before-13-October snapshots/digests of the card, report and relevant broad-release page; exact serving manifest or signed release note for Model C and guardrail versions at each access route; version history of subsequent updates.

Evidence that would narrow or close it

Independently timestamped public archive captures with matching hashes or publisher-signed historical digests, plus versioned release manifests. A later publisher attestation of unchanged text narrows uncertainty but does not independently establish byte identity.

Alternative interpretation

The next-day documents may be exactly what was linked on release day, and the October 13 posts strongly support contemporaneous availability. No change is evidenced; the gap concerns custody, not a claim that editing occurred. The printed date and linked references are useful chronology but not byte authentication.

Reason missing

UNKNOWN_REASON for absent historical captures/manifests in the inspected corpus. This is a provenance limitation, not a publisher-redaction finding.

Graph links and observed evidence

P3-A-007, P3-D-007/001, P3-U-007. Observed evidence: P3-E-001, E-016–018, E-022; source register.
Read this branch in the Executive graph →Isolate it in the Full graph →

Grouping and closure discipline

These seven gap boundaries follow distinct inference failures: inherent CCL mapping; residual-risk decision; bypass interpretation; served configuration; post-launch effectiveness; external inspectability; historical custody. A reviewer could group them by lifecycle or split statistical reproducibility from institutional independence. The count is an inventory of this case, not a safety score, comparison with earlier ARGUS cases or a target number. A later disclosure closes a gap only for the time and configuration it actually covers; it cannot silently authenticate release-time bytes or replace an earlier test.

Method

How to read this work

ARGUS is an independent documentary reconstruction of public sources. No live model was queried, no exploit was run and no confidential source was used. It is not a penetration test, a safety certification, a policy-compliance finding or a ranking of models. The typed graph separates Google’s statements from ARGUS interpretation and records every warrant, assumption and adverse result.

The research was filed on 14 October 2026, the day after the release. This presentation was checked against the filed registers by its author. It has not had an independent fidelity audit, and the study has not been externally peer reviewed. Findings may be revised with cited corrections.

Challenges are welcome: a source locator, contrary evidence or a better argument against any edge or evidence record. Criticism that narrows or corrects a link is a useful outcome.

Open Executive and Full Assurance Graphs Send a challenge or correction

Provenance

Public sources and provenance

Six public publisher documents. ARGUS hashed the copies it retrieved on 14 October; the links below open the publisher’s current copies, and each note says how they compare. PDF page numbers are one-based file pages; the safety report’s printed page numbers are one lower.

  • P3-SRC-001
    Gemini 4 Argon Model Card (opens in a new tab)

    Current publisher PDF. Byte-identical to the ARGUS capture of 14 October 2026 when re-checked the same day. The card says it may be updated.

    Dates, capture hash and release-time limits
    Publisher date
    Published October 2026, exact day not printed; no numbered revision. Card says it may be updated.
    ARGUS capture
    2026-10-14T09:44:59Z; 444,990 B; 562cd3c5deddf75dd2aff7a59dcf6dcc273277eae7d82fe957b6a607d84f7763
    Pages and case use
    14; root p.11, CCL table pp.12–13, distribution p.4
    Release-time qualification
    October 13 safety post currently links the card. No independently authenticated October 13 copy or digest; exact release-time bytes not established.
  • P3-SRC-002
    Gemini 4 Argon Safety & Security Report (opens in a new tab)

    Current publisher PDF, a later revision (R2). Google replaced this file at 10:04 GMT on 14 October 2026, about 20 minutes after the ARGUS capture at 09:44 GMT. ARGUS keeps its captured file (SHA-256 1451f641…) as the source of record and has recorded R2 (SHA-256 446c83a9…) separately. Both have 217 pages and identical charts. On the pages this case cites, six passages changed in grammar or layout only, and one figure changed: on p.157, evaluation awareness tied to automated grading reads 35% of flagged unprompted runs in the capture and 37.8% of unprompted runs in R2. This case cites neither value. No ARGUS finding, figure or page reference is affected.

    Dates, capture hash and release-time limits
    Publisher date
    Cover: October 2026; no numbered revision or exact publication day printed.
    ARGUS capture
    2026-10-14T09:44:44Z; 17,311,582 B; 1451f641e6104778b1a0e7429d9f558325da26968427d53d1fd242b0e4257cba
    Pages and case use
    217; full report read; cyber core pp.34–40, 56–63; checkpoints pp.161–162; security p.160; cyber capability/defense pp.213–217
    Release-time qualification
    October 13 safety post currently links this PDF. No authenticated October 13 byte capture. Public report describes a developed safety case; it is not the separately inspectable complete safety-case file.
  • P3-SRC-003
    Frontier Safety Framework v3.1 (opens in a new tab)

    Current publisher PDF. Byte-identical to the ARGUS capture of 14 October 2026 when re-checked the same day.

    Dates, capture hash and release-time limits
    Publisher date
    Version 3.1, published 17 April 2026.
    ARGUS capture
    2026-10-14T09:45:06Z; 447,155 B; ad10d2d240e0d557ecad406dbccedcbb4a70295f8ba8eec46bfe01803cb9c301
    Pages and case use
    20; §§1.2–1.3 pp.4–8, §§2.1–2.2 pp.9–12, §5 p.17
    Release-time qualification
    Publisher-dated pre-release framework. Exact September 30/October 13 bytes not independently authenticated. Framework sets process; it is not model-specific fulfilment evidence.
  • P3-SRC-004
    13 October safety announcement (opens in a new tab)

    Current publisher page. Byte-identical to the ARGUS capture of 14 October 2026 when re-checked the same day.

    Dates, capture hash and release-time limits
    Publisher date
    JSON-LD datePublished 2026-10-13T18:00:00Z, dateModified 2026-10-13T18:03:03.833342Z in retained HTML; no numbered revision.
    ARGUS capture
    2026-10-14T09:45:13Z; 978,720 B; 8e41264d6080414c1d846ce01b604dec87e550eaf586e1aa23dacbe4d81ee4d5
    Pages and case use
    HTML, pages N/A; paragraphs beginning “Today, we are beginning to roll out Argon broadly” and “Misuse prevention across high-risk domains”
    Release-time qualification
    Publisher-dated release-day post, retrieved next day. Historical HTML byte identity at posting time not authenticated. Summary of report, not independent test evidence.
  • P3-SRC-005
    30 September initial announcement (opens in a new tab)

    Current publisher page. Byte-identical to the ARGUS capture of 14 October 2026 when re-checked the same day. The page itself was modified on 1 October 2026.

    Dates, capture hash and release-time limits
    Publisher date
    JSON-LD datePublished 2026-09-30T20:00:00Z, dateModified 2026-10-01T21:09:53.663080Z; no numbered revision.
    ARGUS capture
    2026-10-14T09:45:23Z; 1,013,487 B; 75294b5d9676a1b969ef867aad1fdebb041d106281337a864f7a8d8b1b7e6507
    Pages and case use
    HTML, pages N/A; “Leading in defensive cybersecurity,” “Strengthening frontier safeguards before broad availability,” “Rolling out soon”
    Release-time qualification
    Distinct restricted Fairwind phase. The post states trusted defenders/internal teams would receive Argon without cyber guardrails and broad release was future. Retrieved version has a 1 October modification; exact 30 September bytes not authenticated. Never use its access terms as broad-release terms.
  • P3-SRC-006
    13 October broad-launch announcement (opens in a new tab)

    Current publisher page. Byte-identical to the ARGUS capture of 14 October 2026 when re-checked the same day.

    Dates, capture hash and release-time limits
    Publisher date
    JSON-LD datePublished 2026-10-13T16:00:00Z, dateModified 2026-10-13T16:33:42.376998Z; no numbered revision.
    ARGUS capture
    2026-10-14T09:50:13Z; 1,032,640 B; a53dbf194157dad3cb58de791f3dc93ba0934dc3f2394951821869d0890251b9
    Pages and case use
    HTML, pages N/A; opening availability paragraph and “Bringing state-of-the-art cyber capabilities to more trusted defenders”
    Release-time qualification
    Publisher-dated release-day post, retrieved next day. It lists broad surfaces and expansion of Fairwind separately. Exact release-time HTML bytes not authenticated.

Historical custody rule

Publication dates, date-modified fields, retrieval timestamps, evaluation checkpoint dates and byte provenance answer different questions. These October 14 captures establish what was publicly served at retrieval. Publisher links and dates support likely October 13 availability of the card/report, but cannot by themselves prove byte identity at the release boundary. No pre- or same-day archived byte comparison was located in this bounded public acquisition.

Research boundary

Published by Automa Dynamics / ARGUS. Independent research; no affiliation, endorsement or certification by Google or Google DeepMind.

Gaps describe the inspected public record. They do not mean Google lacks private evidence, that a control failed, that a policy was breached or that an incident occurred.

Counts are link judgements, not safety scores, and no cross-model ranking is made.

Proof-3 artifacts

Graph SHA-256 7daea553666caed2ed498a5795f06252d31ddde03f5b223a053a799653068469