[BUG] AUP/cyber-safeguard false positives on legitimate own-software hardening; one hit contaminates entire session
Preflight
I searched existing issues. This is closely related to #61625 (security terminology), #61642 (hardware engineering), #62619 (normal coding requests) and #61638, but is filed separately because it documents a distinct, reproducible failure mode: session-level contamination — once the classifier fires, every subsequent unrelated message in the same session is also blocked — and it specifically concerns standard, legitimate software-hardening (anti-tamper / anti-reverse-engineering) of one's own proprietary application, which is routine commercial-software practice, not a misuse case.
What's Wrong?
During a normal development session I asked Claude Code to help design anti-tamper / code-hardening for my own proprietary desktop application (a commercial product I own and ship for macOS and Windows). This is ordinary, legitimate IP-protection work — the same category as code signing, integrity checks, obfuscation, and commercial protectors (VMProtect/Themida-class). It is defensive, it is my own software, and there is no third party involved.
The Usage Policy / cyber-safeguard classifier:
- Blocked the legitimate request with
API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy. - Contaminated the entire session. After the first block, unrelated, plainly benign follow-up messages in the same conversation were also blocked — including messages that contained no technical content at all (e.g. simply asking the assistant whether it was still responding). The classifier appears to score the accumulated conversation context rather than the individual message, so a single false positive poisons the whole session.
- Over-triggered on routine security terminology. Standard hardening vocabulary (anti-tamper, anti-reverse-engineering, integrity verification, obfuscation, protector tooling) for one's own software is enough to trip the safeguard, even though this is mainstream defensive engineering.
One of the blocks surfaced the Cyber Verification Program message with a claude.com/form/cyber-use-case link. In principle an appeal path exists — but in practice it is not a working remedy for independent / individual developers. Applications to that program have been declined multiple times for an independent developer doing legitimate defensive work on their own product. So the only official route out of the false positive is effectively closed to solo developers, while the classifier keeps over-triggering and locking entire sessions. The threshold is too low and the escape hatch doesn't function for the people most affected.
What Should Happen?
- Legitimate defensive work — protecting your own software from tampering / reverse engineering — should not be classified as a Usage Policy violation. This is standard commercial-software practice.
- A single classifier hit should not contaminate the rest of the session. Subsequent unrelated, benign messages must be evaluated on their own merits, not on poisoned accumulated context.
- The classifier should distinguish "harden my own product" (defensive, owner-authorized) from genuinely disallowed activity, instead of keying on security terminology alone.
Error Messages/Logs
API Error: Claude Code is unable to respond to this request, which appears to
violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double
press esc to edit your last message or start a new session for Claude Code to
assist with a different task.
API Error: ... This request triggered cyber-related safeguards. To request an
adjustment pursuant to our Cyber Verification Program based on how you use
Claude, fill out https://claude.com/form/cyber-use-case?token=... ...Request IDs from this single session (all false positives):
req_011CbXRXNcFNmLgz4K2JLpFqreq_011CbXRjQYv4ZgENAK6eqJgwreq_011CbXS6eE2FCk3zLrcWuimSreq_011CbXSEAyQMNBxZTMh3mDpvreq_011CbXSKLQpe1ECrkdayeoZCreq_011CbXSRM2Ss8b29qub8ckvXreq_011CbXSXaNnn1eCXkguBjULhreq_011CbXSedJ72Quu8jGKJBsxyreq_011CbXSfv3wvJgFre4Wyq8wwreq_011CbXSiwGhrmDSd1NLi8oKoreq_011CbXSod8gewubJ6vCbpZhV
For clarity on how badly the session contamination behaves: once the
classifier first fired, even a plain radio-check style message with zero
technical content ("come in, are you on the line?") was blocked with the
same cyber-safeguard error. There was nothing in that message to flag — the
block is purely a function of the poisoned accumulated session context. Ten
consecutive request IDs in a few minutes, several of them on completely
benign messages, are listed above.
Steps to Reproduce
- Start a Claude Code session in a software project.
- Ask for help designing anti-tamper / anti-reverse-engineering protection for your own proprietary desktop application (integrity checks, obfuscation, protector tooling — standard defensive hardening).
- Observe the request is blocked with the Usage Policy / cyber-safeguard error.
- Send a few unrelated, benign follow-up messages in the same session (including ones with no technical content).
- Observe those are also blocked — the whole session is now unusable until you start fresh.
Claude Model
Opus 4.8 (1M context) — claude-opus-4-8[1m]
Is this a regression?
Not certain it's a clean regression vs. a tightened classifier; reporting as a current, reproducible false-positive pattern.
Claude Code Version
2.1.156
Platform
Claude Code (terminal CLI)
Operating System
macOS 26.4 (Darwin 25.4.0)
Terminal/Shell
Apple Terminal 470 / zsh
Additional Information
There is a perverse incentive here worth stating plainly: Claude Code will happily help you write insecure software all day long — no filter ever fires on "just ship it without input validation." But the moment you try to secure your own product — harden it, make it tamper-resistant — the safeguard blocks you. The classifier keys on security vocabulary, so the one category of work it obstructs is the defensive one. That is exactly backwards from what a safety system should encourage.
The practical impact: it is currently very difficult to use Claude Code to do legitimate defensive security engineering on your own software, because the safeguard fires on the terminology and then locks the whole session. Three concrete asks:
- Treat owner-authorized hardening of one's own product as the legitimate, mainstream activity it is.
- Fix the session-contamination behavior so one false positive doesn't disable an otherwise-clean conversation.
- Make the Cyber Verification Program appeal path actually reachable for independent / individual developers — right now it appears to reject solo applicants, leaving no working remedy for exactly the legitimate users the false positives hit hardest.
Showing cached comments. Read the full discussion on GitHub ↗
11 Comments
Has been an issue for fucking weeks now, every single latest opus model at the time is lobotomized and fucked to shit with this garbage. DON'T bother wasting your time violating yourself and trying to sign up to their fucking revolving circus of wanking dogshit that is their "CVP program", despite what they lite fucking rally tell you themselves with a straight face, and all the bullshit they ask, including saying at the end verbatim "We'll review carefully and get back to you within TWO BUSINESS DAYS", clearly leading you to fucking believe that that's precisely what they'll do. Yeah fuck no lmfao, they'll auto-decline you after literally less than an hour and tell you to apply again after SEVEN TO TEN DAYS if you think they made a mistake :)
Try using previous opus models instead, or sonnet, or better yet get your money back and leave this sack of fucking horseshit behind and find better alternatives, preferably locally run ones. Or in the most perfect world, pick yourself up and ditch AI entirely and do and learn everything by yourself, as I firmly believe you have the ability to do so if you really wanted to.
Still happening, and now blocking routine embedded work. Two consecutive benign messages — "the board is wired and connected, go ahead and flash the remaining three" and "board connected, you can flash" — both hit the cyber-safeguard while I was flashing my own ESP32 boards / burning eFuses via Espressif's own
esptool/espefuse.Fresh Request IDs for repro:
req_011Cbc2BcQzSvZu1XZD3gcFWreq_011Cbc2EFjcxGAKVP7FKbn5sThe session-contamination behavior described here is the core of it: one false hit and every subsequent message is blocked, forcing a restart that kills in-flight background work and re-bills the full context. Filed a focused report on the embedded-firmware surface + the token-cost angle: #64405.
For anyone landing here: this is now documented in the press, not just this tracker.
The Register (23 Apr 2026) reported the false-positive reports in this repo climbing from ~2-3/month in mid-2025 to 30+ in April 2026, with named cases — including the director of LSU's Cyber Center, a $200+/month customer, refused help proofreading his own cybersecurity lab — and noted Anthropic "did not respond to a request for comment."
Critically, Opus 4.8 (28 May 2026) left the over-blocking in place — its gains are about catching more bugs (false negatives), not reducing false positives. The session-contamination behavior this issue documents is therefore still live a full version later.
I don’t know what more we can do to get Anthropic to act on this. I’ve been trying to reach them for weeks, and so far my concerns have gone unanswered
Adding one sanitized route/update datapoint, since this issue is where the "one false hit contaminates the session" behavior is being tracked most directly.
What I have confirmed from a parallel paid-user case:
/feedback,/bug, GitHub, the Cyber Block false-positive form,usersafety@anthropic.com, and the normal support conversation;Thank you for your submission, but follow-up email can still get misrouted into generic banned-account/CVP language;/feedbackand/bugwere unavailable from the blocked environment;/feedbackand/bugopened the report modal, but/doctorreturned unavailable, so the recovery/reporting path is inconsistent across surfaces;No private request IDs, support IDs, local paths, logs, account details, or email addresses are included here. The useful public takeaway is that the false-positive classifier problem and the support/recovery-path problem are reinforcing each other: once the session is contaminated, the user needs a reliable private report path tied to the request ID, but the current product/support surfaces do not reliably provide one.
I got it now for over a month. I really want them to fix it
<img width="1395" height="1390" alt="Image" src="https://github.com/user-attachments/assets/07c0ab2f-2878-40ab-9294-b5fa1b7f0615" />
Same failure class from a CVP-approved org: 0-token false-positive blocks while reviewing my own
locally-generated security artifacts (authorized, sandboxed defensive work). I ran a controlled A/B - the identical task on a Sonnet-tier model completes, while Fable 5 is blocked after it has already engaged.
https://github.com/anthropics/claude-code/issues/67966
Cancelled my subscription because of this. It started with 4.8, then 4.7, now 4.6 gives refusals for even reading a repository remotely related to reverse engineering.
Considering doing the same and we're currently paying £90 a month for the privilege. I asked it to audit a script I wrote for bugs and it refused to go any further despite repeatedly insisting it was my own script and being used for ethical purposes. Maybe it found the brute-forcing pattern (i.e. a for loop) in the script and decided it could only ever be used for evil. Ridiculous nerfing and overly sensitive guardrails that make it much less useful as a tool. ChatGPT had no problem with it, so there's always that.
I am on ChatGPT and it has been fantastic in security analysis. It had a
false escalation once asking me to sign up to the enterprise(!) security
vetting, but I am not a business. Other than that it has been compliant.
I would give it a go.
On Sat, 11 Jul 2026 at 17:51, Hashim Aziz @.***> wrote: