Anthropic expanded its Cyber Verification Program (CVP) on 6 October 2026 into three access tiers: Defense Access, Red Team Access and Specialized Access. The change gives verified defenders progressively fewer cyber blocks, but it also raises the operational bar for identity, credentials, device management, network egress, logging and incident response. The practical takeaway is simple: reduced model blocking is not a substitute for authorization. A production deployment needs a controlled security workspace where every person, workload, target and outbound connection is attributable and revocable.
The official announcement, CVP Help Center guide and security requirements were verified on 7 October 2026. Tier eligibility, supported models, provider availability, retention requirements and deadlines below are Anthropic statements. The reference architecture, rollout gates and implementation patterns are engineering recommendations, not claims that approval or safe operation is guaranteed.
What changed in the Cyber Verification Program
Anthropic combined its earlier CVP and Project Glasswing work into one expanded program. All three tiers can include Claude Opus 5.5, Claude Sonnet 5.5, Claude Mythos 5.1 and future models, subject to the grant and platform. The tiers differ by authorized work and the controls required around that work.
Defense Access covers defensive activities such as security operations, incident response, malware reverse engineering, and vulnerability analysis or validation. It is the only tier available to individuals. Red Team Access adds authorized penetration testing and adversarial exercises, but remains limited to organizations and authorized targets. Specialized Access has the fewest cyber blocks and is reserved for deeply verified organizations testing high-risk systems such as power grids, flight operations, telecom networks and interbank infrastructure.
Anthropic says generally available Claude models remain suitable for secure code review, threat modeling, patching known issues, finding vulnerabilities in owned source code and triaging alerts. That matters: teams should not apply for broader capability merely because ordinary secure-development work is possible without it.
Work Starting point
Secure review and patching in owned code General Claude access
SOC triage, malware analysis, validation Defense Access
Authorized penetration test or red-team work Red Team Access
Testing high-risk safety or market systems Specialized Access
Unknown ownership or missing authorization Do not run the activityThe right tier is therefore a scope boundary, not a quality setting. A stronger grant does not create permission to test a system. Written authorization, target ownership, rules of engagement and local law remain separate prerequisites.
The important change is the control plane
The headline is reduced blocking. The engineering change is that access becomes a privileged capability that needs its own control plane. Anthropic's requirements make identity attribution, short-lived credentials and revocation part of the product contract. Treat the CVP grant like production access to a sensitive environment, not like a model dropdown.
A useful control plane has six responsibilities:
1. Authenticate a named person or workload through a trusted identity provider. 2. Authorize the requested tier, workspace, target and test window. 3. Issue short-lived credentials instead of distributing static API keys. 4. Create an isolated execution environment with controlled tools and outbound routes. 5. Record attributable activity without exposing logs to unnecessary users. 6. Revoke access and preserve evidence when a session or identity is compromised.
Anthropic requires a named security contact at every access level. It also requires attributable profiles, personal sign-ins and incident cooperation. For Defense Access, phishing-resistant MFA and the end of long-lived static credentials become mandatory by 15 December 2026. Red Team and Specialized Access require those stronger controls from the start, along with tighter user, device, gateway and network restrictions.
This should change the system diagram. An application should not call the model directly from a developer laptop using a shared key. A broker should exchange a verified human or workload identity for a short-lived model credential, attach immutable authorization context and send the job into a disposable cyber range.
Reference architecture for controlled cyber work
The smallest credible architecture separates the orchestration plane from the execution plane.
Identity provider + phishing-resistant MFA
|
v
Policy broker: tier + workspace + target + time window
|
short-lived credential
|
v
Disposable sandbox / cyber range
- read-only task bundle
- scoped tool allow-list
- off-host egress allow-list
- isolated secrets
|
v
Claude endpoint + safety controls
|
v
Tamper-evident audit + findings review + revocationThe policy broker should reject a job unless it can prove four facts: who is responsible, which grant applies, which assets are authorized, and when the authorization expires. A target should be represented by stable identifiers such as cloud account, repository, application, domain or CIDR range—not free text that an agent can reinterpret.
The sandbox should start from a clean image for each engagement. Mount only the task inputs needed for that session, expose only approved tools, and destroy the environment after exporting reviewed findings. Never place production cloud credentials, signing keys or unrestricted vulnerability scanners in the same context as untrusted evidence.
For agentic work, Anthropic requires outbound traffic to be limited by an allow-list enforced off the host and logged for Red Team and Specialized Access. Off-host enforcement is important because a compromised tool or agent must not be able to edit the rule that contains it. DNS, HTTP proxy and cloud firewall logs should share a session identifier with the model request and sandbox.
Replace API keys with workload identity
Static keys are operational debt in any system; inside a privileged cyber environment they are also a pivot point. Anthropic's rules disallow long-lived static credentials at the stronger access levels and require platform-native short-lived credentials. Defense Access has a transition window until 15 December 2026, with interim keys stored in a secrets manager, assigned to one person or workload and rotated at least every seven days.
Prefer Workload Identity Federation or the equivalent native flow on the deployment platform. The workload proves its identity to AWS, Google Cloud, Azure or Anthropic, then receives a credential with a short expiration. The broker records the subject, audience, workspace, tier and expiry. No reusable secret needs to sit in source code, CI variables or a developer shell.
An authorization envelope can look like this:
{
"subject": "workload:redteam-runner-17",
"grant": "red-team",
"workspace": "payments-security",
"engagement": "2026-q4-gateway-test",
"targets": ["api.staging.example"],
"expires_at": "2026-10-07T12:00:00Z",
"egress_policy": "gateway-test-v4"
}This is an application-side example, not an Anthropic API schema. Sign it, validate it at every boundary and refuse execution after expiry. Do not let the model add targets, extend the engagement window or change its own egress policy.
Separate authorization from model safeguards
Model safeguards and organizational authorization solve different problems. Safeguards reduce the chance that disallowed content or actions pass through the model. Authorization proves that a particular team may perform a particular activity against particular assets. Either can fail independently.
Anthropic reports that, in its CyScenarioBench evaluation, the generally available configuration blocked every task at the first prompt. Defense Access blocked 46 of 50 trials at some point, while Red Team Access produced no blocks and completed 34 of 50 tasks—similar to the unsafeguarded completion rate used as a Specialized Access reference. Those are provider-reported evaluation results, not evidence that a real deployment is safe or effective.
Use four enforcement layers:
- Provider safeguards for broad misuse prevention. - Organization policy for users, grants, targets and time windows. - Sandbox and network controls for tools, secrets and egress. - Human approval for findings disclosure, target-impacting actions and escalation.
Do not weaken local controls because the provider approved a grant. The model should never be the authority for whether a target is in scope, whether destructive testing is allowed, or whether a finding may be disclosed.
Retention, monitoring and sensitive evidence
Anthropic requires data retention for CVP so it can monitor for cyber misuse, with limited exceptions described for eligible Fable or Mythos customers. The company says Enterprise Frontier Safeguards (EFS), planned to roll out in phases, will let eligible organizations keep activity data in cloud infrastructure they control while automated safety systems analyze patterns and route flags to the customer's reviewers.
Treat retention as an architecture decision before applying. Security transcripts can contain source code, indicators of compromise, credentials accidentally exposed by tools, exploit details and regulated incident data. Define which environment may process each evidence class, who can inspect a flag, how long raw transcripts remain, how deletion is proven and how legal holds override deletion.
Minimize at ingestion. Replace live credentials with test secrets. Prefer reproducible samples over full production datasets. Store large artifacts in a controlled evidence repository and pass scoped references when possible. Encrypt logs under customer-managed keys where supported, keep audit access separate from analyst access, and log every human read of sensitive transcripts.
EFS does not remove the need for a local data classification. Customer-owned storage changes custody; it does not automatically make every workload compliant.
Design the workflow around evidence and review
The output of an AI-assisted security session should be a finding package, not an uncontrolled shell history. Require a structured record containing the authorized target, observation, reproduction steps, evidence references, severity rationale, affected versions, confidence and proposed remediation. A human reviewer should confirm that the evidence supports the claim and that the finding belongs to the engagement.
For vulnerability discovery, separate verification from disclosure. The agent may prepare a proof in an isolated environment, but a human should decide whether it is safe to reproduce, how to redact it and which disclosure channel applies. For incident response, keep containment commands behind an approval gate; analysis may be automated while production mutations remain deterministic and role-controlled.
Evaluation should cover both useful work and control failures. Measure valid findings, duplicates, false positives, remediation acceptance and analyst time saved. Also measure denied out-of-scope targets, blocked egress, credential leakage, unauthorized tool requests, stale grants and mean time to revoke. A capability evaluation without a containment evaluation is incomplete.
Best practices and anti-patterns
Start with Defense Access and a narrow workflow unless the work demonstrably needs more. Put a single organization owner over grants and workspaces. Use separate workspaces for ordinary development and privileged cyber activity. Require an engagement record before issuing a session. Keep credentials short-lived, sandbox images disposable and egress policy external to the sandbox. Review logs for anomalous cross-session patterns, not only individual prompts.
Avoid shared accounts, shared API keys and personal devices. Do not proxy CVP access to unapproved users. Do not mix customer-facing product traffic with an internal cyber grant; Anthropic says productization is governed separately. Do not send an agent toward an asset named only in a prompt. Do not treat a successful exploit as a complete finding without scope, evidence and remediation. And do not interpret fewer provider blocks as permission for autonomous destructive actions.
Use the Claude Opus 5.5 migration guide when selecting the model and rollout cohort, the Anthropic Models API routing guide to avoid brittle model-ID parsing, and the Claude Code Mods security architecture for local event controls. For a broader implementation review, see AI integrations and retrieval systems.
When not to use expanded CVP access
Do not use it for ordinary code review or patching when general access is sufficient. Do not apply if the organization cannot enforce named access, phishing-resistant MFA, short-lived credentials, timely offboarding, revocation and logged network boundaries. Do not run offensive workflows when authorization is verbal, ambiguous or broader than the actual target list. Do not use privileged access as the backend for a public product without the separate productization process.
If evidence cannot leave a regulated environment, wait for an approved architecture such as EFS or use a model and workflow compatible with the required retention boundary. If the job is deterministic—asset inventory, ownership lookup, policy check—use CMDB, IAM, SQL or rules. If a scanner already provides a precise, reproducible result, use the model to prioritize or explain it rather than replacing the scanner.
Executive checklist
Choose the least privileged tier. Verify written authorization for every target. Assign a security contact and organization owner. Enforce phishing-resistant MFA and workload identity. Remove static keys. Create separate granted workspaces. Broker every session through tier, target and time policy. Run tools in disposable sandboxes. Enforce and log egress outside the host. Store minimal attributable evidence. Define review, disclosure, incident and revocation procedures. Test containment before increasing autonomy.
Anthropic's expanded program can make capable models more useful to defenders by reducing false blocks for verified work. The production advantage, however, comes from the surrounding system: identity that can be attributed, authority that can be proven, environments that can be contained, and actions that can be reviewed and revoked.
Official references
These references document the tools discussed. Examples and design decisions are illustrative and should be adapted to the project and its versions.
Prepared by: Noor Yasser
Working through a similar engineering challenge?
I help teams turn architecture decisions into a clear scope and dependable, reviewable implementation.




