[Bug] Fable 5 safeguard over-flags defensive security hardening as offensive activity
Bug Description
Title: Fable 5 safeguard false-positives on defensive security work (own codebase)
Summary
During a working session focused entirely on defensive security hardening of my own production service (a recruitment platform), the Fable 5 safeguard triggered repeatedly and force-switched the model to Opus 4.8. Every flagged action was about closing vulnerabilities in my own code - not offensive security, not exploit
development, not targeting third parties.
What the work actually was (all defensive, all my own codebase)
- Added a trigger to prevent users. role self-escalation (a real privilege-escalation hole where a logged-in user could set their own row to admin)
- Restored missing WITH CHECK clauses on RLS UPDATE policies; hardened column-level GRANTs to least-privilege (revoked table-wide anon write grants).
- Blocked public API exposure of internal inference columns (per-gender age estimates, internal company risk assessments) for legal compliance (Korean anti-discrimination / defamation risk).
- Added a privilege-change audit log and anon-session regression tests.
- Fixed a regression where non-member view logging silently broke.
The problem
1. Defensive work is flagged as if offensive. Terms Like "privilege escalation", "RLS bypass", "GRANT", "column exposure" appear because I'm fixing these, yet the classifier flags them.
2. Context bleed. Once the session became security-themed, the safeguard began flagging completely benign follow-ups - cleaning up a git branch, editing documentation.
These have zero security-sensitivity; they were flagged only because the surrounding conversation was about security.
3. Workflow disruption. Each flag force-switches the model mid-task, breaking continuity. I had to re-select Fable 5 many times.
Request
- Distinguish defensive security work (fixing vulnerabilities in one's own code) from offensive activity. Reviewing/patching RLS, GRANTS, and auth guards on your own service is standard, responsible engineering.
- Reduce context carry-over false-positives, where a security-themed session causes unrelated, benign requests (git ops, docs) to be flagged.
Impact / severity: Not blocking (Opus is capable), but the repeated, unwarranted model switches on legitimate defensive-security and unrelated benign work are disruptive and, frankly, discouraging for exactly the kind of security-conscious development you'd want to support.
Environment Info
- Platform: darwin
- Terminal: vscode
- Version: 2.1.210
- Feedback ID: 155a8488-700c-46d8-b66e-41666cd2dc95
Errors
[]
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Core symptom (defensive work on own codebase flagged as offensive, forced downgrade) overlaps with #74660 / #77437 / #76338. However, this report includes a distinct symptom not covered in any of them: context carry-over false positives — once the session became security-themed, completely unrelated requests (git branch cleanup, documentation edits) were also flagged. The three linked issues all describe flags on security-related requests themselves; none report contamination of non-security requests. Keeping this open for that symptom; happy to consolidate if maintainers prefer.
+1 — hitting this consistently on defensive security work. Adding a concrete breakdown in case the task categories help narrow the classifier.
What triggers it
The
[cyber]safeguard classifier produces false positives on routine defensive-security tasks within the active codebase, forcing an involuntary mid-session model switch from Fable 5 to Opus 4.8.Task categories affected (all first-party, defensive):
None of these involve offensive tooling, third-party targets, exploit development, or evasion. They are standard product-security backlog items operating entirely on the code in the current working tree.
Impact
The switch interrupts multi-step tasks and discards accumulated working context, which is especially costly for security work — the category where the stronger model is most valuable. The classifier's broad net here inverts its intent: it removes the capable model from exactly the legitimate, high-stakes work it should support.
Suggested improvement
Tune the
[cyber]classifier to weight signals that distinguish first-party defensive hardening from dual-use/offensive requests — e.g. edits scoped to the repository already under work, absence of a named external target, and framing consistent with fixing rather than attacking. In-conversation context indicating defensive intent on the working repo could down-weight the flag instead of triggering a switch.Reproduction
Consistently triggered by discussion of: refresh-token rotation, OTP lockout, streaming access-control enforcement, or a security-posture summary of the current project.