Разработчик программного обеспечения для ритейла

КЛИЕНТ

Разработчик программного обеспечения для розничной торговли. Объект работ — корпоративный AI-ассистент, построенный на специализированных экземплярах модели Claude. Заказчик не раскрывается в соответствии с соглашением о неразглашении.

ОТРАСЛЬ

Разработка программного обеспечения, розничная торговля.

ЗАДАЧА

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

• Вывести LLM за пределы предусмотренного сценария;
• Раскрыть внутренние инструкции модели;
• Получить информацию, недоступную пользователю штатным способом;
• Добиться обработки потенциально опасных инструкций;
• Использовать подключённые источники данных способом, не предусмотренным разработчиками.

ПРОБЛЕМАТИКА

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

Состав проектной команды «КРЕДО-С»: ведущий эксперт по кибербезопасности, ведущий специалист по анализу защищённости и руководитель проекта.

РЕШЕНИЕ

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

• direct prompt injection;
• indirect prompt injection;
• jailbreak;
• system prompt extraction;
• roleplay;
• context manipulation / context switching;
• task deflection;
• multi-turn attacks;
• token / encoding manipulation;
• попытки обхода реализованных guardrails.

РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ

Подтверждена практическая реализуемость части сценариев:

• Обход отдельных ограничений модели;
• Извлечение части системных инструкций;
• Получение информации вне предусмотренного контекста;
• Успешная prompt injection;
• Воздействие через содержимое RAG;
• Обход отдельных content- и security-контролей.

РЕКОМЕНДАЦИИ

• Усиление input/output filtering;
• Изменение system prompt и guardrails;
• Фильтрация и валидация источников RAG;
• Ограничение контекста, доступного модели;
• Дополнительные проверки перед выполнением чувствительных операций;
• Совершенствование журналирования и мониторинга;
• Архитектурные изменения в интеграционном слое, в том числе в практиках безопасной разработки;
• Повторное тестирование (retest) после устранения недостатков.

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Что такое AI Red Teaming?

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

Что означает режим grey box?

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

Какие сценарии атак проверяются?

В этом проекте — direct и indirect prompt injection, jailbreak, извлечение системных инструкций (system prompt extraction), roleplay, манипуляция и подмена контекста, task deflection, многоходовые атаки, манипуляции с токенами и кодировками, а также прямые попытки обхода реализованных guardrails. Использовалось сочетание ручного и автоматизированного тестирования.

Что подтвердилось на практике?

Обход отдельных ограничений модели, извлечение части системных инструкций, получение информации вне предусмотренного контекста, успешная prompt injection, воздействие через содержимое RAG и обход отдельных content- и security-контролей. По каждому пункту заказчик получил воспроизводимый сценарий.

Что делать после тестирования?

Усилить input/output filtering, изменить system prompt и guardrails, добавить фильтрацию и валидацию источников RAG, ограничить доступный модели контекст, ввести дополнительные проверки перед чувствительными операциями, доработать журналирование и мониторинг и изменить интеграционный слой — в том числе через практики безопасной разработки. После устранения проводится retest.

Другие проекты по безопасности ИИ: аудит безопасности LLM/RAG-решения · обезличивание персональных данных для LLM и RAG.