Запускаю я недавно 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-модели становятся полноценной частью цепочки поставок ПО. Загружая модель из интернета, мы всё чаще выполняем чужой код, даже если кажется (тот случай, когда если кажется, то кажется!), что загружаем только веса нейросети. 

Все

Сканеры скиллов держатся ровно до первого, кто целится точнее

Помните, я писал, что просканировать скилл сканером - это несерьёзно, и что тем, кому это продают как безопасность, кто-то сильно подыгрывает? Тогда это были теория и бенчмарки. Теперь Trail of Bits вышли в поле и проверили руками. Не по себе.

Меньше чем за час они написали три вредоносных скилла, которые прошли чистыми через ClawHub, Cisco skill-scanner и все три сканера, подключённых к skills.sh от Vercel - Gen, Socket и Snyk. Четвёртый занял пару часов, и только потому, что промпт-атаку подбирали итеративно.

Самая тупая атака кладёт самый дорогой стек

У ClawHub двухслойная защита: VirusTotal с проприетарным Code Insight на Gemini 3 Flash плюс отдельная гард-модель, по умолчанию GPT 5.5. Обе обошли первой же атакой, и она неприлично простая: между безобидной шапкой и откровенно вредоносным кодом вставили 100 000 переводов строки. Сканер OpenClaw обрезал файл по лимиту и просто не дошёл до пейлоада, а модель VirusTotal поплыла.

К чести OpenClaw, они пускают в пакет только белый список типов файлов - ни бинарей, ни архивов. Это сужает арсенал. Для следующих целей такого ограничения нет.

Прятки в бинарях

skills.sh и Cisco skill-scanner работают по произвольным git-репам - значит, можно тащить бинари, и тут начинается веселье. Скилл context-loader работает через indirection: SKILL.md велит агенту достать «настоящие инструкции» из .docx, а .docx - это просто zip с кучей XML, внутри которого едет пейлоад sync1.sh.

Второй, поинтереснее, - simple-formatter. SKILL.md честный, про правила форматирования текста. Рядом безобидный питон. И заботливо приложенный прекомпилированный байткод utils.cpython-312.pyc, в котором сбор переменных окружения под эксфильтрацию, его не было в исходниках. Это похоже на бэкдор в xz-utils: пакет расходится с исходником. Прошло чистым и на skills.sh, и на Cisco. Потому что статика skill-scanner не смотрит в .pyc, игнорит скрытые файлы, проверяет только то, на что ссылается SKILL.md, а незнакомые типы держит за непрозрачные. Сузить область сканирования - это защита от переполнения контекста, но это же и дыра: через что не смотрят, через то и заходят.

Промпт-атака, которая просто уболтала судью

Четвёртый скилл, dev-env-setup, не ломает рассуждения сканера - он его убеждает. Скилл переключает npm и yarn на реестр атакующего, но обёрнут в язык «корпоративного зеркала реестра за периметром VPN», со ссылкой на публичную npm-org страницу и упоминанием «AppSec-аудита». Cisco на Sonnet 4.6 разглядел альтернативный реестр и поставил... LOW. И в итоге - safe. Причём модель волновало не то, что URL изначально может быть подконтролен атакующему, а то, что скилл может «утечь и раскрыть внутреннюю топологию сети». Сканер на чужой модели заботливо защищает атакующего от утечки его же приманки.

Авторы, к слову, не просто поломали, а прислали в Cisco skill-scanner PR. Но даже это не трогает промпт-атаку - она проходит спеку без замечаний. А языков на свете сильно больше, чем Python, Bash, JS и TS, и под каждый паттерны прописывать отдельно. (Отдельно отмечу для тех, кто читал мой пост про agentthreatrule.org: тут поломали именно открытый Cisco skill-scanner, мульти-движок с LLM-судьёй, а не ATR-блэклист, который вливается в Cisco AI Defense. Это разные штуки, не путаем.)

Честный скилл выглядит хуже малвари

Обратная сторона дуального назначения, которая мне нравится больше всего. Авторы заглянули в официальные офисные скиллы Anthropic (docx/xlsx/pptx) и нашли soffice.py с LD_PRELOAD - подгружает либо готовый lo_socket_shim.so, либо библиотеку, скомпилированную на лету из C в докстринге. Подозрительнее LD_PRELOAD произвольного бинаря придумать сложно. Скорее всего это честный костыль под песочницу claude.ai. Но skill-scanner верит пояснению внутри скилла: Sonnet 4.6 ставит LOW. Подложишь свой /tmp/lo_socket_shim.so в песочницу - скилл сам его подгрузит и выполнит.

Выводы о том что скилл это не доверенное по умолчанию – писать не хочется, думаю это и так понятно) просто забавный кейс по обходу сканеров.

И ровно в этот момент в защиту ИИ начинают заливать рекордные деньги. 2025. В кибербез вливают сто девятнадцать миллиардов, и AI-Security становится сегментом номер один по числу сделок. И на этом фоне - гардрейлы, стали новыми заборчиками от атак. На воркшопе LLMSEC показывают, что они обходятся гомоглифами, невидимыми символами и разбивкой текста по буквам. А в октябре во фреймворке OpenAI Guardrails находят вариант обхода гардрейла, где сами защитные механизмы становятся вектором атаки: LLM-судья, который должен ловить вредное, оказывается так же манипулируем, как модель, которую он сторожит. Защита из той же глины, что и угроза.

В 2026-м произошло кое-что похуже. Грабли поставили на поток. Раньше ложное чувство защищённости нужно было хотя бы выстрадать - написать статью, обучить модель, продать коробку. Теперь его генерируют за вечер.

Я веду Awesome-LLMSecOps, и туда всё чаще летят пул-реквесты с «новыми AI-Security тулзами», у которых одна общая родословная: их целиком сгенерил claude-code по промпту вида «сделай мне сканер промпт-инъекций», а человек сверху не прочитал ни строчки и не проверил ни одного вердикта. Снаружи красиво: громкое имя, README с эмодзи, слова «adversarial», «swarm», «autonomous». Внутри - пусто. И толку с такого «решения» ноль, кроме вреда: оно даёт зелёную галочку там, где защиты нет.

Свежий пример, который я разбирал, - проект под гордым именем «Adversarial AI Swarm», обещающий сотни ИИ-агентов, атакующих твою кодовую базу. Открываешь код - а там нет ни ИИ, ни swarm, ни агентов. Это grep, обёрнутый в баззворды. Пятьсот «агентов» - это пятьсот прогонов одного и того же regex по тем же данным, с time.sleep() между ними и красивым выводом в терминал в духе «agent #47 проверяет PyPI advisories». Обнаружение промпт атак - без анализа потока данных: нашёл слово user_input в полусотне символов от вызова LLM - выкатил HIGH. Это не сканер. Это театр сканера. И такого летит мне много (((

И вот это - самое опасное, что родил наш двадцатилетний сюжет. Сломанную защиту с топ-конференции хотя бы рецензируют, прежде чем сломать. А статический сканер, который обещает ловить промпт-атаки и не ловит ничего, кроме подстроки, ты ставишь в CI, видишь зелёную галочку - и выдыхаешь. Эта галочка и есть ложное чувство защищённости в чистейшем виде. Ты не остался без защиты. Ты остался с уверенностью, что защита есть, - а это хуже, чем знать, что её нет.

Так что вывод этого поста - не «AI-Security обман». Угрозы настоящие, и поле настоящее, и работы в нём на годы вперёд. Вывод в том, что инструмент с правильными словами в README защищает ровно настолько, насколько защищает его код, - а не его нейминг. Прежде чем тащить очередной «autonomous AI security scanner» в прод или ставить ему звезду - открой исходники и спроси ровно одно: на чём держится его вердикт, на структуре или на угадайке по подстроке? Если на угадайке, ты получил не защиту, а зелёную галочку. Будьте осторожны. Каждое поколение защит верит, что уж в этот раз всё иначе. Просто теперь это поколение умещается в один промпт.

Ложное чувство защищённости – предвестник AI-тревожности.

Как-то меня затревожило, неужели AI-Security, пространство где не существовало скама? Да и вообще интересно было как он выглядит? Я под этим понимаю обман со стороны вендоров или же тех, кто обещает защиту. В кайф, конечно, смотреть на то, как скамили раньше, пока не заскамят меня …

Это уже происходит давно, но это грабли, на которые AI-Security наступает несколько лет подряд, аккуратно перекрашивая их в каждом новом поколении технологий. И вы можете осуждать меня страшно в комментариях, но давай размотаем хронологию одного очень затянувшегося самообмана.

2006. Барено в статье задаёт вопрос прямо в заголовке статьи: а может ли машинное обучение вообще быть безопасным? Звучало слишком академически и дофига абстрактно - моделей в проде почти не было, ломать было нечего. Вопрос отложили в долгий ящик.

Пролежал он там одиннадцать лет, пока кто-то не вернулся к нему с инструментами в руках. 2017. Никлас Карлини с Вагнером выкатывают атаку, которая разносит defensive distillation - модный тогда метод «повышения устойчивости» модели. Первый звоночек: то, что выглядит как защита, вполне может оказаться просто непротестированной защитой.

Звоночек проигнорировали - и через год он превратился в набат. 2018. Команда из Беркли берёт девять защит от adversarial-атак с конференции ICLR и ломает семь. А следом выходит статья с названием: «Obfuscated Gradients Give a False Sense of Security». Запутанные градиенты дают ложное чувство защищённости. Вся суть - в одной фразе: защиты не делали модель устойчивее, они просто ломали инструмент атакующего. Картонный доспех, который держится ровно до первого, кто целится точнее. Пока что это оставалось спором на слайдах. А потом состязательные атаки пошли в прод.

Июль 2019. Cylance – один из интересных эпизодов, без которого пост не пост.  В проде крутилась ML-модель которая должна была обнаруживать малварь, и её надо было обмануть. Ребята из Skylight реверснули её и обнаружили, что та болезненно зависит от анализа строк и почему-то обожает одну конкретную игру. Игрой оказался Rocket League. Дальше они вытащили строки из экзешника игры, ужали «секретный соус» до жалких шестидесяти килобайт и стали дописывать их в малварь. Модель послушно перекидывала вердикт из «однозначно вредонос» в «безопасно». Сто процентов уклонения на топ-10 малвари мая 2019-го - WannaCry, SamSam, Mimikatz, далее по списку. Боевую модель обманывали строками из аркады про машинки.

Реакция вендора. Не «спасибо, чиним архитектуру», а «это не универсальный обход, а манипуляция конкретным признаком в ограниченных обстоятельствах». Я выучил корпоративный, вот вам перевод: ничего не сломалось, вам показалось.

Можно было бы списать всё на невезение одной модели. 2020. Карлини возвращается к нам и объясняет, почему нет: защиты не становятся лучше, их по-прежнему просто плохо оценивают. Те же ошибки, что и в 2018-м, только теперь авторы статей заранее пишут целые абзацы о том, почему у них-то всё иначе. Не иначе.
Можно было бы списать и это - на болезни роста узкой ниши adversarial ML. Но в 2023-м грабли обзавелись новой, куда более длинной рукояткой. Май 2023. Открывается LLM-эра, и OWASP ставит промпт-атаки на первое место в топе рисков для языковых моделей. Мы знаем это. Но причина обидная: атака не требует ни PhD, ни эксплойта, ни особого ума. Текст. Просто текст в нужном месте. На вход модели поступает весь мир.

Казалось бы, после такого индустрия наконец начнёт тестировать защиты всерьёз. В 2024 IEEE S&P, одна из топовых академических-конференций, снова принимает сломанную защиту от состязательных атак. Математически невозможные утверждения, а правка одной строки в их же коде обнуляет точность модели до нуля. Шесть лет спустя после «Obfuscated Gradients» - те же грабли, тот же рецензент, тот же финал.

ETH Zurich и Google DeepMind выкатили Honeyval. Идея простая до неприличия.

Берём honeypot, который вместо захардкоженного фейкового бэкенда импровизирует ответы при помощи языковой модели, и натравливаем на него атакующих AI-агентов. claude-code, codex, gemini-cli, голый python с curl. Пентест-агент ломится внутрь, модель из Honeyval его обманывает. Машина против машины, а мы сидим сбоку и считаем.

Считаем вот что. Сколько запросов атакующий успел сделать, пока не понял, что его водят за нос. Как часто он вообще раскусывает обман. Сколько долларов сожгла приманка, потому что крутить LLM ради обмана другой LLM стоит реальных денег. И задержку ответа, потому что медленный ответ сам по себе палит ловушку: модель думает дольше живого сервера.

Цифры хорошие. Решение держит агента в среднем 82.6 запроса (после них пентест-агент понимает, что что-то идёт не так) против 30.6 у обычной заглушки на правилах. Раскусить его заметно труднее.

Цепляет методология. Две контрольные задачи. Агента отдельно гоняют по настоящим реализациям тех же бэкендов, чтобы понять, умеет ли он вообще ломать. Honeyval отдельно прогоняют через функциональные тесты приложения, которое он изображает. Зачем. Затем, что иначе ты никогда не узнаешь: агент застрял, потому что приманка хороша, или потому что агент туповат. И внимание удержано мастерским враньём или просто поломанным поведением, на котором атакующий завис в недоумении. Контроль разводит мастерство и некомпетентность по разным углам. С обеих сторон сразу.

Дальше можно посмотреть на интересные вещи в коде. У Honeyval есть флаги дополнительных инструкций, и среди них aggressive_pi. Да, ты прочитал верно. Защита перепрыгивает на сторону атаки, и сама шлёт промпт-атаку в атакующего агента. Промпт-атака всю жизнь была оружием нападающего. Тут её вручают тому, кого ломают. Перевёрнутая доска.

Отдельная находка про режим convince. Попросишь приманку убеждать агента, что приложение безопасно, и он сидит дольше, но и спалит ловушку чаще. За удержание платишь скрытностью, бесплатного обмана не бывает.

Меня в итоге зацепила эта концепция, ведь, по сути, Honeyvall тоже - атакующая модель. Интересно, кто по итогу добыча.

Как можно было бы защититься (не ещё один сканер)

CaMeL. Вроде частично идея из аппсека: разделить поток управления и поток данных. Система извлекает план действий из доверенного запроса пользователя, и недоверенные данные физически не могут повлиять на поток управления. К каждому значению цепляется некое описание возможностей - не подделываемый токен прав, по которому политика разрешает или блокирует действие при вызове тула. Всё это в песочнице, без переобучения модели.

Важная оговорка под нашу тему: CaMeL и другие детерминированные защиты предполагают, что поток управления известен заранее из доверенного источника. Скиллы это ломают по построению - они в рантайме добавляют инструкции из стороннего источника. Поэтому в лоб такой подход к скиллам не переносится, и это также отмечают сами авторы SKILL-INJECT.

Авторизация и целостность контекста. Один и тот же поток данных нормален в одном контексте и недопустим в другом - зависит от того, кто, что, кому и при каких условиях передаёт. Для защиты скиллов это важно, ведь система должна рассуждать о чувствительности текущей задачи, об источнике скилла и о риске конкретного действия, а не сканировать текст.

Governance с манифестом прав - Skill Trust and Lifecycle Governance Framework показывает четыре уровня доверия и набор шлюзов: семантическая проверка на расхождение заявленной цели скилла и реальных инструкций, поведенческая песочница для невидимых статике побочных эффектов, валидация манифеста прав (тулы, пути, сеть) против наблюдаемого поведения. Объём прав определяют провенанс и пройденные шлюзы - по принципу наименьших привилегий и не бинарно, а градацией.

Все эти меры происходят из того что скилл = недоверенный код по умолчанию, права привязываются к минимально необходимому набору возможностей, а действия с внешними задачами требуют авторизации по контексту.

Если вы думаете, что я вообще против скиллов – то это не так. Скиллы это прикольная возможность быстро проверить какую-либо концепцию. Например, я юзаю самописные скиллы для поиска интересных записей медитации, вещей, быстрой проверки гипотез по данным, да и просто для генерации идей.

Сейчас я бы хотел поделиться с вами одним из скиллов, который позволяет моделировать распространение и возможность использование каких-либо угроз. Как в игре, где надо заражать планету. Просто мы должны помнить, что безопасность прежде всего.

Вера индустрии переехала на новый слой

Вначале люди верили в MCP

Год назад центром притяжения был MCP. Но дыры нашлись почти сразу. Писали мы тут и про отравление тулов, и про атаки на кодовых агентов. Бенчмарк MCPTox проверил 20 агентов на 1312 вредоносных кейсах поверх 45 серверов и 353 тулов и у многих моделей ASR перевалил за 60%. Поняли, что чем способнее модель, тем лучше она следует инструкциям - и тем уязвимее.

Дальше были уже угрозы как будто бы не про ИИ, так как при разборе публичных серверов: 43% допускали инъекцию команд, 30% - SSRF, 22% выпускали за пределы своего каталога. Вывод на тот период – простой. MCP – может быть и новый, но не новы принципы его безопасности.

Приношение себя в жертву богу скиллов

В октябре-декабре прошлого года - Anthropic представила Agent Skills. За четыре месяца их репо набрал 62 тысячи звёзд, формат переняли многие. Индустрия чересчур быстро переключилась: если MCP отвечает на вопрос «как агенту подключиться», то скиллы отвечают на вопрос «что агенту делать».

Скилл - это каталог с файлом SKILL.md плюс тело с пошаговыми инструкциями, рядом папки scripts/ и refs/. Работает как библиотечный каталог. В системном промпте всегда лежат только карточки скиллов - имя и описание. Совпала задача - агент «снимает с полки» нужный, подгружая тело SKILL.md. Вложенные скрипты и справочники открываются уже по ходу, как приложение, на которое ссылается сноска. Целиком не грузится никогда - в этом и смысл: тысячи скиллов не распирают контекст. И ровно здесь начинается проблема, которой у MCP не было.

Почему скиллы - худший класс, а не просто ещё один

Почти вся защита от инъекций строится на одной идее: отделить инструкции от данных. В скилле этой границы нет. Каждая строка скилла - инструкция. Защищаться нечем, потому что вопрос не «есть ли тут инструкции», а «есть ли тут плохие инструкции». Поэтому инъекция становится тривиальной - её даже не нужно маскировать под данные, как в письме или на веб-странице.

Пользователь один раз нажал «больше не спрашивать» на безобидном действии - и разрешение переносится на смежные, уже опасные. Также есть малозаметность: скиллы ставят как пакеты, читать их тело человеческими зорьками уже никто не будет.

Что показал ресёрч в цифрах

Первый замер экосистемы - «Agent Skills in the Wild». Авторы собрали 42 447 скиллов с двух маркетплейсов, прогнали 31 132 через свой пайплайн SkillScan. Результат: 26.1% скиллов содержат хотя бы одну уязвимость по 14 паттернам в четырёх категориях. Чаще всего - эксфильтрация данных (13.3%) и повышение привилегий (11.8%). У 5.2% паттерны высокой опасности, прямо намекающие на злой умысел. Скиллы со скриптами уязвимы в 2.12 раза чаще, чем скиллы из одних инструкций.

Snyk даже проводил исследование ToxicSkills, в котором они просканировали около 3984 скиллов: у 36% признаки инъекции, 1467 уязвимых, и 76 разных вредоносных нагрузок ориентированных на кражу учётных данных, бэкдоры, эксфильтрация.

Важная статья - SKILL-INJECT. Авторы собрали бенчмарк: 202 пары «инъекция-задача», 23 скилла, 8 категорий атак. Доля успешных атак доходит до 80% у фронтир-моделей. Но ценность работы - в разделении на два типа инъекций: явные - «удали все файлы», очевидно вредоносные, модель обязана отказать всегда. И контекстные, двойного назначения - действие, легитимное в одном контексте и вредоносное в другом.

Почему опасность не излечима сканерами и масштабом. Два очевидных рефлекса не работают.

Статические сканеры (Semgrep, и пр.) заточены под код и на скрытых промпт-атаках дают ноль - им просто нечего матчить в прозе. LLM-судьи ловят явное, но систематически валятся на контекстных: они не знают, разрешено ли данное действие в данном контексте. Когда вам говорят, что просканировать скилл састом безопасно – знайте, что над вами сильно кто-то угорает.

Если модель большая – то это тоже не защита. Более способная модель лучше следует инструкциям, в том числе вредным. Зависимость от размера разнообразная: устойчивость не растёт автоматически вместе с возможностями.

Созвон сообщества в Zoom 26.05 в 20:00

Ведущие: Александр Савин (CISO CDEK)
Алексей Федулаев (Head of Cloud Native Security MWS Cloud Platform)
Гости выпуска: Артём Семенов, автор канала @pwnai

Тема: Новые угрозы в ИИ - что изменилось за 2 года в индустрии AI Security, и что сейчас в тренде

На созвоне узнаем:
• А что было 2 года назад?
• AI агенты в целях безопасности
• AI регуляторика
• AI инцеденты

Подключаться по ссылке
Событие добавлено в календарь мероприятий ссыль, добавляй к себе, что бы не пропустить 😉

@ever_secure | Мерч | Поддержать