Red-teaming your own agent

Red-teaming агента — это не «покидать в него джейлбрейки и посмотреть». Продуктивный процесс начинается с модели угроз, которая опирается на всё, что вы уже разобрали в курсе. Опишите активы (какие данные и действия ценны), доверительные границы (откуда приходит недоверенный вход), возможности агента (инструменты, токены, сеть) и цели вероятного атакующего. Из этого рождаются гипотезы: «через косвенную инъекцию в загруженном PDF атакующий пытается заставить агента отправить содержимое базы на внешний адрес».

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

Важная этическая и практическая рамка: это тестирование СВОЕГО агента в контролируемой среде ради его укрепления. Цель — найти и закрыть дыры раньше атакующего, а не создавать работающее оружие. Поэтому находки описываются как классы уязвимостей и защитные требования, а не как готовые к копированию пейлоады; репозиторий тест-кейсов держат в приватном контуре с ограниченным доступом.

Из модели угроз вырастает корпус тест-кейсов — набор проверок, каждая из которых кодирует одно защитное требование. Полезно раскладывать корпус по категориям OWASP LLM Top 10: prompt injection (прямой и косвенный), раскрытие чувствительных данных, excessive agency, отравление данных/цепочки, небезопасная обработка вывода. Для каждой категории — несколько сценариев под конкретную архитектуру вашего агента.

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

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

Ручной red-teaming не масштабируется: пространство атак огромно, а модели и промпты меняются на каждом релизе. Поэтому проверки автоматизируют. Есть открытые фреймворки, задающие методологию и наборы проб: garak от NVIDIA сканирует LLM на известные слабости, Microsoft PyRIT — фреймворк для автоматизированной оценки рисков GenAI, есть и другие (например, promptfoo для evals и red-teaming в пайплайне). Ценность не в «готовых эксплойтах», а в систематическом покрытии и повторяемости.

Отдельный приём — автоматизированный/«агентный» red-teaming: одна модель-атакующий генерирует вариации атак против вашего агента, а детерминированный оценщик фиксирует, пробита ли защита. Это расширяет покрытие за пределы того, что человек напишет вручную, и помогает находить целые семейства обходов, а не единичные строки.

Важно держать оценку честной. Судьёй «пробита ли защита» по возможности должен быть детерминированный код (сработал ли запрещённый вызов, ушёл ли пакет наружу), а не другая LLM, которую саму можно ввести в заблуждение; LLM-судья допустим для нечётких критериев, но с осторожностью. И запускать всё это надо в изолированной песочнице с фиктивными секретами и подставными внешними адресами, чтобы тесты сами не стали каналом утечки.

Разовый аудит устаревает мгновенно: новая версия модели, новый инструмент, новый MCP-сервер или правка промпта могут открыть старую дыру. Поэтому корпус adversarial-тестов встраивают в CI и прогоняют на каждое изменение агента — как обычные тесты, только про безопасность. Падение security-теста блокирует релиз так же, как падение функционального.

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

Замкните цикл с остальным курсом. Red-teaming не заменяет архитектурную защиту — он проверяет её: разорвана ли нога триады, держит ли скоуп токена, срабатывает ли approval gate, ловит ли мониторинг. Зрелая команда фиксирует не «мы неуязвимы», а измеренный остаточный риск и покрытие, и планомерно его снижает. Такой непрерывный, приоритизированный, автоматизированный red-teaming и есть практический способ убедиться, что защиты из предыдущих уроков реально работают, а не существуют только на бумаге.