В августе на конференции OFFZONE выступили два практикующих специалиста по безопасности — Владислав Бэк, занимающийся реагированием на инциденты и багхантингом на российских платформах, и Даниил Шушаков, пентестер компании «Инфосистемы Джет», регулярно попадающий в топы багбаунти-программ. Их доклад, опубликованный в текстовом виде, посвящён тому, как использовать ИИ-агентов для поиска уязвимостей так, чтобы получать валидные находки, а не бесконечный поток ложных срабатываний. Авторы подчёркивают, что за последние полгода плотной работы с агентными связками на российских площадках они собрали коллекцию типовых граблей, на которые наступает почти каждый, кто пытается делегировать поиск багов искусственному интеллекту. Речь идёт о семи стоп-факторах, от самых простых до наиболее болезненных, и о методах борьбы с каждым из них.

Первый и самый распространённый стоп-фактор — галлюцинации и фабрикация. Он складывается из трёх взаимосвязанных проблем: выдуманные артефакты, когда модель дописывает несуществующие уязвимости и целые концепции, чтобы отчёт выглядел солиднее; инфляция критичности, при которой находка на пустом месте превращается в CRITICAL с CVSS 10.0; и отсутствие самовалидации, когда агент не перепроверяет себя и выдаёт предположение как доказанный факт. Авторы отмечают, что звучит это эпично, но по факту за таким отчётом ничего не стоит. Решение они видят в трёх мерах: дать агенту реально выполнять команды в изолированной виртуалке или через аккуратно собранные MCP-контейнеры, чтобы он проверял, а не фантазировал; обязательно перепроверять находки перед финальным отчётом через Burp или curl, убеждаясь, что реакция именно та; и шаблонизировать отчёт, чтобы при отсутствии конкретных фактов агент упирался в стену и сам признавал отсутствие доказательств. Живой пример из практики: ИИ находит time-based SQL-инъекцию по задержке ответа, хотя на деле инъекции нет — просто эндпоинт сам по себе отвечает медленно, и задержка совпала с нагрузкой.

Второй стоп-фактор связан уже не с моделью, а с самим исследователем, который не валидирует находку. Причин несколько: слепое доверие к красивой полной цепочке, которую выдаёт ИИ-хантер, спешка на ивентах, когда нужно сдать как можно больше отчётов и обогнать конкурентов, близкая к нулю цена ошибки для новичка, которому максимум понизят уровень сигнала, и банальная нехватка навыков для перепроверки. Авторы формулируют жёсткое правило: не понимаешь находку — не отправляй. Если непонятно, что нашёл агент, нужно сначала довести расследование до конца самостоятельно, разобраться, доизучить и воспроизвести поведение. Дополнительно они советуют определять правила перепроверки для каждого типа уязвимости — инъекции, SSRF, доступ и авторизация, XSS, раскрытие информации, файловые загрузки — и отдельное правило на сам воркфлоу верификации. Даже если отчёт сдан в спешке, всегда можно вернуться и доресёрчить детали в комментариях, сделав находку полезнее для вендора.

Третий стоп-фактор — непонимание реальной модели угроз. Агенту может казаться, что он нашёл классную багу, хотя на деле это не бага вовсе. Авторы выделяют три тезиса: информация не равна уязвимости, спекулятивные цепочки подменяют доказательства, и отсутствует бизнес-контекст. Хрестоматийный пример — заголовок X-Powered-By: PHP/8.1, из которого агент на голубом глазу выстраивает цепочку до полной компрометации периметра: злоумышленник знает про PHP, может гуглить CVE, значит возможен RCE, значит бизнес уничтожен. Каждое звено здесь — допущение, а не доказательство. Другой пример из практики: агент считает взаимодействие с чужим товаром на маркетплейсе уязвимостью, хотя по бизнес-логике так и задумано. Решение — давать агенту контекст приложения, описывая не просто «маркетплейс», а конкретную модель с легитимными сценариями, и запускать второго агента на опровержение находок, чтобы снизить количество фальшивых срабатываний.

Контекст проблемы шире отдельного доклада: ИИ в багхантинге перестал быть экзотикой, и сегодня агент помогает искать уязвимости почти у всех. Вопрос давно не в том, пользоваться им или нет, а в том, как пользоваться так, чтобы это приносило валидные находки. На российских багбаунти-площадках, таких как Standoff 365 Bug Bounty и аналогичные программы, растёт число отчётов, сгенерированных с помощью ИИ, и площадки вынуждены адаптировать модерацию. Зарубежные исследователи фиксируют похожие тренды: агенты на базе больших языковых моделей всё чаще применяются для разведки и первичного анализа, но требуют человеческого контроля на этапе верификации. Отрасль постепенно приходит к пониманию, что ИИ — это усилитель исследователя, а не его замена, и что качество отчёта важнее его количества.

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

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