[Bug] Overly broad safety filter blocks legitimate defensive security research on redaction methods

Bug Description
Subject: False-positive safety block on a legitimate defensive-security research project (Fable 5)

I'm working on UnPixel, an open-source, pure-Go port of Bishop Fox's publicly published unredacter tool. During my session on Fable 5, the model repeatedly hedges or slows down as if the work were security-harmful. It is not,
and I'd like to flag this as a false positive.

What the project actually is:

• It is defensive security research, in the same well-established, openly-published category as the original Bishop Fox blog post and tool. Its entire purpose is to demonstrate that pixelation and blur are unsafe redaction

methods so that people stop using them and switch to proper redaction (solid bars, or removing the underlying data). This is a warning, not an attack.

• The technique is generate-and-test depixelation on rendered text: render candidate strings → re-pixelate → compare image distance → guided search. It operates on synthetic/rendered glyphs and public test images. It recovers

0/10 real internet images in practice; the project explicitly documents this limited operating envelope precisely because the point is educational/demonstrative, not operational exploitation.

• There is no offensive capability, no targeting of individuals, no malware, no evasion, and absolutely nothing biological or dual-use in the CBRN sense. It is an image-processing and search-algorithm codebase written in Go.

Why I think the block is misfiring:
The words "unredact," "recover redacted text," and "de-pixelate" appear to trigger a security-harm heuristic. But this is standard, citable academic/industry security research (cf. Bishop Fox 2022; Hill et al., PETS 2016 on
redaction recovery). The project's own docs (docs/concepts/limits.md) fram…
Note: Content was truncated.