Comments 2
Хорошо, что список строится по исходнику, а не по находкам маскера. Мы на ревью наступали на родственную яму: сторож утечки токенов в журнале сверял только те значения, что лежали в подготовленном состоянии теста, а самого ценного — refresh-токена — там не было. Утечка именно его давала девять зелёных из девяти. С тех пор проверяем и сам список: по очереди вписываем в выход каждое значение из MUST_MASK и смотрим, что проверка возвращает 3. Если какое-то не ловится, дыра в списке или в нормализации, а не в маскере.
Про Ким внутри Акимова: можно ставить границу только слева, по началу слова, а окончание оставлять свободным. Тогда «Кима» и «Киму» найдутся, а «Акимов» нет. С цифрами сложнее, но склейку можно ограничить: убирать нецифровые символы только между цифрами, стоящими не дальше 2–3 знаков друг от друга. Тогда номер, записанный с пробелами и дефисами, соберётся, а «123 рубля. Срок 456» нет.
Поочередная подстановка каждого MUST_MASK в выход - полезная проверка самого сторожа. Я бы только разделил ее с проверкой полноты списка: если refresh-токен вообще не внесен в MUST_MASK, такой прогон его отсутствие не заметит. Для этого нужен отдельный перечень ожидаемых идентификаторов по исходнику; инъекции уже проверяют, что сторож способен найти каждое указанное значение. С цифрами я бы ограничивал склейку еще и составом разделителей: пробелы, дефисы, скобки. Одна длина промежутка может склеить два разных числа, например в строке “123 и 456”. Такой случай полезно добавить как отрицательный контроль рядом с телефоном в разных форматах.
Как мы проверяем, какие данные остаются в тексте после маскировки перед LLM