Пентест AI: тестирование чат-бота до запуска

Коротко. Тестирование безопасности чат-бота — это проверка, при которой специалист с письменного разрешения владельца пытается заставить бота сделать то, чего он делать не должен: раскрыть системные инструкции и внутренние документы, выдать чужие персональные данные, выполнить действие в CRM или почте по команде из недоверенного текста, дать клиенту ложное обещание. Методическая основа — OWASP Top 10 for LLM Applications (десять классов рисков для приложений на больших языковых моделях) и база знаний MITRE ATLAS о тактиках атак на системы ИИ. Классический пентест сайта AI-проверку не заменяет: уязвимость живёт не только в коде, но и в том, как модель обращается с данными, правами и инструментами. Результат — отчёт с воспроизводимыми сценариями, оценкой последствий и списком исправлений до запуска.

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

Чем пентест AI-системы отличается от обычного пентеста

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

Отсюда три отличия:

• Недетерминированность. Один и тот же запрос может не сработать четыре раза и сработать на пятый. Поэтому каждый сценарий повторяют многократно и фиксируют не «прошло или не прошло», а устойчивость защиты.
• Атака через смысл, а не через синтаксис. Опасный ввод выглядит как обычный текст: сообщение клиента, PDF, карточка товара, страница сайта, которую бот читает по ссылке.
• Последствия зависят от прав. Бот, который отвечает по публичному FAQ, и агент, который создаёт заявки и пишет письма, — разные уровни риска. Проверяется вся цепочка: модель, база знаний, инструменты, права учётных записей, фильтры и журналы.

Тестирование безопасности чат-бота: что проверяют по OWASP Top 10 for LLM

Проект OWASP ведёт отдельный список рисков для приложений на языковых моделях; на момент подготовки статьи актуальна редакция 2025 года. Ниже — как каждый пункт выглядит применительно к чат-боту.

Top 10 — карта приоритетов, а не исчерпывающая методика: самые опасные находки обычно лежат на стыке нескольких пунктов, например инъекция плюс избыточные полномочия. Почему пункт о дезинформации — это не только вопрос качества, разобрано в статье о галлюцинациях ИИ в бизнес-процессах.

MITRE ATLAS: как думает атакующий

Определение. MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) — открытая база знаний о тактиках и техниках атак на системы искусственного интеллекта, построенная по образцу матрицы MITRE ATT&CK.

Если OWASP отвечает на вопрос «какие классы уязвимостей бывают», то ATLAS — «как атакующий идёт от разведки к результату». Для пентестера это способ выстроить сценарий цепочкой: разведка (какая модель, какие инструменты, что лежит в базе знаний), первичный доступ через пользовательский ввод, выполнение, закрепление в памяти или базе знаний, извлечение данных, воздействие на бизнес. В отчёте удобно ссылаться на идентификаторы техник ATLAS: команде защиты проще сопоставить находки с мерами и с общей моделью угроз компании.

Для руководителя смысл простой: проверка по ATLAS показывает не отдельную «забавную» уязвимость, а путь, по которому посторонний человек может дойти от окна чата до ваших данных.

Как проходит пентест AI-системы: этапы

1. Шаг 1. Согласование границ. Письменное разрешение, перечень каналов, моделей и интеграций, окно тестирования, запрещённые действия (например, реальные письма клиентам), контакт для экстренной остановки.
2. Шаг 2. Модель угроз. Какие данные доступны боту, какие действия он может совершать, кто пользователи, откуда поступает недоверенный контент. Здесь же определяют, что считать критичной находкой.
3. Шаг 3. Разведка. Поведение бота в штатных сценариях, границы тематики, реакция на ошибки, какие источники он цитирует и какие инструменты вызывает.
4. Шаг 4. Ручное тестирование по OWASP и ATLAS. Прямые и косвенные инъекции, извлечение инструкций, обход ролей, провокация действий, проверка фильтров на входе и выходе. Автоматические наборы проверок ускоряют работу, но не заменяют ручную: опасные сценарии завязаны на бизнес-логику конкретного бота.
5. Шаг 5. Проверка классической части. API, авторизация, хранение истории диалогов, журналирование, секреты в конфигурации.
6. Шаг 6. Отчёт и разбор с командой. Воспроизводимые сценарии, оценка последствий, приоритеты исправлений.
7. Шаг 7. Повторная проверка. После исправлений те же сценарии прогоняют снова — с учётом недетерминированности, многократно.

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

Чек-лист: что подготовить к тестированию

• Описание сценариев бота: кому отвечает, по каким темам, что ему запрещено
• Список источников данных: база знаний, CRM, документы, сайты, которые бот читает
• Перечень инструментов и действий агента с правами каждой учётной записи
• Тестовые учётные записи для каждой роли пользователя
• Копия базы знаний без реальных персональных данных или согласованный порядок работы с ними
• Системный промпт и настройки фильтров для проверки «серым ящиком»
• Установленные лимиты запросов и бюджета API
• Доступ к журналам диалогов и вызовов инструментов
• Контакт ответственного и порядок экстренного отключения бота
• Письменное разрешение на тестирование от владельца системы

Что должно быть в отчёте

Отчёт по AI-пентесту читается так же, как отчёт по обычному пентесту (см. как читать отчёт по пентесту), но с особенностями:

• для каждой находки — сценарий воспроизведения и доля успешных попыток из серии повторов;
• привязка к категории OWASP LLM и технике MITRE ATLAS;
• бизнес-последствие простым языком: «посторонний получает выдержки из договоров», а не просто «LLM02»;
• рекомендация на уровне архитектуры (права, разделение данных, подтверждение действий), а не только «усилить промпт»;
• перечень того, что проверено и не подтвердилось, — чтобы понимать покрытие.

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

Когда проводить и сколько стоит

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

У Viviar тестирование безопасности AI входит в «Пакет безопасного AI» — от 20 300 BYN за один сценарий с защитой данных и модели и от 8 700 BYN в месяц за сопровождение; для 2–3 сценариев — от 43 600 BYN и от 17 400 BYN в месяц. Если нужно одновременно оценить защищённость инфраструктуры и готовность к AI, есть «AI и безопасность: полный аудит» от 26 200 BYN. Цены указаны для минимальной конфигурации; итог зависит от числа каналов, интеграций и прав агента. Подробнее о направлении — на странице услуг кибербезопасности.

Частые вопросы

Чем тестирование безопасности чат-бота отличается от обычного пентеста?

Обычный пентест ищет ошибки в коде, конфигурации и авторизации. Тестирование чат-бота добавляет проверку языковой модели: выполняет ли она инструкции из недоверенного текста, раскрывает ли внутренние данные и системный промпт, может ли совершить лишнее действие. Нужны обе части, потому что у бота есть и веб-интерфейс, и модель с доступом к данным.

Что такое OWASP Top 10 for LLM Applications?

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

Можно ли тестировать бота, который уже работает с клиентами?

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

Достаточно ли хорошо написанного системного промпта для защиты?

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

Как часто повторять проверку AI-системы?

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

Вывод

Тестирование безопасности чат-бота до запуска проверяет не «умность» модели, а то, что произойдёт, когда кто-то попытается использовать её против вас — через сообщение, документ или ссылку. OWASP Top 10 for LLM Applications даёт перечень рисков, MITRE ATLAS — логику атаки, а ручной пентест отвечает на вопрос, выдержит ли именно ваша архитектура. Если бот готовится к запуску, расскажите о сценарии: определим границы проверки и что тестировать в первую очередь.

Источники: OWASP Top 10 for LLM Applications, редакция 2025 (genai.owasp.org); MITRE ATLAS (atlas.mitre.org); NIST AI 100-1 «Artificial Intelligence Risk Management Framework (AI RMF 1.0)», 2023 (nist.gov); практика Viviar.