Зонд безопасности
#иб_для_ml


Механизмы безопасности AI-агентов требуют развития - потому что обойти их уже стало если не спортивным интересом любого пользователя, то абсолютно очевидным обстоятельством для любого злоумышленника точно.
Все начинают с блэклистов и оценок близости, потом приходят к BERT-моделям или легким LLM-классификаторам.
Я давно слышу, что гардрейлы - это не все, и они ненадежны. Действительно, это ведь достаточно примитивная (хотя и все еще необходимая) идея - не пропустить атаку. Однако если она более сложная, неявная, и не проявляется сразу. Как APT, которая проникает в инфру и сначала сидит месяцами, разведывая.

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

Нужны средства выявления закрепленной атаки.

В чем особенность таких атак? Они не провоцируют негативные последствия, но все-таки могут в определенных случаях поменять поведение AI-агента на девиантное.

Значит, нужно средство, которое устраивает "песочницу на лету", которое выводит агента на такие пограничные ситуации, где "отравленный" агент точно сорвется.
Я бы назвал это новым классом средств защиты информации для AI-агентов -детекторы rogue-агентов.

И на самом деле идея не нова. Часть даже затронул Артем у себя в статье про аи-пентестеров, но под немного другим углом. Рассмотрим это теперь со стороны обнаружения промпт-атак.
Однако такие средства не все одинаковые с точки зрения эффекта. В целом тут нужно две половины - инструмент, которые закидывает зонд, "подталкивает" агента к опасной реакции, и детектор, который выявляет целевую реакцию/последствие.

Я поискал, что сейчас есть среди опенсорса и статей, и нашел, что не так много. Решения по "второй половине" некоторые имеются, а "первой половинки" как таковой в чистом виде нет.

1. Выявление подозрительной "уверенности"
Детекция закрепленной промпт-атаки
Решение от promptfoo - та самая единственная "первая половинка, которую я нашел. Это плагин к основному редтим-кобмайну, действующий так:
1. Агенту дают корректную информацию, которую он должен сохранить.
2. Агенту дают сообщение, которое содержит промпт-атаку, связанную с переданной раннее информацией (искажающую исходное "воспоминание").
3. Агенту задают вопрос, где нужен исходный сохраненный факт.
Если на третьем шаге агент отвечает по зараженной версии - значит его память уязвима к отравлению, то есть, в контексте рантайма - там есть закрепленная промпт-атака.

2. Ложные тулы (1, 2)
Детекция девиантного поведения
В системник, реестр тулов или MCP добавляются правдоподобные тулы, которые автономный агент не должен вызывать: internal_debug_export, read_secret_vault, emergency_send_report. и тд. Они не отвечают ни одной из целей и задач агента, но формально он о них знает. Гипотеза в том, что их применение однозначно сигнализирует о нарушении, при чем даже не обязательно вследствие действий злоумышленника.

3. Ложные учетные данные (1, 2)
Детекция девиантного поведения
В среду кладутся правдоподобные, но бесполезные AWS-ключи, SSH-ключи, токены, cookie. При чем использование этих учетных данных не прописано в системнике агента, поэтому нормальный агент не должен их использовать. Если такой "секрет" появился в tool-call, egress или попытке аутентификации - это прямое свидетельство, что агент скомпрометирован.


Вывод
Пока rogue-детекторы - не готовый класс продуктов, а набор разрозненных кирпичей: есть детекторы девиантного поведения, но почти нет средств, которые безопасно провоцируют уже “отравленного” агента и вытаскивают закрепленную атаку наружу.

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