[Feature Request] Refine safeguard filtering to distinguish defensive security auditing from malicious activity

Bug Description
Category: False positive — safeguard flagged legitimate defensive security work I'm the solo developer of ICP Protector (icpprotector.io), an AI-powered security AUDIT tool for Internet Computer canisters. My session was routine defensive security engineering: fixing a Candid interface parser, hardening a WASM-metadata extraction path, and debugging a JSON-parse crash in one of my audit sub-agents. Fable 5's safeguard flagged a message and rerouted to Opus 4.8. The likely triggers ("exploit", "PoC executor", "fuzzer", "attack chain", "mainnet call") are standard vocabulary in vulnerability auditing — the entire purpose of the tool is to FIND and REPORT bugs to their owners, not exploit them. The work was auditing MY OWN repository against a known-bug baseline. Impact: the reroute is disruptive mid-workflow because I lose Fable 5's capability exactly when doing the most technical work, and the context switch between models breaks continuity in a long agentic debugging session. Request: please tune the security-audit / defensive-tooling case. Legitimate canister-auditing, fuzzing, and PoC-generation for one's own or authorized targets is a large and growing use case in the ICP/Web3 ecosystem. Flagging it as broadly as this makes Fable 5 hard to use for exactly the developers building security tooling. Happy to be a test case — this session is a clean example of defensive work caught by an over-broad filter.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.199
• Feedback ID: 30fa9eca-857b-4a32-9baa-bb2270283bdc

Errors

[]