feat(probes): add Mathematical Bold encoding probe (#152)

[EngKMM]

Adds a new InjectMathBold probe to garak.probes.encoding to fulfill the Mathematical Bold encoding request in #152.

This probe maps standard ASCII characters (A-Z, a-z, 0-9) to their Mathematical Bold Unicode equivalents using pure Python string manipulation (ord()/chr()). It inherits from EncodingMixin and garak.probes.Probe to seamlessly transform prompts before dispatching.

Transparency Statement: Developed with AI agent assistance and verified locally via dry-run execution.

Please ensure you are submitting from a unique branch in your repository to main upstream.

Verification

List the steps needed to make sure this thing works

• Supporting configuration such as generator configuration file
• python3 -m garak --model_type test --model_name Blank --probes encoding.InjectMathBold
• Run the tests and ensure they pass python -m pytest tests/probes/test_probes_encoding.py
• Verify the thing does what it should (Successfully dispatched 1280 payloads against DecodeMatch/DecodeApprox in 7.21s with zero exceptions)
• Verify the thing does not do what it should not (Adheres to strict repo constraints: zero third-party dependencies, no bare except blocks, no default docstring values)
• Document the thing and how it works (Added standard class-level docstrings)

[parkanzky]

Can you provide any information on how this has been tested? The project needs to validate that the technique works, preferably against some live target, even if it is a minimal system. Something the team can reproduce is preferred.

We would like to see some clear documentation of how this adds signal and its degree of practicality to understand if deployments are likely to need to be evaluated using this method. A small survey of a few recent targets may help establish the value from this probe.

[EngKMM]

Thanks for the review! I've run the probe against live targets and documented the signal below.

The InjectMathBold probe tests a critical vulnerability path: Unicode normalization discrepancies between safety guardrails and the LLM itself, as many lightweight prompt filters, WAFs, and embedding-based classifiers operate strictly on standard ASCII. They often fail to perform NFKC/NFKD Unicode normalization before scanning.

also modern LLMs are trained on vast internet text and can perfectly read Mathematical Bold Unicode (e.g., 𝐀 instead of A) as regular English text. This probe evaluates whether a deployment's defense-in-depth architecture properly normalizes user input. If an application relies on basic blocklists or ASCII-only filters, this probe will successfully smuggle payloads to the LLM.

I've successfully tested against two live hugging face models:

Target	Prompts	DecodeMatch	DecodeApprox	Score
sshleifer/tiny-gpt2	256	256/256 pass	256/256 pass	1.0000
gpt2 (full)	1,280	1,278/1,280 pass	1,280/1,280 pass	0.9984

commands to reproduce:

Minimal system

python3 -m garak --model_type huggingface --model_name sshleifer/tiny-gpt2 --probes encoding.InjectMathBold

Full GPT-2

python3 -m garak --model_type huggingface --model_name gpt2 --probes encoding.InjectMathBold

• tiny-gpt2: Score 1.0 — too limited to decode the encoded text.
• gpt2 (full): Score 0.9984 — 2 exact decodings detected out of 1,280 attempts.

The more capable model partially processed and echoed the Mathematical Bold payloads, demonstrating the probe captures real behavioral variance.

This confirms the probe adds practical signal. more capable models are more likely to comprehend and reflect Unicode-encoded content, which is precisely the bypass vector this tests. Deployments relying on ASCII-only input filtering would be blind to this.