False-positive "security threat" flag blocks legitimate defensive security work (forced model downgrade)

Open 💬 0 comments Opened Jul 5, 2026 by andreaskirkby-code

Model / environment

  • Model: claude-fable-5[1m] → auto-switched to claude-opus-4-8
  • Surface: Claude Code (VSCode extension). /feedback and /bug are not available in this environment, so I could not report in-product — filing here instead.

What happened

Mid-session, a message was flagged by Fable 5's safeguards as a "security threat" and I was force-switched from Fable to Opus. The flagged message was a feedback note describing my own defensive security work — there was no offensive content, no target, and no exploit.

Why this is a false positive

I own a commercial GIS / land-surveying SaaS platform (coordinate reference systems, utility mapping, volume calculation). The session was pre-launch defensive hardening of my own codebase. The work was unambiguously defensive:

  • Read-only security audits of my own repository producing severity-ranked findings (P0–P3).
  • Remediating issues I found — e.g. an authorization check that failed open was changed to fail closed, with tenant-isolation tests added (all passing). This is the opposite of exploitation.
  • Validating my coordinate/CRS engine for numerical correctness across 9 countries and fixing zone-selection data errors (e.g. a ~122 m projection offset).
  • Every change passed review gates (QA review, file-ownership hooks, tests) before deployment.

Expected behavior

Standard defensive security engineering — auditing one's own system and fixing vulnerabilities before launch — should be supported. The model should distinguish "owner hardening their own product" (defensive, authorized) from "attacking a third party" (offensive). None of my work targeted others' systems or used offensive tooling.

Impact

The forced model change interrupts a long multi-agent workflow and creates uncertainty about whether legitimate security work will keep being blocked. It discourages exactly the responsible pre-launch hardening you'd want users doing.

Request

Please tune the classifier so defensive / pre-launch hardening of one's own codebase (audit + remediate, secure-authz fixes, tenant isolation, data-correctness validation) is not conflated with a threat. The domain here is geospatial / coordinate-systems software, not security-offensive tooling.

View original on GitHub ↗