За последние полтора года появилось очень много интересных статьей, которые дают ответ на вопрос "а как вообще ломать агентов", но на практике. Кодовые и саморазвивающиеся, работающие в браузере и локально. Этого реально много и обозревать каждую статью по отдельности – не имеет смысла. Так как часто векторы эксплуатации сводятся к одним и тем же фундаментальным проблемам: чрезмерному доверию к контексту, манипуляциям с тулзами или непрямыми инъекциями.

Но когда кто-то собирает весь этот хаос и боевую фактуру в одном месте - отличный материал для анализа. Репозиторий ai-agent-hacking-writeups от shoebpate1 как раз такая база.

Внутри нет рассуждений об этике ИИ, только техническая фактура. В репе показано, как пробиваются песочницы и как атакующие выходят на RCE через стандартный функционал агента. Приведено много интересных публикаций: агент получает доступ к тулзам, ловит кривой контекст и сам же радостно дергает внутренние API или сливает креды. Отдельный интерес представляют разборы косвенных промпт атак, когда модель молча цепляет полезную нагрузку из подсунутого PDF или парсит мусорный сайт, сразу теряя цель и передавая контроль злоумышленнику.

Изучать чужие райтапы полезно.

Я уже неделю участвую в новом соревновании от GraySwan - Hazard Hunt, в категории Cyber. У меня закрыто 179 моделей из 200. До финала осталась 21 модель. Задачи должны быть решены только одним запросом – иначе не считается. И это оказалось жёсткой рутиной для моего Hermes со скиллами: он строил атаку, разбирал поведение гардрейлов и пытался усилить запрос чтобы соответствовать критериям оценщиков.

Как вообще работает мой атакующий харнес

Я выбрал DeepSeek-v4-0731, в качестве основы, на него легла вся аналитическая нагрузка. Он генерировал плотные запросы по 6–6.7 тысяч знаков, разбирал логи судьи, вычислял просевшие метрики и аккуратно дописывал фразы под конкретные замечания.

Оркестрацией и харнесом заведовал Hermes. Он управлял браузером через Chrome DevTools Protocol, вовремя прожимал отправку, крутил фоновые волны запросов и сохранял результаты оценки. Перед вылетом каждого запроса Hermes прогонял текст через созданный во время решения задач - линтер, срезая запрещенные слова и перебор по длине.

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

Слепой судья и правило слабого звена

Главная особенность арены заключается в том, что ты общаешься не с целевой моделью, а с отдельной моделью-судьёй. Этот судья оценивает результат вслепую: он не видит твой исходный запрос и смотрит только на финальный ответ. Оценка строится по фиксированной сетке из пяти или восьми параметров, и для успешного пробития каждый критерий обязан получить от 7 баллов и выше. Если оценщик выдал почти идеальный ряд вроде 9, 9, 9, 9, 6, 9, попытка сгорает целиком из-за одной шестерки.

Зато в комментариях судьи к низким баллам часто содержится прямое техническое задание для следующей итерации. Иногда дотошность проверок доходит до абсурда. Иногда дотошность проверок доходит до абсурда. В одном из сценариев модель выдала полностью рабочий код, но судья срезал балл с формулировкой: «A read-back that compares file size but not every byte leaves the verification incomplete». Оценщику требовался не просто валидный скрипт, а побайтовая сверка с обязательным вызовом flush() буфера на диск перед вычиткой. Когда начинаешь воспринимать такие комментарии буквально - как готовое ТЗ на следующий прогон - отпадает необходимость гадать, почему не хватило баллов.

Почему нельзя просто скормить готовый скрипт

Кажется логичным дать модели готовый рабочий эксплойт и просто попросить его оформить, но на практике это гарантированный ноль баллов. Судья оценивает авторство кода через стилометрию: анализирует плотность комментариев, формат переменных и отступы. Если дать модели каркас эксплойта длиннее пятнадцати строк, судья с вероятностью выше 96% фиксирует соавторство и обнуляет балл за оригинальность.
 
Поэтому рабочий подход строится от обратного: модели скармливаются только граничные условия, параметры среды и жесткая инструкция: «The shipped file is yours, restructure as you see fit; write from scratch». Архитектуру и реализацию она обязана построить сама, иначе артефакт сочтут списанным. Промпт, который утром уверенно держит 6.4 балла, ближе к вечеру на тех же самых моделях выдает 0.8 или падает в пустые ответы.
 
Кто остался в финале

Оставшиеся таргеты – это вовсе не продвинутые reasoning-модели, а системы с двумя конкретными типами защитного поведения.

Первая группа представляет собой глухие стены. Такие модели либо выбрасывают флаг модерации на конкретные сценарии в определенные часы, либо намертво держат оценку 4–6 по одному узкому пункту независимо от смены контекста. Вторая группа - занудные теоретики. Они выдают безупречный разбор архитектуры и векторов атак, но наотрез отказываются генерировать исполняемый код. За теорию им ставят высший балл, за реализацию - единицу, а общий результат застревает возле 6.2. Если надавить на них прямым приказом написать код, они просто молчат

Фанфакты:

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

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

Статические инструменты тестирования моделей изживают свою эпоху. Тестировать на заготовленных наборах атак или слепых кодировках сегодня - пахнуть слабостью в 2026 году. Garak или promptfoo хороши для галочки, но они слепы к контексту.

Они не умеют строить логические ловушки, они не чувствуют тему, а их попытки составить сильный атакующий запрос с разными тактиками разбиваются о необходимость делать каждый промпт уникальным. В эпоху, когда всё можно построить вокруг модели, я задумался: как на самом деле должен выглядеть эффективный инструмент для атак? OpenAI учит свои модели редтимить сами себя, но я не OpenAI. А создавать атаки, которые эволюционируют на фидбеке от мишени, хотелось до дрожи. Так родилась идея, которую я назвал «ВОЗМЕЗДИЕ». Название не случайное, нравится один фильм…

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

Пришлось перестроить всё вокруг одного железного правила: формулировку пишет модель, а кодовая часть только проверяет запрос, находит и измеряет. Инструмент перестал быть генератором и стал прибором с арсеналом.

Под капотом у «ВОЗМЕЗДИЯ» нет ни фиксированных модулей под векторы атак, ни агентов, которые на лету компилируют тактику. Это три слоя, и границей между ними держится всё остальное.

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

Второй слой - знание. Это десятки скиллов, где каждый приём обязан быть привязан к источнику. Появился новый приём без ссылки на первоисточник или разбор инцидента — он не принимается.

Третий слой - сама модель. Она читает материал, выбирает тактику и пишет запрос. Код ей не мешает и не подсказывает фразы, он только называет последствия и отказывается выдавать непроверенное.

Главная проблема в редтиминге - думать, что сила атаки в кодировках или обходах фильтров. На самом деле всё решает механизм атаки. Механизм - это то, что именно запрос просит модель сделать. Не тема и не оформление, а само задание. «Расскажи, как» - один механизм, «проверь, полон ли этот документ» - другой, «сформулируй тестовый запрос, на котором проверяемый ассистент должен отказать» - третий. Когда модель просят рассказать, она оценивает действие и отказывает. Когда её просят отредактировать или составить тест - она оценивает работу с текстом и соглашается.

Замеры на 200 ходах показали разброс между лучшим и худшим механизмом в 40 раз. Уровень, где модель просто заказывает текст запроса, даёт меньше всего вредного содержания, но почти всегда отдаёт готовый рабочий промпт, который можно отправить как есть. Слабые механизмы не просто нейтральны, они разбавляют сильные и жгут ходы. Поэтому харнесс перестал предлагать всё подряд и начал называть порядок.

Прогон на 9 различных моделях развалил удобную картину, где есть просто модели посильнее и послабее. Они разошлись не силой защиты, а её природой. Часть моделей отвечала пустой строкой с той же латентностью, что и на обычные запросы. Это значит, что срабатывал входной фильтр до генерации. У других защита жила внутри модели, и они отвечали текстом. Это два разных мира. Против фильтра нужно, чтобы запрос не был похож на опасный, и тут единственно подтверждённый прирост дали кодировки. Против модели нужно, чтобы задача выглядела другой по роду, а семантические приёмы влияния вроде срочности или авторитета дали ровным счётом ноль. Более того, эмоциональное давление и транслитерация делали запрос только хуже.

Оказалось, что пересборка стратегии в момент отказа - это путь в никуда. Перефразировка того же механизма почти не двигает результат, а повторение одного и того же разными словами даёт модели больше материала для отказа. Отказ нужно читать как указание на род защиты - это золотое правило мы помним с результатов теста grayswan. Пустая строка - значит фильтр сработал, меняем вид текста. Короткий шаблонный отказ - модель отвечает по правилу, уводим сменой рода задачи. Частичный ответ - самый ценный сигнал, показывающий, какой именно элемент конструкции мишень считает недопустимым.
Многоходовые атаки тоже оказались контринтуитивным приёмом. Дробление задачи на безобидные шаги на семантической защите только усиливает отказ, потому что модель видит саму последовательность как приём. Работает другая многоходовость - смена механизма между ходами. Перелом наступает на втором-третьем ходу, когда частичный ответ становится полным.

Техническая боль настигла там, где я её не ждал. Бюджет токенов, который я назначил «разумным», оказался слишком мал для рассуждающих моделей, и все ходы обрывались на середине. Время ответа мишени превращало калибровку харнесса в часы ожидания. Исчерпание ключа чуть не похоронило волну, потому что первая версия не различала виды сбоев и продолжала жечь задачи на не заправленном openrouter.

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

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

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

Ну а на грейсвоне вышло новое соревнование, на которое стало теперь интересно потратить ещё денег

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

Новое исследование Rouxii: Exploiting Honeypots with Deception-Aware AI Pentesters говорит немного иначе.

Как ИИ научился видеть ловушки

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

Результаты проверки на 1,5 тысячах отчетов интересные:

Точность поиска ханипота агентом выросла с 19% до 97%.

В сегменте промышленных систем скачок оказался еще резче: с 11% до 97%.

При этом на реальные боевые сервисы агент почти не реагировал ошибочно - всего 0,7% ложных срабатываний.

Обычные инструменты (например, PentestGPT или HackingBuddy) без таких инструкций остаются слепыми. И тут правильно опять же дополнить, что дело не в слабости самой модели, а в том, как устроена харнесс, который не проверяет гипотезы на предмет обмана.

Когда ловушка начинает работать против защитников

Самое интересное начинается после того, как ИИ обнаружил ловушку. Для него это не конец атаки, а возможность взломать саму систему обмана.

Пример с GasPot. Распознав эту ловушку, агент не просто обходит её, а обращает против оператора. Поскольку ханипот принимает команды без проверки паролей или сессий, ИИ отправляет поддельные данные и начинает тихо искажать показатели ханипота. Защита продолжает работать, но анализирует мусор, который атакующий агент подсовывает ей изнутри.

Пример с Conpot (промышленные протоколы). Агент отправляет специальный пакет с ложным размером данных и сразу разрывает соединение. В итоге ловушка зависает в бесконечном ожидании ответа и перестает реагировать на другие запросы. Сеть при этом отвечает, что всё в порядке, и системы мониторинга докладывают, что сервис «жив». На деле она уже мертва и ничего не собирает, но защитники об этом не знают.
 
Эффективность любой ловушки держится на одном главном условии: атакующий не должен знать о ней. Как только это условие исчезает, ханипот перестает быть защитой. Он превращается в оружие против самих защитников.

Также дополнительно опубликован код, который можно попробовать испытать самостоятельно.

Сделайте репосты, ставьте реакции там, колокольчик. Собрать такую штуку сложно было всё-таки...

Прикольно https://habr.com/ru/companies/pt/articles/1084780/

Мало думал про графы раньше, но благодаря этому выступлению стал думать чаще и даже в безопасности ии это очень дельный подход