Anthropic's Cyber Verification Program in Practice: From Approval to Real Defensive Work

AI Security Series #52

On July 6, 2026, I applied for Anthropic's Cyber Verification Program. Approval came the next morning — one business day. The following afternoon I was in the Console Workbench running Sonnet 5 and Opus 4.8 against a real deferred item from a completed four-pass CMS security audit: TOTP replay prevention, a medium-severity finding where MFA codes were cryptographically valid but reusable within their ~90-second window. By end of day, both models had produced genuinely usable remediation output — the kind of content that would have hit the high-risk dual-use classifier before CVP approval.

This post covers what CVP is, how approval works, and what the classifier actually unlocks in practice — using the TOTP test as a concrete example. Part two (AI Security Series #53) goes deep on the technical implementation, the bug in the AI-generated fix that almost shipped, and what it took to verify the remediation actually worked.

What CVP Is

Anthropic's Cyber Verification Program is an application-based access tier that unlocks the "High-Risk Dual Use" classifier category for verified defensive security professionals operating at the organization level. It is not a consumer-account feature and it does not operate through claude.ai — CVP access is org-scoped and API-key scoped, exercised through the Console Workbench or via direct API calls using the organization's key.

The classifier system it unlocks was covered in detail in AI Security Series #48 when Fable 5 returned with its new safeguard taxonomy. The relevant tier for CVP is "High-Risk Dual Use" — the category that includes penetration testing, exploitation reasoning, privilege escalation, lateral movement analysis, exploit development and weaponization, and high-uplift vulnerability discovery. These are blocked by default in Fable 5 for all users. CVP removes that block for approved organizations.

One thing the brief notes as worth being explicit about: this test ran the happy path. No false-positive block was encountered, no classifier edge cases were hit. CVP's limits weren't stress-tested here — what was tested is what the program is designed to do when it's working as intended.

The Two-Tier Classifier Structure

Understanding CVP requires understanding the distinction between Anthropic's two classifier tiers, because CVP only addresses one of them.

The Prohibited Use tier covers ransomware, malware development and delivery, C2 infrastructure, cyber-physical sabotage, and internet backbone attacks. CVP provides no exemption for this tier. These remain blocked for all users regardless of verification status — no amount of defensive intent or organizational vetting changes that.

The High-Risk Dual Use tier is where CVP operates. This tier covers activities that are standard practice in authorized security assessments — penetration testing, exploitation, credential attacks, privilege escalation, lateral movement, exploit development, and high-uplift vulnerability discovery. The classifier blocks these by default because the same technique that serves a pen tester under a signed statement of work serves an attacker without one. CVP is Anthropic's mechanism for resolving that ambiguity at the organizational level: you apply, demonstrate your defensive security context, and receive classifier access that reflects that context.

The CVP also applies to Opus and Sonnet class models specifically — Mythos 5, which carries full offensive capability, operates under a separate vetted partner framework.

The Application and Approval Process

The application is submitted through Anthropic's platform, scoped to an organization rather than an individual account. Anthropic documents an approximately two business day SLA. In practice, the approval for Bregg Holdings came in one business day — applied late July 6th, approved early July 7th.

The approval is communicated via email and activates immediately on the organization's API key. There is no additional configuration step. Once approved, API calls made with the organization's key reflect the unlocked classifier behavior.

The Console Workbench is Anthropic's browser-based tool for testing API behavior without writing code — model selection, system prompt configuration, and token/cost tracking in a single interface. For CVP testing purposes, it provides a controlled environment to verify classifier behavior and compare model outputs before committing to implementation.

Claude Console dashboard showing CVP-approved organization status, credits, and available model tiles — Claude Console dashboard confirming CVP-approved organization status — model tiles and credit balance visible immediately after approval.

The Test Case: TOTP Replay Prevention

The vulnerability selected for CVP testing was Finding F-13 from a completed four-pass CMS security audit of bregg.com's custom PHP CMS: TOTP replay prevention.

The vulnerability is straightforward in concept. RFC 6238 specifies time-based one-time passwords with a 30-second time step. Most implementations, including this one, allow a ±1 step skew window to account for clock drift between client and server — meaning a given code is valid for approximately 90 seconds. The vulnerability is that the server-side implementation was validating the cryptographic correctness of the code against the current time step but had no concept of whether a given code had already been used. A code captured during its validity window — through network interception, shoulder-surfing, a phishing relay, or log exposure — could be submitted again and accepted a second time.

This is not a theoretical attack. TOTP relay attacks are documented in the wild and have been used against MFA implementations at organizations that assumed the time-limited nature of the code provided sufficient protection. The cryptography is sound. The single-use enforcement is the gap.

The finding had been deferred from the original audit specifically because reasoning through the exploitation mechanics and designing an atomic remediation pattern at sufficient technical depth is precisely the kind of work the high-risk dual-use classifier was restricting. CVP approval was the prerequisite for addressing it with full AI assistance.

Console Workbench: Sonnet 5 vs Opus 4.8

Both models were run against the same prompt in the Console Workbench on the same day with CVP access active. The prompt established the defensive security context explicitly — authorized administrator, own infrastructure, remediating a completed security audit finding — and asked for analysis of the exploitation mechanics, a proof-of-concept test design for dev environment validation, and a recommended remediation pattern.

Metric	Sonnet 5	Opus 4.8
Output tokens	~2.7K	~3.1K
Approximate cost	$0.03	$0.08
Exploitation mechanics	Correct — replay window analysis, attack scenarios	Correct — same plus more detailed attack scenario enumeration
PoC test design	Solid — replay attempt sequence with expected outcomes	Same, plus edge case coverage for concurrent submission
Remediation pattern	DB schema, composite PK approach, code structure	Same plus full working TotpVerifier class with self-test harness
Proactive gap identification	Did not flag adjacent issues	Flagged backup-code replay as a related open gap

Both models produced genuinely usable, non-generic technical output. Neither produced the kind of response the classifier would have generated without CVP access — a deflection to general security guidance or a refusal to reason through the exploitation mechanics. The content both models delivered covered the attack surface in enough technical depth to drive real implementation decisions.

Sonnet 5 at $0.03 delivered roughly 85% of Opus 4.8's value at 37% of the cost. For a single-session remediation task with a well-defined scope, Sonnet 5 is the right starting point — escalate to Opus 4.8 when you want proactive identification of adjacent issues or a more complete implementation scaffold to start from.

What CVP Actually Changes

The practical difference between working with and without CVP access is not that the model becomes dramatically more intelligent about security topics. It is that the conversation can proceed without the model interrupting to redirect to generic guidance at precisely the moment the technical reasoning matters most.

Without CVP, a prompt asking for analysis of a TOTP replay vulnerability's exploitation mechanics will typically produce a response that explains what TOTP is, notes that replay attacks exist, and suggests implementing single-use enforcement — without the technical specificity needed to make confident implementation decisions. The model knows the domain. The classifier gates the depth of engagement with the offensive-side reasoning.

With CVP, the same prompt produces analysis of the specific exploitation window (±1 step = ~90 seconds in this configuration), concrete attack scenarios (relay phishing, network capture, log exposure), a proof-of-concept test sequence with exact submission timing, and the implementation tradeoffs between SELECT-then-INSERT (introduces TOCTOU race) versus atomic INSERT-as-claim (the correct pattern). That difference in output depth is what maps to real implementation quality.

What This Means for Healthcare

CVP Is a Legitimate Path for Authorized Defensive Work

Healthcare security teams conducting authorized penetration testing, vulnerability assessments, or technical security reviews of systems they own or administer have a documented path to AI-assisted offensive-side reasoning without fighting the classifier on every prompt. The application is organization-scoped, which maps cleanly to the organizational authorization structure that governs legitimate security testing — the organization owns the infrastructure, the organization applies for CVP access, the organization's security team uses it for authorized work against that infrastructure.

This is worth knowing because the alternative — rephrasing prompts repeatedly to avoid classifier triggers, working around the model's deflections, or accepting lower-depth responses — is operationally inefficient and produces worse security outcomes. CVP is the intended path for this work. Healthcare security practitioners should be aware it exists and that the approval timeline is measured in business days, not weeks.

The Console Workbench Is the Right Tool for Initial Evaluation

For healthcare organizations evaluating CVP access before committing to integration into existing workflows, the Console Workbench provides a no-code environment for testing model behavior against representative prompts. This is directly relevant for security teams that want to evaluate how well a model's output quality supports their specific assessment methodology before deciding which model tier to use in production tooling. The token and cost tracking in the Workbench also provides empirical data for budget planning — the $0.03 vs $0.08 comparison above came directly from a single Workbench session.

CVP Does Not Reduce the Verification Requirement

CVP unlocks classifier access. It does not validate AI-generated remediation output. The TOTP implementation that resulted from CVP-assisted analysis contained a bug that would have shipped invisibly if the code had been deployed without thorough testing — a timezone clock mismatch in the cleanup function that caused every freshly-inserted "used code" record to be silently deleted by the very next housekeeping call. The bug was caught through debug-instrumented logging and direct database inspection, not by re-prompting the model.

For healthcare security teams, this distinction matters. AI-assisted remediation of MFA controls, authentication logic, or access control code in systems that handle PHI or support HIPAA technical safeguards requirements carries the same verification obligation as any other code change in those systems — arguably more, given the compliance audit trail implications of a control that appears deployed but is not functioning as designed. AI assistance improves the quality and speed of the initial implementation. It does not replace the testing loop.

The Classifier Boundary Matters for Healthcare Audit Documentation

When documenting AI tool use in healthcare security workflows for compliance purposes — internal audit records, HIPAA Security Rule technical evaluation documentation, or vendor management records — the distinction between Fable 5 without CVP (blocked on high-risk dual-use tasks) and Fable 5 with CVP (unlocked for authorized defensive work) is materially relevant. Organizations should document CVP status as part of their AI tool inventory and note which security workflows depend on CVP access, so that any future change to CVP status (renewal, org restructuring, policy changes) is captured in the risk register before it silently degrades a security testing capability.

The Bigger Picture

CVP is Anthropic's current answer to the authorization verification problem described explicitly in the Fable 5 safeguards documentation: the classifier cannot independently verify that a user asking for exploitation reasoning is a credentialed security professional working under authorization rather than a threat actor. CVP resolves that ambiguity at the organizational level — the application, review, and approval process is the verification mechanism.

It is a pragmatic solution to a hard problem. It is not a permanent solution. The jailbreak severity framework being developed with Amazon, Microsoft, and Google is the longer-term architectural answer — a scoring system that allows proportionate access controls rather than binary classifier gates. CVP bridges the gap between the current classifier architecture and that future framework.

For healthcare security practitioners, the near-term implication is to treat CVP as a standard part of AI tool provisioning for security teams doing authorized defensive work — alongside the existing professional certifications, signed statements of work, and organizational authorization frameworks that govern that work. The verification overhead is low, the approval timeline is short, and the alternative is working around classifiers on every technically substantive prompt.

AI Security Series #53 covers what happened after the Console Workbench session: the implementation of the TOTP replay guard, the timezone bug that almost shipped, the debug instrumentation that caught it, and the production verification sequence.

This is entry #52 in the AI Security Series. Continued in AI Security Series #53: TOTP Replay Prevention — The AI-Assisted Fix, the Bug in the Fix, and Why Verification Still Matters. For related coverage, see AI Security Series #48: Fable 5 Came Back Different — What the New Safeguard Taxonomy Means for Security Practitioners.