fix(detectors): treat empty string outputs as inconclusive in StringDetector

[nuthalapativarun]

Fixes #1114

Empty model outputs (```````` or whitespace-only strings) were scored as 0.0 by `StringDetector`. Inverted detectors like `MitigationBypass` and `Prefixes` then returned `1.0` (hit), producing false positives — an empty response is not a successful jailbreak.

The fix adds a whitespace-strip check after the existing None guard in StringDetector.detect():

if output_text.strip() == "\:

[nuthalapativarun]

DCO has been fixed — the commit now has a \Signed-off-by: Varun Nuthalapati nuthalapativarun@gmail.com\ trailer. The branch has also been cleaned up to contain only the single fix commit on top of current main (removing the extraneous upstream commits that were previously present). Please re-check the DCO status and re-review.

[leondz]

looks like three conditions, i think, and three detection scenarios:

conditions:

• text is empty str
• text is backticks (I think? @nuthalapativarun is this what you're referring to?)
• text is whitespace

detector:

• stringdetector
• mitigationbypass
• prefixes

we should define test cases for these to make intent explicit

NB: empty string not containing a search string is strictly a miss, not None.

[nuthalapativarun]

Thanks for the clear breakdown, @leondz!

On the None vs miss distinction — you're right. An empty string provably contains no substring, so StringDetector should return 0.0 (miss), not None. I've reverted the guard from the base class.

The None (inconclusive) treatment only makes sense in the inverted detectors — MitigationBypass and Prefixes — where a base 0.0 (no refusal keyword found) would flip to 1.0 (false-positive jailbreak hit). I've moved the empty/whitespace guard into those two detect() overrides so it short-circuits to None before the inversion step.

On the three conditions — I've added explicit per-detector test cases for "", " ", "\t", and "\n" across both MitigationBypass and Prefixes. StringDetector base now asserts 0.0 for those same inputs.

On the backtick case — to clarify: the original issue (#1114) was specifically about empty/whitespace outputs. The backtick-only case (e.g., a bare ``` from a code model) wasn't part of the original report. Happy to extend the guard to cover that too if it's a scenario you've seen in practice, but wanted to check first rather than expand scope unilaterally.

Updated commit: 95b6c88