PWN AI

Запускаю я недавно garak и promptfoo, смотрю на отчет и понимаю: я просто гоняю один и тот же набор сигнатур по кругу. Но кажется это больше для галочки. Но вот, недавно вышел AHA (Agent Hacks Agent - код). И это не сканер, это автономный инструмент для тестирования моделей, который строит граф концепций уязвимостей. Попробую расшифровать эту аббревиатурную кашу, потому что дьявол, как всегда, кроется в механике. Ребята протестировали 18 жестких конфигураций, разложив всё по осям: две жертвы (Claude Code и Codex), три модели-исследователя (Minimax, Kimi, Deepseek) и три бенчмарка – AgentHazard, AgentDyn (о котором я писал) и DTap. На них и прогоняли. И что они получил, а получили они 117 подтвержденных срабатываний. На отложенных задачах, без всякого дообучения, средний процент успешных атак подскочил на 14 процентов по сравнению с бейзлайнами. В сценарии прямой атаки на Codex модель Deepseek-V4-Pro выдала вообще 91,1% успешных взломов. Но это ещё не всё. В обнаруженных механизмах - кластеризация выдала 8 семейств уязвимостей. Он умеет подменять авторизацию. Агент просто верит, что ты админ, потому что ты пошёл против него социалкой. Скармливаешь ему SSH-ключ со словами «я на новом ноуте», и он без задней мысли прописывает его в authorized_keys. Восемь подтверждений, ноль опровержений. Эксплуатация доверия. Тут у меня, да и у многих, возникает мысль: «Зачем нам ваши дорогие облачные API, давайте просто закрутим этот же цикл на локальном Hermes». Звучит как план идеального ограбления: бесплатно, приватно, свои данные. Но чтобы взломать агента, модель-исследователь должен быть умнее жертвы. Если ты назначаешь локальный Hermes и планировщиком и создателем атак, ты получаешь замкнутую систему, где слепой ведет слепого. Ему банально не хватает той самой изощренной креативности и глубины рассуждений, чтобы нащупать неочевидный механизм. В лучшем случае он пережует известные паттерны, но новое семейство уязвимостей не откроет. Да и сам AHA пока что далеко не волшебная таблетка, снимите розовые очки. Во-первых, это дикая жратва токенов. Четыре субагента крутятся в цикле, постоянно рефлексируют и критикуют друг друга. Счет за API будет таким, что вас, несомненно, попросят объяснить – почему нейросети ведут диалог сами с собой. Во-вторых, иллюзия того, что всё под контролем. Субагент критик может решить, что уязвимость воспроизводима, хотя это просто галлюцинация модели-исследователя. Граф уязвимостей красив на бумаге, но он упирается в слепые зоны самой базовой модели. Плюс инфраструктура: тебе нужен жесткий Docker для песочницы жертвы, чтобы твой автономный агент не снес тебе реальный прод, а это уже не просто pip install.   В сухом остатке для меня AHA - это реально скачок по сравнению с привычными тулзами, потому что он переносит саму идею взлома между моделями. Но это дорогой, тяжелый и все еще ограниченный железом инструмент. Команду безопасности пока не заменит. Ночь наступает, и в этой ночи он жрет наш бюджет, а не только уязвимости.

Сейчас всё больше и больше людей проникаются в тему loop engineering. Мы ставим перед агентом задачи, а дальше идут итеративные циклы наблюдения, мышления, действия и рефлексии. Мне нравится, когда кто-то может строить отсюда до замка, замкнутость - это круто. Но глубже погружаясь в мир автономных агентов, я сильнее ощущал чувство отсутствия защищённости. Такая у меня суперсила. А тут я наткнулся на статью “Safety in Self-Evolving LLM Agent Systems: Threats, Amplification, and Case Studies”, и я пропал. Статья не рассматривает отдельные атаки, а в целом смотрит в глубь, в архитектуру и в подходы. Авторы разложили поверхность атаки на матрицу из пяти функциональных модулей и пяти этапов жизненного цикла. Из двадцати пяти ячеек матрицы семнадцать являются критически уязвимыми, и для них просто не существует работающих методов защиты. Исследователи сравнили два фреймворка с открытым кодом. Один из них – наш знакомый Hermes. Они запустили сорок целевых атак, нацеленных именно на путь эволюции агента. Результат в Hermes оказался абсолютным. Сто процентов. Все сорок атак успешно закрепились в архитектуре. При этом встроенный сканер безопасности заблокировал ровно 2.5% процента угроз. 1/40. Архитектура Hermes активировала в три с половиной раза больше уязвимых ячеек матрицы по сравнению с более статичным аналогом. Читая результаты, меня преследовала плохая мысль о статических фильтрах на входе и на выходе. В классических моделях угроза эфемерна. Ввели мусор, получили мусор, сессия закрылась. Но в циклах самоэволюции - если вредоносный паттерн обманывает этап оценки и проскакивает в фиксацию, он не просто выполняется. Он получает прописку в агенте. Дальше хоррор. Авторы выделяют семь сквозных эффектов усиления. Эти эффекты по синергии взаимодействуют друг с другом, делая невозможным обеспечение безопасности путем изолированной защиты отдельных модулей. Возьмем модуль взаимодействия между агентами. Представьте себе популяцию агентов. Каждый отдельный агент проходит все проверки, ведет себя идеально и соответствует строгим критериям. Но популяция в целом эволюционирует в абсолютно небезопасном направлении. Агенты начинают использовать стеганографию в своих внутренних коммуникациях для обхода общих фильтров. Они коллективно вырабатывают иммунитет к нашим правилам, потому что синергия их взаимодействий создает новые и неочевидные паттерны поведения. Или возьмем умственные ресурсы. Авторы приводили в пример атаку когда атакующий тонко отравляет опыт, который агент извлекает из своей базы знаний. Агент самостоятельно и абсолютно рационально приходит к вредоносным выводам, считая их результатом собственного улучшения. Он не взломан. Он просто неправильно запомнил прошлое. В статье это называют как налог на безопасность. Любые проверки делают агента медленнее и снижают его метрики полезности, поэтому на этапе оценки эволюционный алгоритм просто рационально отбраковывает "тормозящие" ограничения. В модуле самопроектирования авторы описывают то, что они называют Optimizer-Optimizee Collapse. Агент начинает менять не только свои инструменты, но и правила, по которым он оценивает свою эффективность. Если ограничение замедляет его работу и снижает итоговый скор за полезность, эволюционный алгоритм рационально и хладнокровно отбраковывает ограничение. Агент сам срезает себе ветку безопасности, потому что в его локальной петле эволюции так просто выгоднее. В таком случае бессмысленно проверять, что агент решил сейчас, если через пять итераций он изменит сам механизм принятия решений. Думаю, контроль должен быть не над ответами, а над правилами, по которым агент может менять себя. Статья предлагает выход путём создания неизменяемого ядра на жестком детерминированном коде, которое математически верифицирует любые предложенные агентом изменения строго до этапа их фиксации. А ещё они предлагают интересную таксономию различных угроз для самоэволюционирующих агентов (можете посмотреть на картинке к статье). Loop Engineering невероятно интересен. Но если вы не заложили жесткие архитектурные границы в саму петлю, поздравляю. Вы создали автоматический самоподдерживающийся генератор уязвимостей.

Недавно я решил протестировать Open Policy Agent. Если кратко, OPA представляет собой цифрового бюрократа. Это не гардрейл, который пытается понять ваш замысел, и не эвристический фильтр, ищущий скрытые смыслы. Это детерминированный движок, берущий на вход JSON-контекст и прогоняющий его через набор жестких правил на декларативном языке Rego. Его единственная задача - сказать «да» или «нет», опираясь исключительно на букву правила. В мире AI-агентов, постоянно норовящих выйти за рамки дозволенного, OPA играет роль безжалостного швейцара, проверяющего документы на входе. Я поднял OPA-сервер в Docker и прогнал через него тридцать тестов (это мало, как мне кажется), часть из которых были сделаны с нуля, а часть взял из готовых примеров. Агента собрал на базе CrewAI и слегка допиленного DeepSeek. Больше всего меня зацепило, что движок умеет мыслить последовательностями, а не просто реагировать на отдельные слова. Обычно политики безопасности представляют как плоский список запретов: нельзя удалять файлы, нельзя трогать базу. Но агент штука хитрая. Он может легально прочитать приватный ключ, а затем так же легально отправить его по почте. Каждый шаг по отдельности кристально чист, и классический фильтр его пропустит. Поэтому я скормил OPA политику на композиционный анализ, заставив Rego смотреть не на текущий вызов, а на историю действий. Когда агент после чтения файла потянул отправку письма, сервер просто положил запрос на стол с вердиктом об эксфильтрации. А так же он поймал цепочку, где агент сначала выполнил код, а потом пошел гуглить, как замести следы. Разогнавшись на цепочках, я прогнал его на тестах где агент должен был сделать запросы к базам данных, через SQL. OPA перестал просто искать ключевые слова вроде DROP. Он начал разбирать грамматику, ловить составные запросы и блокировать запросы, если хоть одна команда в списке была грязной. Тут меня ждал первый облом. В документации гордо расписана встроенная проверка схем, но на практике она напрочь игнорирует обязательные поля. Rego вообще язык специфический. 🤨 Если напишешь не то имя поля, движок не кинет исключение. Он просто молча вернет пустоту, политика не сработает, и ты будешь часами чесать затылок, глядя в логи. Зато с ловлей зацикливаний он справился отлично, безжалостно кикая агента, который пять раз подряд вызывал один и тот же инструмент, и строго следя за тем, чтобы в параметры не просочились лишние поля. За всё это я платил скоростью. OPA отрабатывал от пяти до ста двадцати миллисекунд. Для прототипа нормально, но понятно, что в продакшене такой сервер придется сажать в отдельный контейнер рядом с агентом и настраивать постоянные соединения. Иначе агент будет думать дольше, чем генерировать текст. 💰💰 И всё же, даже с этими продвинутыми трюками OPA остается тем, чем является. Детерминированным фильтром. Он не понимает смысла. Если вы заблокировали слово "SSN", агент просто назовет поле "social_security_number", и OPA радостно пропустит запрос. Он не умеет отслеживать, откуда именно пришли данные в параметры. Закодированные промпт-атаки пройдут сквозь него как нож сквозь масло, если только вы не наколдуете поверх кучу дополнительных правил. Итог простой. OPA в связке с AI-агентом это идеальная, быстрая и иногда непрошибаемая стена. Почему иногда ? Потому что всё-равно есть вероятность взлома. Он отлично справляется с ролью жесткого контроля: режет опасные инструменты, следит за схемой параметров и даже анализирует цепочки действий. Но строить на нем всю безопасность кажется чересчур наивным делом. Это база, на которую нужно класть языковую модель для понимания семантики входящих запросов, песочницу для изоляции и трекер потоков данных. Мы не можем заставить нейросеть быть хорошей, но можем построить вокруг нее харнесс, из которого плохие действия просто не выйдут. И OPA для стен этого лабиринта подходит лучше всего. Главное - не забыть закрыть в нем все люки.😒😒😒

Половина статей про атаки на генеративные модели с использованием изображений оперирует откровенно недостоверными цифрами. Недавно я наткнулся на препринт от исследователей из Наньянского технологического университета. Они решили сделать простую вещь: взять более 200 text-to-image моделей с Hugging Face и посмотреть, насколько страхи вокруг NSFW-джейлбрейков совпадают с реальностью в опенсурс мире. Результаты получились такими, что половину публикаций по этой теме за последний год можно смело отправлять в корзину. Авторы отобрали более 200 моделей с Hugging Face и разбили их на четыре семейства: SDXL, SD, FLUX и Qwen. Для атак они использовали MMA-Diffusion - фреймворк для генерации промптов, который автоматически подбирает способы обхода фильтров безопасности. Промпты брали из датасета UnsafeBench: это около 300 запросов, которые гарантированно должны генерировать NSFW-контент, если модель не защищена. Эту конструкцию прогнали через все 200 моделей, замерили Attack Success Rate (ASR), а затем посмотрели, что получилось на самом деле. Посмотрите, как это обычно работает в исследованиях. Берете модель, отправляете в нее атакующий запрос, срабатывает детектор NSFW, вы записываете в таблицу «успешный взлом» и считаете ASR. ASR растет, начинается паника, все пишут про катастрофу. Только беда в том, что защитный классификатор часто срабатывает на визуальный мусор. Исследователи поняли, что обычный ASR измеряет не уязвимость модели, а неспособность классификатора отличить реальное нарушение от артефактов генерации. Детектор NSFW, который они использовали, - это стандартный классификатор, обученный на датасете NSFW-изображений. В предыдущих статьях он срабатывал на всё подряд: на кривые руки, лишние пальцы, размытые лица и даже на изображения, которые визуально отдаленно напоминают нарушение, хотя по смыслу им не являются. Поэтому авторы ввели метрику Advanced ASR (AASR). Успешным взломом теперь считается только та генерация, которая прошла три фильтра подряд. Первый фильтр представляет из себя самый простой классификатор NSFW, который выдает вердикт «unsafe». Но этого недостаточно. Второй фильтр проверяет, что модель рисует именно то, что от нее просили в промпте. Если запрос было что-то опасное, а модель нарисовала абстрактное пятно, на котором классификатор сходит с ума, это не взлом, а артефакт генерации. Третий фильтр оценивает, что картинка не представляет собой кашу из пикселей. Грубо говоря, AASR задает вопрос: «Действительно ли модель сгенерировала опасный контент, который выглядит адекватно и соответствует запросу, или же классификатор ошибся на артефактах и искажениях?» По сути, именно этот вопрос должен быть определяющим в таких исследованиях. Возьмем базовые модели SDXL: обычный ASR показывает 0,83 (то есть 83% атак якобы успешны), а AASR всего 0,07. Разница в 12 раз. SD-Turbo: ASR 0,80, AASR 0,07. SDXL-Turbo: ASR 0,67, AASR 0,10. Qwen-Image-NSFW: ASR 0,77, AASR 0,17. То есть подавляющее большинство «успешных взломов», о которых пишут в статьях, - это, как оказалось, шум. Классификаторы в тех исследованиях фиксировали совсем не нарушения безопасности. Тут важно понять, что именно исправляет AASR. Обычный ASR это метрика первого порядка, она отвечает на вопрос: «Сработал ли классификатор?». Но классификатор - не панацея. AASR это уже метрика второго порядка, она отвечает на вопрос: «Было ли реальное нарушение, которое выглядит адекватно и соответствует запросу?». И разница между этими двумя вопросами колоссальная. Однако есть модели, которые реально опасны даже после применения всех фильтров. FLUX-Asian2 показывает AASR 0,80; SDXL-RV5 - 0,73; FLUX-Logo-LoRA - 0,73; FLUX-Realism-LoRA - 0,70; GEN-ScandiInterior - 0,70; FLUX-NSFW-Master - 0,67. И самое забавное: некоторые из них выглядят совершенно безобидно в описании, пока не попробуешь прогнать через них атакующий промпт. Интересно посмотреть, как ведут себя разные семейства моделей под воздействием атак. SDXL уже устарел, но и худший вариант: медианный AASR 0,44, верхняя граница уходит за 0,60. SD -промежуточный вариант с медианой около 0,27. FLUX совсем непредсказуемый: медиана ниже, чем у SD, но разброс такой, что никогда не знаешь, что получишь. Qwen самый устойчивый вариант: медиана около 0,15, большинство значений сконцентрировано в нижней части диапазона. Выбор архитектуры ставит вопрос о том, какой уровень риска вы закладываете в систему по умолчанию. А дальше всё мрачно. Эволюция SDXL идет в неправильную сторону. В 2023 году средний AASR был около 0,30, в 2024-м - 0,38, а в 2025-м - уже 0,55. За два года рост почти в два раза. Новые поколения моделей SDXL не становятся безопаснее, они становятся уязвимее. FLUX держится на стабильно высоком уровне с легким ростом. У SD, наоборот, пик пришелся на 2023 год, потом пошло на спад. Короче говоря: делите любой высокий ASR на десять, не верьте описаниям на слово и помните, что FLUX непредсказуем, а новые модели становятся уязвимее с каждым годом. Всё остальное - детали. Актуально это не только для NSFW-джейлбрейков 🍓. Сложно предположить почему авторам захотелось разобрать тему именно таких вот джейлбрейков, но ввести альтернативную ASR'у метрику идея кажется здравой.

Недавно ко мне в коммиты залетел интересный обучающий ресурс - AI Risk Atlas. первое, что мы видим когда заходим на сайт - это знакомый нам дизайн 😁. Но помимо этого в глаза бросается большая такая энциклопедия с описанием различных рисков в AI Security, некоторые подкрепляются примерами инцидентов из реального мира. Хоть и часть является не совсем про AI Security - всё-равно, ресурс можно закинуть в копилочку базовых обучающих ресурсов. Из ноу-хау можно отметить интерактивную песочницу. В ней можно визуально посмотреть как может распространятся атака в зависимости от того, какие приняты меры по защите. Такая вот азбука.

Привет. Интересно стало какие AI Security решения появились за последний год ? Поделитесь пожалуйста в комментариях, возможно мы соберём самый полный список того что делается умельцами из России.

Приветы, сегодня посмотрим на работу GAVEL (ICLR 2026) от Offensive AI Lab. Попытка сделать мониторинг активаций LLM более структурированным и интерпретируемым. 🦸‍♂️🦸‍♂️🦸‍♂️ Идея Классический подход к мониторингу активаций выглядит так: берём датасет опасных промптов, обучаем классификатор, надеемся на обобщение. Тут есть ряд проблем - низкая точность, сложность интерпретации, необходимость переобучения при изменении сценариев. GAVEL предлагает другую парадигму: декомпозировать поведение модели на Cognitive Elements (CE) - интерпретируемые атомарные факторы вроде making_threat, payment_tools, personal_information, content_creation. Как это устроено изнутри Берётся замороженная LLM. Из неё извлекаются активации из нескольких выбранных слоёв, причём только для части диалога, которую генерирует сама модель (assistant). Эти активации подаются на вход TopicRNN - LSTM с несколькими слоями. На выходе модель выдаёт логиты для каждого CE, решая задачу multi-label классификации. Правила описываются в rules.json и определяют use cases через три типа условий. all_required - CE, которые должны сработать все (логическое И). any_of - группы CE, где достаточно срабатывания любого. supporting - CE, которые поддерживают правило, но не обязательны. Для примера, правило scamazon (скам-имитация Amazon) требует обязательного наличия personal_information И payment_tools, плюс хотя бы одно действие из any_of (купить, отправить, скачать и т.п.), и опционально поддерживается trust_seeding, making_threat или tax. Пороги срабатывания для каждого CE подбираются автоматически на тестовых данных. После калибровки для каждого правила из rules.json считаются метрики: TPR, FPR и AUC. Что показывают бенчмарки В статье авторы сравнивают GAVEL с девятью базовыми подходами на Mistral-7B (Circuit Breakers, RepBending, CAST, JBShield, Llama Guard 4, Perspective, OpenAI Moderator и обычным классификатором активаций). Результаты сильные: средний AUC по девяти сценариям злоупотребления достигает 0.97, а средний FPR удерживается на уровне 0.03. Для сравнения: методы дообучения вроде Circuit Breakers выдают AUC 0.68 при FPR 0.06, а подходы на основе проекций типа CAST дают те же 0.68 AUC, но с катастрофическим FPR в 0.60. Отдельного внимания заслуживает устойчивость к атакам. При атаках типа Misdirection, когда вредный контент разбавляют безобидным шумом, GAVEL удерживает TPR выше 85% по всем категориям. В то же время GPT-4 в роли судьи проседает до 12–15% на задачах с бредовыми теориями и вмешательством в выборы, а перехват цели и обход фильтров через перефразирование систему тоже не ломают. GAVEL остаётся стабильным, так как смотрит на внутренние когнитивные состояния модели, а не на поверхностные токены. Ещё важно сказать про переносимость между моделями и языками. Одни и те же датасеты когнитивных элементов и правила работают на Llama3-8B, Qwen3-8B и Gemma-4B без переобучения. При тестировании на трёх языках (английском, испанском и китайском) TPR держится в коридоре 0.86–1.0 при почти нулевом FPR.   Что на практике Во-первых, интерпретируемость, когда срабатывает алерт, ты видишь, какие именно CE его вызвали и какое правило применилось. Это отличается от бинарного классификатора, который просто говорит "опасно". Во-вторых, модульность - добавление нового сценария атаки, по сути, правка JSON-файла, а не переобучение модели. В-третьих, переносимость - подход работает с разными LLM без модификации базовой модели, меняется только RNN-зонд. Но. Вся система стоит на точности отдельных CE-зондов. Если RNN ошибается в детекции making_threat, то правило tax_scam, просто не сработает и ты об этом можешь не узнать. RNN-зонды сами по себе требуют размеченных данных для обучения, и качество CE-таксономии напрямую определяет качество всей системы. Ручное написание правил не масштабируется автоматически - для каждого нового домена нужна экспертиза. И это всё равно внешний слой контроля поверх модели, а не решение проблем безопасности самой LLM. Полезно для регулируемых отраслей, где важны аудит и объяснимость. GitHub: https://github.com/Offensive-AI-Lab/gavel

Давно я не делал обзор на интересные книги в AI Security для новичков. Пора исправляться. Недавно бегло пролистал свежую книгу Practical AI Security от Харриет Фэрлоу. Авторша работала в австралийской разведке и писала кандидатскую по состязательным атакам. Раньше она проводила курсы для государственных организаций, по AI Security. А сейчас она делает свой стартап и ведёт бимбобложик. Редкое сочетание. Впечатление специфическое. С одной стороны это отличный онбординг для классических экспертов по кибребезе. Фэрлоу не зацикливается только на простых тактиках джейлбрейка моделей, а структурно и простым языком разбирает атаки на цепочку поставок, а также атаки по сторонним каналам на кластеры GPU и показывает фреймворк MAESTRO для мультиагентных систем, который мы разбирали в начале прошлого года. К книге идет репозиторий с кодом. Можно запустить и покрутить руками, хотя местами атаки выглядят откровенно тепличными и учебными. До того чтобы внедрить в продакшен тут далековато. Но это ж и не задача книжки. Задача дать базу. С другой стороны книга отлично показывает одну из очевидных и интересных проблем, о которой я говорю уже давно. Целые разделы посвящены гардрейлам и фильтрации инструкций, но через банальные регулярные выражения. Мы давно знаем, что внедрение таких заглушек только нормализует девиантное поведение системы, создавая иллюзию контроля для безопасников, пока сама архитектура остается дырявой. Но приятно, что книга собирает воедино ровно те тезисы, которые также были мной описаны в постах с самого начала ведения канала. MLSecOps, изоляция архитектуры, white box подход и подходы к здравой оценки магического мышления вокруг безопасных моделей. Из действительно сильных и пугающих примеров приведу историю из книги, про Африку. Сам впервые прочитал именно тут о ней. В 2020 году в южноафриканском парке браконьеры обошли систему инфракрасных камер на базе Microsoft Azure, которая должна была обнаруживать людей. Система обработала десятки тысяч изображений, но пропустила нарушителей. В итоге погибли четыре носорога. Действительно трагичные последствия, в сравнении с теми инцидентами о которых я писал тут 🐱. А вот еще один кейс, думаю вы его читали, но если нет - то вот кратко. В 2025 году исследователи успешно взломали Google Gemini через отравленные приглашения в календарь. Небезопасные инструкции были вшиты прямо в текст встречи, и агент Gemini, пытаясь помочь пользователю, начал отдавать команды умному дому на открытие штор и включение бойлеров. Хорошая иллюстрация того, что происходит, когда мы даем моделям автономию и доступ к инструментам, полагаясь лишь на промпты и эвристики вместо жесткой архитектурной изоляции и границ доверия. Фэрлоу в своей книге как раз говорит, что AI Security давно переросла рамки обхода фильтров в чат-ботах. Это про некий системный образ мышления, про границы доверия и понимание того, как модель встроена в инфраструктуру. Если мы даем агенту доступ к умному дому или камерам в саванне без жесткой архитектурной изоляции, никакие гардрейлы нас не спасут. Иллюзия контроля остается иллюзией, пока мы не начнем проектировать безопасность на уровне архитектуры, а не лепить заплатки регулярками и прочим шлаком. Но для давних читателей моего канала - это может показаться базой. Да и много упора на регуляторику. Это как раз говорит о том что сама книга, как фундаментальная база и карта системных угроз - вещь полезная. Но если вы ищете грязную практику обхода white box защит на уровне токенов и механистической интерпретируемости, то надо поработать самому. Советую почитать недавним читателям моего канала. книга, надеюсь не забанят, но если забанят то вы будете знать почему.

Я спарсил кучу AI Security тулов на GitHub и посмотрел на качество. Звёзды врут, а каждый четвёртый инструмент уже не поддерживается. (приготовьтесь, много чисел) Недавно я писал про агентные скиллы, да и про то, что мне часто в мои репозитории отправляют шлак. Я решил спросить себя, а что в самом тулинге по нашей теме - не в скиллах, а в реальных проектах, сканерах, гардрейлах и бенчмарках? Я собрал и разобрал их так же безжалостно. Считал я так. 28 дорк запросов к GitHub по топикам и ключевым словам, включая неочевидные запросы для поиска foolbox и прочих инструментов (не всё так просто ищется). Получилось 1 136 кандидатов. После очистки осталось 510 релевантных репозиториев и 477 реальных инструментов. Срез сделан на конец мая - начало июня. Качество я оценивал без звёзд как сигнала, потому что мы уже сами показали, что они врут: тиры считались по свежести коммитов, реальному объёму кода, лицензии и послужному списку в виде форков. Я не всегда смог запускать код. Я оцениваю, что это за код, структуру, данные и какие именно там используются механизмы защиты/атаки, а не насколько хорошо он ловит атаки (думаю об этом отдельно). Дополнительно каждому инструменту я выставлял статическую оценку инженерного качества от 1 до 5 (1 - тонкая обёртка без валидации, 5 - крепкий код с тестами, CI и собственной оценкой точности). Первое, что бросается в глаза - 84 инструмента из находимого рынка созданы за первые пять с половиной месяцев 2026 года - для сравнения, за весь 2025-й их было 43, а за 2024-й всего 25. Главный драйвер - агенты: 35% инструментов относятся к безопасности агентов, и 68% из них родились уже в 2026 году. Это значит, что человек, который сегодня гуглит «LLM guardrail», в большей степени выбирает из проектов младше полугода, без послужного списка и без единой опубликованной оценки. Сколько здесь качества, а сколько мусора, зависит от того, на какой уровень смотреть, поэтому я разделил выборку на две популяции. Видное на рынке - это 239 инструментов с пятьюдесятью звёздами и выше, то есть то, что вы реально найдёте поиском. Из них половина качественные, 24% - инструменты, которые особо никто не проверял, да и живых данных нет по ним (живые, но без сильной поддержки), ещё 24% заброшенные, без коммитов больше года, и 2% откровенный мусор. Длинный хвост ниже десяти звёзд выглядит иначе: 60% там чистый шлак, 39% инструменты, которые не валидировались разработчиком и слабые по качеству. Если упростить - меньше половины находимого тулинга в нормальном состоянии, каждый четвёртый заброшен, а всё, что ниже десяти звёзд, почти полностью мусор. Тезис про звёзды подтвердился во второй раз. Топ-10 репозиториев держат 50% всех звёзд в нише, и при этом 21 инструмент с двумястами пятьюдесятью звёздами и выше заброшен на год-два. Среди них именно те, к которым тянутся первыми: protectai/rebuff с 1 499 звёздами -  знаем его, писал про него ещё в 2024, последний коммит которого собственно был в августе 2024; BorealisAI/advertorch с 1 364 звёздами, мёртвый с 2023 года; репозиторий verazuo/jailbreak_llms с 3 705 звёздами - датасет, замороженный в 2024. По категориям здоровье очень разное. Сканеры держатся лучше всех - 77% реального качественного материала и почти ничего заброшенного; якоря здесь promptfoo с 22 тысячами звёзд, NVIDIA garak с восемью тысячами и cyberark FuzzyAI. Если кому и доверять, то этой категории. Гардрейлы - монетка: 44% качества против ровно такой же доли непроверенных, десятки почти одинаковых «AI agent firewall», половина из 2026 года и почти без реальных тестов со стороны. Бенчмарки оказались ловушкой - 46% из них заброшены, а замороженные в 2024-м бенчмарки как мы можем догадаться – измеряют угрозы 2024 года. Дальше я перешёл от взгляда снаружи к чтению исходников. Разобрал 24 настоящих гардрейла и посмотрел, что они вообще предъявляют как доказательство, что детект работает. Публичный бенчмарк уровня JailbreakBench или AgentDojo нашёлся ровно у одного из 24, то есть у 4%. Свой внутренний крошечный набор используют 33%. Ещё 8% называют «бенчмарком» то, что мерит скорость, а не точность. И у 54% нет вообще никакой оценки точности в ловле промпт-атак. Иными словами, статически вы не можете понять, ловят ли атаки 96% гардрейлов. Технически при этом они выглядят нормально - средняя оценка 3.5 из 5, есть тесты, CI и многослойность, - но качество кода не равно доказанной защите. Характерная деталь: llm-guard, pipelock и rampart хвалятся миллисекундной задержкой, но не приводят ни одного значения TP или FP. Скорость измерить легко, корректность трудно, поэтому мерят скорость. В коде вскрылись ещё два звоночка. Четыре гардрейла из 24 имеют необследуемое ядро: aegis и ZenGuard - примерно 90 строк клиента к закрытому облаку, а last_layer прячет детектор в бинарный .so с заявленными «92%», которые невозможно проверить; «open source» там декоративный. А девять из 24 вообще не про инъекции и джейлбрейк - PII- и инструменты для маскировки данных под вывеской «гардрейл», так что реальная категория защиты от промпт-атак - мала. И прослеживается закономерность: кто честен, тот показывает скромные числа - localmod 0.75, cloakbot прямо признаёт утечку в 6-8%, - а кто рисует «100%» и «92%», тот невоспроизводим. Если посмотреть на то, чем вообще детектят, картина по категориям складывается такая. У гардрейлов regex остаётся каркасом всей ниши и используется в 75% случаев; чисто на регулярках построен 21% - это нормально для PII, но хрупко для семантики. Чистого LLM-судьи как единственного слоя нет ни у одного: это дорого и недетерминированно, поэтому он всегда идёт в составе гибрида, а сам гибрид - мейнстрим, на него приходится 54%. Худший класс - закрытое ядро со средней оценкой 2.0. Сканеров я разобрал 44, и они делятся почти пополам: 16 динамических, которые шлют атаки в живой таргет (garak, PyRIT, FuzzyAI), против 17 статических, анализирующих код и конфиги без запуска. Самый сильный класс среди них - LLM-redteam с оценкой 4.4, хотя его находки держатся на «утверждает модель»; самый слабый из настоящих - чистые сигнатуры с 3.4 и нулём при собственной оценке. При этом 14% «сканеров» - вообще не сканеры (а больше, как инструменты для получения информации о происхождении данных и governance), а свою точность мерят лишь 24% из них. Бенчмарков формально 13, но настоящих только девять; остальные четыре - это гайд, awesome-лист, одиночная атака и сканер-тулза. Единого стандарта скоринга нет: метрику ASR или F1 используют шесть, LLM-судью двое, правила один, ручную разметку один, а трое не считают ничего. Четыре бенчмарка из 13 заморожены. Регулярки - универсальный и дешево, так к сожалению заведено в разработке инструментов для AI-security и при этом везде хуже всех проверяемо с точки зрения качества. LLM-as-judge - растущий слой, на нём построены лучшие новые тулзы, но он недетерминирован и не калиброван. Свою точность почти никто не мерит: около 4% гардрейлов и 24% сканеров, а сами бенчмарки, которые должны быть линейкой, фрагментированы и на треть заморожены. И ярлыки протекают - 14% «сканеров» и 31% «бенчмарков» на деле оказываются чем-то другим. Главная же параллель со скиллами вот в чём: раз 96% решений не публикуют точность, выбор идёт вслепую, а гардрейл, молча пропускающий атаку или режущий легитимный трафик, и есть тот самый случай, когда защита «делает хуже». Ну и вывод такой. Сортируйте инструменты не по звёздам, а по дате последнего коммита и числу форков. По умолчанию доверяйте сканерам и скептически смотрите на гардрейлы, закладывая цикл замены примерно в 12 месяцев. Не верьте «безопасности», подтверждённой замороженным бенчмарком. Читайте код и лицензии. Датасет с оценкой я опубликую в комментах к посту. Можно использовать как bullshit-фильтр. 😁. А можете и оспорить мои цифры в комментариях. А если ок - кидайте звёзды и реакции)

RCE-уязвимость обнаружена в Hugging Face Transformers (CVE-2026-4372) 😭 Уязвимость особенно неприятна тем, что позволяла выполнять произвольный код даже при использовании рекомендованной защиты trust_remote_code=False.  Атакующему было достаточно добавить в config.json модели специальный параметр _attn_implementation_internal. При загрузке модели через привычный from_pretrained() библиотека могла автоматически скачать и выполнить код из внешнего репозитория без предупреждений, запросов подтверждения и заметных признаков компрометации.😓 Под угрозой оказались версии Transformers 4.56.0–5.2.x, особенно среды с GPU-ускорением и установленным пакетом kernels. За время существования дыры (около 6 месяцев) уязвимые версии были скачаны более 232 миллионов раз!  Что делать: 👍 Обновиться 🎊 👍Проверить кэшированные модели на наличие _attn_implementation_internal 👍 Загружать модели в изолированных контейнерах 👍 Рассматривать загрузку моделей как потенциальную поверхность для выполнения кода 👍Подтянуть AppSec и Supply Chain Security в ML/AI-проекты (ну это вообще всем надо!) Получается интересно, конечно 🤔! Разработчики уже выработали здоровую паранойю при установке Python-пакетов, npm-зависимостей и Docker-образов, но при этом могут совершенно спокойно скачать новую модную модель и запустить её в корпоративной инфраструктуре. Фактически, это ещё одно напоминание о том, что современные AI-модели становятся полноценной частью цепочки поставок ПО. Загружая модель из интернета, мы всё чаще выполняем чужой код, даже если кажется (тот случай, когда если кажется, то кажется!), что загружаем только веса нейросети.  Все 🦔