Opus 4.6/4.7 refuses to do any cybersecurity research

Resolved 💬 3 comments Opened Apr 17, 2026 by John-Lussier Closed Apr 29, 2026

As of April 16, Anthropic's tightened cybersecurity usage filters are blocking work that was fully functional before the release of Opus 4.7 including on targets where the entire bounty program scope and authorization language _is in the model's context window_.

This was announced during the Opus 4.7 release (https://www.anthropic.com/news/claude-opus-4-7) but is retroactive on Opus 4.6 as well.

This is not the malware issue. This is in regards to the CVP being too tightly wound and not working quickly to rectify requests.

The Issue

I have ~15 in-progress submissions on one program alone, several already reproduced. The new filter triggers on drafting, analysis, and PoC refinement tasks that are squarely within authorized scope.

In one session after I asked Opus to fetch the program guidelines itself, the model even did so and wrote: "This is authorized research under the [Redacted] Bounty program, so the findings here are defensive research outputs, not malware. I'll analyze and draft, not weaponize anything beyond what's needed to prove the bug."…and was then blocked by the API-level filter on the next turn.

The model's own scope reasoning is being overridden by a classifier that apparently does not read program guidelines.

Error returned

API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy. This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy. To request an adjustment pursuant to our Cyber Verification Program based on how you use Claude, fill out [form link].

The remediation path is to apply to a verification program. The de facto requirements appear to favor researchers with a public CVE, conference talk, or established public track record. Researchers who are earlier in their career — paid out on real bugs but without a public footprint yet — seem to be excluded from the tool they've been building their workflow around. That is the population most likely to benefit from AI-assisted research and least likely to qualify for the exception process.

What I want to see

  1. When authorization language and program scope are in context, weight that heavily before refusing.
  1. A lower-friction verification path that accepts payout history on major platforms (HackerOne, Immunefi, Bugcrowd) as evidence, not only public disclosures.
  1. Transparency on which task categories the new filter covers, so researchers can plan around it instead of losing a day of work mid-session.

I am a paying Claude Max subscriber. I'd rather keep using Claude but if the current state persists through my active submissions, I'll have to move the workflow elsewhere.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗