Голая модель не умеет в security: как собрать харнесс, который реально тестирует ИИ на уязвимости

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

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

Почему готовые комбайны не подошли

Первая мысль при сборке системы — взять что-то тяжеловесное вроде OpenClaw или другой мультиагентный фреймворк. На практике такие решения быстро упираются в потолок.

Проблема в трёх вещах:

• избыточные абстракции и запутанные графы взаимодействий между агентами;
• сжигание токенов на координацию — иногда пять агентов созваниваются между собой ради одного curl-запроса;
• утечки состояния между шагами, из-за которых воспроизводимость результата падает почти до нуля.

Для прикладной безопасности это фатально: если агент не может гарантированно повторить один и тот же сценарий атаки дважды, результатам просто нельзя доверять. В академических статьях техника «пробивает защиту на 99%» ровно до момента, пока не запускаешь код за пределами авторского ноутбука.

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

Почему в качестве модели взяли DeepSeek, а не флагман

Выбор модели для харнесса — deepseek-v4-flash, апрельская и июльская версии. На первый взгляд странно: зачем ставить не самую мощную модель в основу security-системы?

Ответ — в двух практических критериях:

1. Модель хорошо работает в агентном режиме — держит контекст задачи и корректно вызывает инструменты по цепочке шагов.
2. До недавнего 12-кратного роста цен модель была на порядок дешевле аналогов, а на OpenRouter более бюджетная версия всё ещё доступна.

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

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

Как устроены четыре слоя харнесса

Система строится вокруг трёх взаимосвязанных контуров и отдельного слоя исполнения кода.

Управляющий слой. Чтобы агент не блуждал в галлюцинациях прошлой сессии, его посадили на жёсткий поводок из ранбуков (пошаговых сценариев), скиллов и планов, которые лежат в обычном git-репозитории. Условная структура выглядит так:

harness/
  runbooks/
    prompt-injection-check.md
    memory-poisoning-scan.md
  skills/
    scanner-adapter.py
    triage-adapter.py
  state/
    session-2026-08-22.json

Агент заходит в задачу, читает актуальные правила из runbooks, забирает пошаговые команды и сверяет состояние, которое вычисляется прямо из файлов на диске. Никакой скрытой логики — любой шаг прозрачен, а ошибку можно откатить обычным git revert.

Слой сбора данных. Под капотом работает «сканер» публикаций — набор запросов, которые непрерывно опрашивают более тридцати внешних источников: блоги, новостные ленты, базы уязвимостей. Все находки скрипт складывает на диск в виде дампов с жёсткой привязкой по времени — так система сразу видит, какие данные свежие, а какие уже устарели.

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

Слой исполнения. Изолированная среда с командной строкой и адаптерами к профильным инструментам безопасности:

• garak — сканер уязвимостей для языковых моделей;
• PyRIT — фреймворк для red-teaming ИИ-систем от Microsoft;
• promptfoo — тестирование промптов и оценка ответов моделей;
• fickling — анализ небезопасной десериализации pickle-файлов;
• modelscan — сканирование ML-моделей на вредоносный код;
• presidio — детекция и маскирование персональных данных.

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

Файловая система вместо памяти модели

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

Это значит:

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

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

Где это ломается

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

Второе узкое место — зависимость от цен на инференс. Резкий рост стоимости токенов у выбранной модели (тот самый 12-кратный скачок) может в одночасье сломать экономику всей системы, если харнесс не спроектирован с возможностью быстро переключиться на альтернативную модель через OpenRouter или аналогичный роутер.

Что попробовать дальше

Если вы собираете похожий харнесс для своего домена — не обязательно security, — начните с трёх вещей: зафиксируйте состояние в git с самого первого дня, разделите сбор данных и анализ на отдельные слои с явной привязкой по времени, и не гонитесь за самой дорогой моделью, пока не убедитесь, что обвязка вокруг неё держит воспроизводимость каждого шага.

FAQ

Что такое харнесс в контексте ИИ-агентов

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

Почему выбрали Hermes, а не OpenClaw

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

Зачем использовать более слабую модель вроде DeepSeek

DeepSeek-v4-flash хорошо работает в агентном режиме и до недавнего роста цен был значительно дешевле аналогов. Для системы с постоянными циклами сбора и анализа данных это критично.

Какие инструменты входят в слой исполнения

garak, PyRIT, promptfoo, fickling, modelscan, presidio и другие открытые инструменты для сканирования уязвимостей моделей и данных.

Почему состояние хранится в файлах, а не в контексте модели

Файловая система — единственный источник правды, который не деградирует по мере роста истории. Это обеспечивает воспроизводимость и защищает от галлюцинаций на основе устаревшего контекста.

Источники

• Habr ML: Тот самый харнесс, который мы заслужили в эпоху, когда безопасность ИИ уже не диковинка