Как эволюция моделей изменила ИИ-агентов безопасности на платформе H1

По мере того как модели быстро преодолевали пороги возможностей, инфраструктура, выстроенная вокруг ИИ-агентов на платформе H1, претерпела значительные изменения. Каждый раз, когда выпускалась более новая и интеллектуальная LLM-модель, нам приходилось удалять слои кода, которые существовали для компенсации ограничений предыдущего поколения. В этой статье описывается, как наши агентские системы стремились к архитектурной простоте и как наш подход к защитным механизмам менялся с каждым поколением.

Что изменилось за последние 18 месяцев

Мы проанализировали историю итераций подмножества ИИ-агентов, которые HackerOne использует для анализа кода и тестирования безопасности. Эти агенты предназначены для проверки запросов на включение (pull requests) на наличие уязвимостей, проверки отчетов об уязвимостях, представленных исследователями, анализа того, являются ли уязвимые зависимости действительно доступными в коде клиента, и аудита кодовых баз на наличие эксплуатируемых дефектов. Они работают с кодом клиентов в рамках настроенных клиентами областей, в промышленном масштабе, при этом результаты публикуются в запросах на включение, в программы аудита безопасности кода или используются для проведения анализа первопричин уязвимостей.

Мы отслеживали различные параметры в репозиториях, используемых для поддержки агентов: выбор модели (какая версия модели и почему она была изменена), формат вывода (как агент возвращает структурированные результаты), поток управления (как инфраструктура ограничивает действия модели) и защитные механизмы (что снижает риск попадания нежелательных результатов к клиентам).

Период времени, охватываемый этим документом, знаменует собой то, что мы называем нашей «эрой современных ИИ-инструментов»: с марта 2025 года по август 2026 года. Это время, когда мы начали активно сворачивать модели, созданные собственными силами, такие как Security Hotspots, построенные на базе CodeBERT и обученные при участии группы клиентов PullRequest с открытым исходным кодом, и преобразовали наши монолитные ИИ-конвейеры в иерархические оркестрации, где несколько агентов осуществляют полную навигацию по поверхности кодовой базы в последовательных рабочих процессах. Сегодня ИИ-агенты, которые мы проектируем и создаем, основаны на ключевых функциях реального непрерывного управления воздействием угроз (CTEM) и оцениваются на основе того, насколько эффективно и последовательно они выполняют свою работу.

HackerOne не использует и не разрешает использование конфиденциальных материалов исследователей или данных об уязвимостях клиентов для обучения, дообучения или иного улучшения генеративных ИИ-моделей.

Модели не развивались в одном направлении

Парк агентов не обновлялся единообразно. Разные агенты развивались в разных направлениях в зависимости от специфики их задач.

В ходе нашего тестирования один из агентов рабочего процесса проверки для анализа безопасности кода показал прирост производительности при переходе от моделей с более высокими возможностями и более высокой задержкой, таких как Opus, к сбалансированным и более быстрым моделям, таким как Sonnet. Произошло следующее: результаты работы агентов, ориентированных на принятие решений, с которыми он взаимодействовал — его «коллег по команде» — стали более стабильно точными, в то время как параллельно развивались новые поколения сбалансированных моделей. Это означало, что агент мог быстрее выполнять свою задачу по вынесению обоснованного вердикта без ущерба для точности. В нашем внутреннем тестировании более тяжелые модели с высокими возможностями были сопоставимы по точности в этой задаче, но добавляли заметную задержку. Для нашего продукта H1 Code это было особенно важно; каждая лишняя секунда работы проверки CI/CD конвейера ухудшает пользовательский опыт.

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

Несколько многоагентных рабочих процессов, которые изначально использовали исключительно модели с более глубоким рассуждением на всех этапах, перешли на более быстрые, сбалансированные модели для задач широкого охвата (сканирование, исследование, сбор информации) и сохранили модели с глубоким рассуждением для задач, требующих принятия решений, таких как вынесение вердиктов и пути эскалации для клиентов. Например, в нашем тестировании весь рабочий процесс аудита кода показал прирост производительности, когда агент пакетного сканирования, используемый для разведывательных действий, где пропускная способность и скорость важнее глубины рассуждений, был переведен на более быстрые сбалансированные модели. Затем мы наблюдали постепенные улучшения в наших бенчмарках, коррелирующие с эволюцией Sonnet от 3.5 до 3.7 и 4.5.

К концу августа 2026 года большинство «задач широкого охвата» (например, сканирование, маршрутизация, исследование) в наших бенчмарках лучше всего выполнялись на сбалансированных, более быстрых моделях. «Задачи принятия решений» (верификация, окончательный вердикт, оркестрация) лучше выполнялись с моделями с более глубоким рассуждением.

Работа с передовыми кибер-ИИ-моделями

Важность делегирования задач моделям и эмпирические доказательства, которые мы начали наблюдать, усилились, когда мы начали работать с новым поколением передовых кибер-ИИ-моделей, таких как Mythos 5 через Project Glasswing от Anthropic и кибер-модели GPT через Daybreak Defense от OpenAI Network. Эти модели представили новые концепции, такие как композиционный риск: уязвимости, которые существуют не в одном коммите, а в том, как несколько безопасных по отдельности изменений взаимодействуют с кодовой базой, создавая сложные уязвимости с течением времени.

Наша работа с этими моделями привела к новым аспектам эффективности выполнения задач в наших системах анализа безопасного кода и наборах бенчмарков, по которым мы их оцениваем.

Например:

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

Агенты следовали схожей дуге форматов вывода

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

Этап 1: JSON в свободной форме (2025). Попросить модель ответить в формате JSON. Распарсить (если повезет). Обрабатывать некорректные ответы с помощью повторных попыток. Наш старейший агент поначалу работал именно так. В тот период значительная часть запусков завершалась неудачей без уведомления, потому что модель возвращала валидный JSON, который не соответствовал ожидаемой схеме. К сожалению, мы отлавливали это в производственных логах, а не на уровне API.

Этап 2: Принудительный структурированный вывод (конец 2025). Структурированный вывод на уровне API (принудительные вызовы инструментов или режим JSON-схемы) перенес валидацию из жесткого промптинга в коде на саму модель. Некорректные ответы стали явными ошибками API, а не скрытыми ошибками повреждения данных.

Этап 3: Вызов инструмента как канал вывода (2026). Наши самые зрелые агенты используют вызовы инструментов не для действий, а как типизированные порты вывода. Агент определяет инструменты с валидацией по схеме, единственная цель которых — выдавать структурированные результаты. Это называется контрактом вывода. Модель свободно исследует в рамках ограничений (читает файлы, ищет шаблоны через grep, перемещается по кодовой базе), а затем выдает результаты через эти типизированные каналы. Это отделяет исследование от отчетности: агенту не нужно удерживать весь свой анализ в одном ответе.

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

Вызов

За 18 месяцев наш парк агентов сменил четыре различных программных метода вызова моделей ИИ:

• Прямые вызовы API (начало 2025 г.). Непосредственный вызов модели.
• CLI-подпроцесс (середина 2025 г.). Этот метод просуществовал недолго, прежде чем мы заменили его полноценным SDK.
• Agent SDK (середина — конец 2025 г.). Его внедрили четыре наших основных агента. Один отказался от него всего через несколько недель; остальные перешли на другие решения в течение следующих шести месяцев.
• Графовый фреймворк + прямые вызовы моделей (с 2026 г. по настоящее время). Текущая конвергенция: графовый фреймворк исполнения отвечает за структуру рабочего процесса, прямые вызовы API — за вызов модели, а промежуточное ПО (middleware) — за защитные барьеры.

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

В 2026 году мы добавили уровень вызова, который маршрутизирует запросы к нескольким провайдерам во время выполнения. Некоторые семейства моделей поддерживают блоки «мышления» (thinking blocks) и кэширование промптов, другие — нет. Уровень фабрики абстрагирует эти различия, поэтому управляющий код выше не знает и не заботится о том, какая именно модель дала ответ.

Защитные барьеры становились строже по мере того, как модели становились умнее.

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

2025 г.: Неявное доверие. Последовательная обработка, отсутствие ограничений на количество итераций, повтор до успеха. Модель работала до завершения (или сбоя).

Начало 2026 г.: Мягкие бюджеты. Фиксированные лимиты на токены «мышления». Ограничения на количество итераций как крайняя мера. Они существовали для предотвращения бесконечных циклов, но не для формирования поведения.

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

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

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

Лучше модели, меньше архитектурных уровней.

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

Специализация агентов стала менее важной. Один из наших агентов изначально распределял работу по анализу между узкопрофильными специалистами (например, по уязвимостям инъекций, ошибкам аутентификации, неверным настройкам инфраструктуры и т. д.). На нашем внутреннем наборе тестов один агент-универсал с промптом на основе свойств начал превосходить систему распределения по специалистам. В конечном итоге мы удалили уровень специалистов — сотни строк кода оркестрации и маршрутизации. Уровень специалистов существовал лишь потому, что агенты, использующие ранние модели, не могли охватить все аспекты безопасности за один проход.

Поля для «лесов» (scaffolding) стали менее необходимыми. Один агент изначально требовал от модели вывода резюме рассуждений наряду с оценками, заставляя её «показывать ход мыслей» для улучшения качества вывода. В ходе наших оценок мы убрали эти поля, и агент стал выдавать лучшие результаты.

Это отличается от видимости покрытия. Агенты по-прежнему записывают, какой код они проверили, а какой пропустили. «Лесами», которые влияли на точность, было именно принудительное повествование.

Расширенное «мышление» стало менее необходимым (для некоторых задач). Один агент отключил расширенное мышление для пакетных заданий после того, как тесты показали, что оно потребляет время, не улучшая точность. Меньшие бюджеты на мышление или их отсутствие обеспечивали то же качество за долю времени.

Короче говоря, почти каждое крупное поколение моделей поглощало один уровень компенсирующей сложности. Специалисты становились универсалами. Многошаговые процессы — однократными вызовами. Структурированные рассуждения — структурированным выводом. Агенты становились проще.

Создание ИИ-агентов для безопасности.

Изменения моделей в разных поколениях вынуждают менять архитектуру. Каждое решение о составе мультиагентных систем, структуре вывода и выборе SDK имеет срок годности, измеряемый поколениями моделей. Избегайте проектирования «на века».

Двухуровневое разделение моделей (меньшая модель для охвата, модель рассуждения для принятия решений) остается стабильным в течение шести месяцев, что, по нашему опыту, является реалистичным пределом того, как долго живет дизайн системы, прежде чем его нужно пересматривать. Если агент выполняет и сканирование, и проверку — разные задачи, — назначайте для каждой разные модели и измеряйте результаты.

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

Посмотрите на это в действии.

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

• H1 Code выполняет проверки pull-request и CI/CD, предназначенные для выявления новых рисков до того, как они будут объединены с основным кодом.
• H1 Remediation превращает подтвержденные находки в стратегию исправления.
• H1 Code Security Audit проводит аудит с широким охватом, используя иерархическую оркестрацию агентов сканирования, исследования и проверки, которые работают от разведки до вынесения вердикта.

Хотите увидеть, что передовые кибер-ИИ-модели с архитектурой, созданной специально для них, могут обнаружить в вашей поверхности атаки? Ознакомьтесь с H1 Code Security Audit.