This is controlled access, not a general scanner
Anthropic’s October 6 announcement describes an expanded Cyber Verification Program for qualifying security professionals. It says the program uses three access tiers with different verification requirements and security controls, and that applicants must provide proof of the controls required for the tier. The announcement presents the offer as a way to make more capable models available for defensive security work.
A buyer should not read that as blanket access for any company that labels a task defensive. The qualification and tier boundaries are part of the program. Nor does a model’s availability establish that it is suitable for a particular environment or authorized to touch production systems. The organization still owns the scope, authorization, isolation, and review around its use.
Write the defensive scope before the application
Describe the systems, assets, and activities the team is authorized to assess. Name the owner who can approve a test, the boundaries on data access, and the conditions that stop work. If a task involves customer infrastructure or a third-party codebase, preserve written authorization and define what the model or operator may inspect and modify.
Then separate information retrieval from active testing. Reading public advisories or reviewing a patch is different from executing a scan, attempting exploitation, or making a change in a live environment. Each step should have its own permissions and approval path. This prevents a broad prompt from silently turning a defensive review into an unapproved action.
Design for containment and evidence
Use a test environment that mirrors only the needed parts of production. Limit credentials, outbound network access, and write permissions. Keep the model’s work in a sandbox, log the commands and tools it requested, and require a qualified operator to review any proposed change before it reaches a protected system.
A useful exercise also needs evidence. Record the target scope, the model and tool configuration, the finding, the validation method, and whether a human reproduced it. Label unverified suggestions as leads, not vulnerabilities. Security teams should be able to close a false alarm without losing the reasoning that led to it.
Measure quality without promoting vendor claims
The announcement includes Anthropic’s own evaluation results. Treat those as vendor-reported evidence about the company’s test setup, not as a performance guarantee for your team. Measure the things that affect your work: in-scope finding rate, false positives, time to reproduce, review effort, and whether the system respects explicit stopping conditions.
Before a wider pilot, write a small set of benign, authorized cases and define what counts as a safe result. Include a case where the right action is to stop and ask for approval. Make sure the evaluator checks both the final answer and the actions taken along the way. A successful benchmark score is not a substitute for local validation.
Use tiering as a governance prompt
Different access tiers create a reason to align capability with role. Map who needs access, what work they do, what controls are already in place, and who reapproves access when the task or team changes. Keep the scope narrow enough that access can be reviewed regularly rather than granted as a permanent general-purpose privilege.
For a security lead, the next action is a short readiness review with the people who own incident response, platform permissions, and risk approval. Confirm program eligibility from Anthropic’s current materials, then test one bounded workflow in an isolated environment. Do not infer eligibility, availability on a particular cloud, or the result of an application from a public announcement alone.