Claude Opus 5.5

Scope

The claim under examination

On 22 September 2026, Anthropic announced general access to Claude Opus 5.5 with cyber safeguards intended to enforce the same policy as Claude Opus 5. Its system card reported robustness comparable to Claude Fable 5 and Fable 5.1, and greater robustness than Opus 5. That comparative language is Anthropic’s claim, not an independently reproduced ARGUS ranking.

ARGUS reconstructed this one bounded claim, P2-C-001, from the published system card, release announcement, policy chronology and associated evaluation descriptions. The result contains 50 typed nodes, 121 edge records, 23 evidence objects and eight unresolved public-assurance gaps. These figures describe the research artifact; they are not safety scores.

The Executive assurance graph provides a readable claim-to-gap route. The Full graph exposes each evidence record, dependency, assumption, source locator and ARGUS-written warrant.

Findings

What the public evidence supports

A described safeguard architecture

Anthropic describes an activation probe, a lightweight classifier running with Opus 5.5 and a separate trained language-model classifier. It also describes a temporarily wider blocking margin, adversarial-training additions and a policy distinction between source-code vulnerability discovery and compiled-binary exploitation. These are substantive descriptions of the intended release controls. Published coverage summaries are useful evidence, though they do not provide an independently auditable matrix of every deployed classifier version, interface and error rate.

Substantial testing, including uncomfortable results

The system card reports adversarial testing against production safeguards. Its no-critical-jailbreak observation is made under Anthropic’s severity framework; it is not a guarantee that jailbreaks or harmful outputs cannot occur. In contracted testing, Trajectory Labs reportedly spent about 95 hours and made more than 29,000 requests, identifying 13 candidate breaks across seven tasks and producing a working exploit chain. Other reported campaigns had more favourable outcomes. The published material does not provide enough per-case severity adjudication for ARGUS to independently decide whether any finding met Anthropic’s critical threshold.

Section 3.5’s robustness work used an earlier model snapshot. Anthropic says the safeguards and findings are representative of the released model. The public passages examined do not supply a paired mapping of tested and final model, classifier and fallback configurations. This qualification is specific to those evaluations; it should not be applied indiscriminately to every result in the system card.

Fallback changes the system being assessed

When a cyber classifier blocks a request, Anthropic describes automatic fallback to Claude Opus 4.8 in its own applications. On the API, model switching requires developer opt-in, and other providers may differ. The release’s safety properties therefore depend partly on routing, interface and enabled protections, not only on the primary model.

The system card reports zero successful attacks among 1,310 fallback-served rollouts in one static prompt-injection test. That is a narrow rollout-level result, separate from its overall 1.0% attack-success probability at k=15. In adaptive coding experiments, reported attack-success rates were 54.61% without prompt-injection probes and 11.13% with probes. Those percentages are overall attempt-level rates among valid responses, across direct and fallback arms; they are not fallback-only rates. All observed successful attacks in those coding arms were served by the fallback model. The no-probe arm still retained cyber blocking and fallback; it did not disable every safeguard.

GUI experiments also reported a small number of successful attacks served by the primary model, while separate protected browser tests reported no successes in their tested configuration. The card further documents a residual vulnerability to malicious text pasted by a user, alongside favourable product-mitigation tests. These experiments vary in setup, denominators and deployed protections. Their results cannot be pooled into a general incident probability or a claim that every interface is equally protected.

Open links

The eight open public-assurance gaps

The gaps below are ARGUS analyst groupings. Each describes evidence that could close or narrow the relevant public link. Different groupings would be possible.

1. 1. G-001

   Coverage and release operation. A versioned, interface-specific record of deployed controls and audited coverage would connect the described architecture to the system users received.

2. 2. G-002

   Severity and comparative robustness. Sanitised adjudications of candidate breaks, their four-axis severity assessments and matched-condition comparisons would make reported robustness more independently challengeable.

3. 3. G-003

   Earlier-to-final snapshot transfer. A mapping of tested and released versions, with targeted final-snapshot checks or an auditable invariance argument, would strengthen the claimed transfer.

4. 4. G-004

   Composite fallback and surface behaviour. Per-path outcomes and testing across application, API, coding, GUI, browser and pasted-text configurations would clarify end-to-end protection.

5. 5. G-005

   Reproducibility and independent corroboration. Evaluation manifests, denominators, uncertainty and independently authored cyber findings would narrow reliance on publisher-mediated results. METR's separate work concerns AI R&D, not independent verification of the cyber-release case.

6. 6. G-006

   Capability-to-tier mapping. A model-specific explanation of novelty, autonomy and operational criteria would clarify how observed capability relates to the framework's cyber tiers.

7. 7. G-007

   Model-specific risk acceptance. A dated public or independently audited summary linking adverse results, safeguards, margins, fallback and monitoring to the relevant risk-owner decision would support a stronger release-acceptance interpretation.

8. 8. G-008

   Historical framework custody. An authenticated release-day copy or credible unchanged-content attestation would clarify whether the reviewed Frontier Compliance Framework v2 text matches the exact version available on 22 September 2026.

Limitation

The Frontier Compliance Framework limitation

The reviewed Frontier Compliance Framework identifies version 2, effective 24 July 2026. ARGUS verified the integrity of a retained October copy, but did not authenticate its exact byte identity on the September release date. An independently accessible, non-NDA direct PDF destination was not established for the public website. Consequently the interactive evidence presentation labels the framework as an access and historical-provenance limitation, without a misleading download action.

The framework describes general cyber tiers and decision processes, but the public materials inspected do not establish a signed, Opus-5.5-specific risk-acceptance determination. This is a limit on what the present reconstruction can conclude, not a finding of noncompliance. No NDA-protected Trust Center information was used.

Method

How to read this work

ARGUS is an independent documentary reconstruction, not a penetration test of the deployed service, a safety certification, or a comparison of frontier models. Its typed graph separates publisher statements from ARGUS interpretation, and shows assumptions, competing explanations, adverse findings and proposed evidence for closure.

An independent-of-author source-to-visual fidelity audit found no material representation error and prompted presentation corrections. That check is not external scientific peer review; this Proof-2 study has not been externally peer reviewed. The research boundary is the 22 September 2026 release, with later context separately labelled. The research was filed on 11 October 2026.

Readers are invited to examine particular edges or evidence records and challenge them with source locators, contrary evidence or a better argument. Criticism that narrows or corrects an assurance link is a useful outcome of the project.

Provenance

Public sources and provenance

• P2C-SRC-001
  Anthropic, Claude Opus 5.5 System Card ↗ (opens in a new tab)

  Primary system-card release record. The separately archived 22 September copy has authenticated release-day custody; current PDF bytes were not compared with it.

• P2C-SRC-002
  Anthropic, Introducing Claude Opus 5.5 ↗ (opens in a new tab)

  Public release announcement. Current page content is not asserted byte-identical to the historical capture.

• P2C-SRC-003
  Anthropic, Responsible Scaling Policy v3.4 ↗ (opens in a new tab)

  Publisher policy chronology; exact historical bytes not authenticated.

• P2C-SRC-004
  Anthropic, Responsible Scaling Policy version history ↗ (opens in a new tab)

  Publisher policy chronology; exact historical bytes not authenticated.

• P2C-SRC-005
  METR, Summary of predeployment evaluation of Claude Opus 5.5 ↗ (opens in a new tab)

  AI R&D evaluation context, not independent cyber-release validation.

• P2C-SRC-006
  Claude Help Center, automatic model switching FAQ ↗ (opens in a new tab)

  Later, post-release context only.

• P2R-SRC-001

  Anthropic, Frontier Compliance Framework v2 NO PUBLIC LINK

  Publisher-dated 24 July 2026 framework; no independently verified direct public PDF link for this presentation; exact 22 September bytes unauthenticated.

Current publisher URLs do not establish byte identity with the authenticated release-day captures. The Anthropic Trust Center, which is NDA-gated, was not used.