Anthropic turns cyber-model access into a three-tier professional programme

Anthropic expanded its Cyber Verification Program on 6 October into three tiers for qualifying security professionals. The distinction is the work permitted and the controls attached—not merely which model name appears in a menu.[1]

This matters because two people using an apparently identical AI system may have materially different capabilities available to them. A refusal may reflect a deployment boundary rather than an inability to reason through the problem. Conversely, permission to proceed says nothing by itself about whether the resulting work is correct. Those are separate dimensions of a product that buyers increasingly need to evaluate together.

The experiment separates refusal from capability

Anthropic tested Opus 5.5 on ten CyScenarioBench challenges, with five attempts per challenge and access configuration. These are fifty trials, not fifty distinct challenges. The outcomes separate blocking from successful completion.[1]

A useful reading of that result is that an access policy can change how much of a model’s underlying capability reaches the user. A much less defensible reading would be that the experiment proves the entire programme safe. It does not measure every malicious applicant, stolen account, production environment or way a permitted workflow could be repurposed. The experiment answers a narrower question, and that narrower answer is still informative.

Irregular’s separate 22 September assessment describes a 67.6% average solve rate for Opus 5.5 on a ten-challenge subset with cyber mitigations disabled. It says Anthropic used its benchmark and revised the evaluation harnesses. This is valuable configuration context, not an independent reproduction of the October tier experiment or a controlled measurement of real-world attack success.[4]

Why the benchmark is more than a coding test

CyScenarioBench’s designers describe a shift from isolated technical exercises to sequences involving planning, changing conditions and recovery from inconsistent state. Their working-draft methodology keeps scenarios private to reduce contamination. It also acknowledges artificiality in simulated environments and incomplete coverage of coordinated multi-agent behaviour.[3]

The important distinction is orchestration: getting several individually plausible actions to form a valid whole. In an authorised defensive investigation, correctly interpreting one alert is only a start. The team must connect it to the right system, establish what evidence is missing and choose an action consistent with the investigation’s scope. A fluent description at one stage does not establish that the overall conclusion follows.

That is why organisations should keep at least two scorecards. One measures whether the model can complete permitted work. The other measures whether the surrounding system preserves scope, attribution and a reliable record of what happened. A strong result on either scorecard cannot substitute for the other. This is our evaluation framework, not an additional result claimed by the benchmark authors.

A verified account becomes something valuable to steal

The published security requirements make this concrete. Granted access must remain attributable to named users or workload identities; shared sign-ins and sessions are prohibited. A named security contact must be able to act on alerts. These controls address who is actually using the capability after the initial applicant has been approved.[2]

For Defense Access, multifactor authentication is required when access is granted. By 15 December 2026, the requirements call for phishing-resistant authentication, such as passkeys or security keys, and replacement of static or long-lived model credentials. Interim API keys must be individually assigned, securely stored, excluded from source code and replaced at least every seven days. The detailed requirements differ by deployment platform and tier.[2]

The practical implication is that a team should budget for an access lifecycle, not just an application. Someone joins, receives the minimum appropriate access, changes responsibilities, and eventually leaves. Automated work needs its own identifiable credentials. If a single shared secret is copied into multiple scripts, revoking one person’s access becomes difficult to separate from shutting down everybody’s work.

This does not imply that every organisation needs an elaborate new bureaucracy. It means the operational design should answer a small set of concrete questions before deployment: whose authority is being exercised, on which assets, for what purpose, and how can that authority be withdrawn? A capability grant without those answers is a fragile foundation for automation.

Data custody and monitoring are different choices

Anthropic’s proposed Enterprise Frontier Safeguards offers another revealing distinction. Its September design places activity data in cloud infrastructure controlled by the customer, under the customer’s keys and policies. Automated monitoring analyses patterns across a rolling window; flags go to the customer for review rather than requiring Anthropic employees to inspect them. The announcement describes a phased rollout beginning later in the autumn.[5]

That is not the same promise as “no logs exist anywhere”. Data location, retention period, automated analysis and human access are four different properties. A security team may be comfortable retaining an investigation trail in its own controlled environment while rejecting a copy stored under a supplier’s control. Procurement language should state which property is being promised instead of relying on an ambiguous privacy label.

The programme retains data by default, with limited exceptions while EFS is pending. Applicants need their current grant terms, not a future architecture’s promise.[1]

The larger change is a new kind of AI product boundary

Model capability used to be discussed mainly as a leaderboard question. This release makes a different boundary visible: the useful product is capability combined with an identity, an authorised scope and a monitored deployment. The same technical advance can be more or less useful depending on how those conditions are implemented.

The programme should ultimately be judged on more than successful applications or fewer refusals. Does permitted defensive work reach a verified resolution sooner? Are legitimate users able to understand and challenge inappropriate blocks? Can misuse be detected without unnecessarily exposing confidential investigations? Those are the outcomes that would establish whether tiered access gives defenders a durable advantage.

Report an error or suggest a correction