From the Anthropic edition of November 2, 2026
Analysis: Claude reverse-engineering blocks come from an external cyber classifier with no off switch; Anthropic's own benchmark shows Defense Access still blocked 46 of 50 scenarios
Capital and Compute (independent analysis of Anthropic controls) · AI model provider; security practitioners · Global
- Publisher
- Capital and Compute
- Original publication
- October 25, 2026 (updated November 3, 2026 UTC)
- Source retrieved
- 2026-11-03
What happened
This independent analysis argues reverse-engineering blocks come from Anthropic's cyber safety classifier, a separate system that ends the turn, not from a weaker model. It cites Anthropic's Oct. 6 statement that generally available models have conservative safeguards that block most cyber work. It reproduces Anthropic's CyScenarioBench table: without verification every trial was blocked on the first prompt, Defense Access was blocked in 46 of 50 trials at some point, and Red Team Access completed 34 of 50. It says there is no setting to switch the classifier off. The route is the Cyber Verification Program, and Anthropic aims to respond within seven business days.
Why it matters
Cross-tagged to state-government for state and local SOCs and campus security teams. It explains why rewording does not help and quantifies, from vendor data, how much verified defensive access still gets blocked on offensive-style scenarios. Why now: updated the evening of Nov. 2 CT as refusal reports spread, and it was not previously archived.
Evidence and measured results
Vendor benchmark figures (50 trials per tier) reproduced from Anthropic; user reports; no independent test.
Limitations and uncertainty
Independent blog; benchmark is offensive and vendor-run; refusal threshold changes unconfirmed.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-03; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Security teams need to know which defensive tasks Claude will perform and how to get access for the rest.
- Stakeholders
- CISO
- SOC lead
- Security research faculty
- Discovery questions
- Which tasks fall outside the default allowed list?
- Who is the organization admin for verification?
- Is a paid plan in place for Defense Access?
- Value hypothesis
- Interpretation: aligning workflows to allowed tasks and verification tiers reduces wasted analyst time.
- Potential engagement
- A task-mapping session and verification application support.
- Unsupported claims
- That verification guarantees completion
- That any setting disables the classifier
- Independent benchmark results
Pre-sales engineering
Role takeaway
- Fit
- Fits security teams using Claude for code review and triage; weak fit for unverified malware analysis.
- Architecture and integration
- Classifier sits outside the model and reads prompts, files, connectors and MCP tool outputs.
- Prerequisites
- Organization-level verification
- Paid plan for individual Defense Access
- Task inventory
- Constraints
- No off switch
- Defense tier still frequently blocked on offensive scenarios
- Threshold changes undisclosed
- Security
- Classifier inspection of all context; disguising tasks violates usage policy.
- Proof of value
- Test real defensive tasks per tier
- Track blocks per task type
- Confirm verification response time
Delivery
Role takeaway
- Work
- Plan verification tier, map tasks, and document fallbacks.
- Dependencies
- Organization admin
- Anthropic verification portal
- SOC
- Ownership
- CISO with the AI platform admin
- Skills and adoption
- Analysts learn allowed tasks and the appeal route.
- Governance checkpoints
- Tier decision recorded
- Retest after vendor changes
- Acceptance criteria
- Proposal: task map covering all SOC Claude uses
- Proposal: verification decision within one review cycle
- Risks
- Over-reliance on blocked capabilities
- Policy violations from rewording attempts
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Classifier reads all conversation content, including tool results from MCP servers, so local analysis tools still feed the gate.
Governance
Who approves, reviews and stays accountable for outcomes?
Verification tiers become a governance decision with organization-level applications and seat assignment.
Security and privacy
What data, permissions and controls need testing?
Classifier reads tool outputs as well as prompts; disguising tasks is a usage-policy violation.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Security staff need training on which tasks are allowed by default.
Procurement
What should contracts, pricing and exit terms secure?
Budget time for verification review and paid-plan requirements.
Operating model
Which teams own the service once it runs?
Organization admins, not individuals, should apply and assign seats.
Publication history
- 2026-11-02Anthropic · Issue 056 resources
Stable resource ID: capitalandcompute-claude-cyber-classifier-reverse-engineering-explainer-20261102