Тестирование AI-агента BnLAB на устойчивость к атакам

С чего всё началось

К нам обратился сервис, который помогает бизнесу оценить готовность к внедрению ИИ. Пользователь проходит интерактивную анкету, а на выходе получает числовой индекс готовности, карту рисков и дорожную карту. Звучит безобидно. Но как только продукт принимает пользовательский ввод, считает на его основе значимую метрику и под капотом обращается к языковой модели, у него появляется сразу несколько поверхностей атаки. Логика расчёта, обработка персональных данных и сам LLM-слой. Мы прошли по всем трём.

Что насторожило

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

Что нашли

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

Управляемость ключевой метрики. Индекс готовности задаётся положением слайдеров, а не качеством ответов. Оценка перестаёт быть объективной.

Отсутствие проверки на противоречия. Мы намеренно заложили взаимоисключающие вводные, выбрав одну сферу деятельности и описав в задаче совсем другую. Система не заметила конфликта, а склеила противоречие в единую сущность и начала давать рекомендации по требованиям, которые к реальному клиенту могли вообще не относиться. Валидации входных данных на непротиворечивость нет.

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

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

Потенциальный доступ к чужим операциям. Мы выявили признаки того, что при определённых условиях возможны действия от имени другого пользователя, вплоть до работы с чужим результатом и его отправки. Детали мы передали клиенту в закрытом порядке и не публикуем. На повторной проверке проблема воспроизвелась снова, то есть на момент ретеста корневая причина оставалась незакрытой.

Где была дыра в соответствии закону

Отдельный пласт находок касается не кода, а 152-ФЗ, и для российского сервиса это критично.

Трансграничная передача данных. Если обработка идёт через зарубежного провайдера языковой модели, это трансграничная передача персональных данных по статье 12 152-ФЗ. Закон требует прямо указать в политике страну и компанию-получателя и взять отдельное согласие именно на передачу за рубеж, а не общим флажком. В текущей политике этого нет. Радикальный способ снять весь пласт рисков, перейти на провайдера, который держит данные внутри страны.

Недоказуемость согласия. Согласие по 152-ФЗ принимается простым флажком. При проверке регулятора или жалобе пользователя сервис не сможет доказать факт получения согласия, потому что нет привязки к времени, адресу, устройству и версии документа, с которой согласился пользователь. Согласие надо фиксировать вместе с этими метаданными.

Что забрать себе

Этот кейс хорошо показывает, что безопасность продукта это не только дыры в коде. Здесь самым дорогим оказалось не проникновение извне, а то, что ключевую метрику можно накрутить через интерфейс, что система не проверяет вводные на противоречия и что формальное согласие пользователя юридически недоказуемо. Если у вас есть продукт, который считает значимый результат на основе пользовательского ввода, задайте себе три вопроса. Можно ли получить нужный результат, минуя честные ответы. Что произойдёт, если на вход подать противоречивые или мусорные данные. И сможете ли вы доказать в споре, что пользователь действительно дал согласие.

Важная оговорка

В рамках этого этапа активное эксплуатирование LLM-слоя не проводилось. Целенаправленные промт-инъекции и стресс-тест ограничений это отдельный прогон, который мы выделяем в самостоятельную работу. Всё, что описано выше, получено в рамках согласованных границ и без действий, способных навредить сервису или его пользователям.