Архитектура FlautGuard: многоуровневая защита языковых моделей от инъекций промптов

# FlautGuard: как мы построили многоуровневую защиту LLM

Защита языковой модели принципиально отличается от защиты обычного программного обеспечения. В веб-приложении строка текста остается просто данными, в то время как модель искусственного интеллекта воспринимает этот текст как потенциальную команду. Эта граница размывает понятия «данные» и «инструкция», открывая путь для атак типа prompt injection, утечек системных инструкций и вывода конфиденциальной информации.

В рамках развития инфраструктуры FlautFast отдел FlautSecurity столкнулся с необходимостью создать надежный барьер. Вместо попыток решить проблему одним универсальным фильтром, инженеры разработали FlautGuard — защитный слой с архитектурой «глубокой защиты» (defense in depth). Это решение не ставит все яйца в одну корзину, разделяя задачи на несколько независимых этапов.

Разделение задач: данные против модели

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

В результате была выстроена архитектура из двух независимых уровней:

1. .fsecurity — защищает статические и динамические данные инфраструктуры. Шифрует запросы, ответы, файлы и сессии с использованием отдельных ключей для каждого объекта. 2. FlautGuard — специализируется на защите самой модели от вредоносных воздействий через пользовательский ввод и выходные данные.

Архитектура четырех слоев защиты

FlautGuard размещен непосредственно между пользователем и ядром модели FlautFast. Каждый компонент архитектуры выполняет узкую задачу, минимизируя зависимость от ошибок одного модуля.

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

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

DetectIn: обнаружение попыток инъекции Этот модуль отвечает не на вопрос «кто пользователь», а на вопрос «пытается ли запрос изменить правила работы модели?». Простых списков запрещенных фраз недостаточно, так как современные атаки часто завуалированы или разбиты на части.

FlautGuard использует классификационные алгоритмы для определения вероятности prompt injection. Важно понимать, что данный этап не является окончательным вердиктом. Высокая чувствительность классификатора приводит к ложным срабатываниям (false positives), блокируя полезные запросы, в то время как слишком мягкий фильтр пропускает атаки.

ShieldIn: активация внутренних механизмов Если классификатор DetectIn допускает подозрительный запрос, срабатывает ShieldIn. Этот слой активизирует внутренние защитные механизмы модели, включая разработанный ранее SwitchNet. Механизм срабатывания защищенного пути активируется через криптографический ключ, что позволяет отделить конфигурацию защиты от обычных параметров модели.

Это означает, что даже при проходе через фильтры входной запрос обрабатывается с повышенными мерами предосторожности, снижая риск выполнения заложенных в промпт команд.

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

Этот этап использует: * NER (Named Entity Recognition): для поиска сущностей, представляющих конфиденциальные данные. * Регулярные выражения: для детерминированной проверки форматов (например, email, ID, номера).

Отказ от использования LLM для анализа ответов модели позволяет избежать циклических зависимостей и повышает скорость обработки.

Уроки разработки: почему одного фильтра недостаточно

История создания FlautGuard иллюстрирует эволюцию подхода к безопасности ИИ. Первая версия системы представляла собой простой pipeline: Пользователь → Классификатор → Модель. Такая архитектура создавала единую точку отказа: ошибка классификатора приводила к компрометации системы.

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

В текущей версии FlautGuard реализован принцип защиты в глубину. Ошибка одного компонента (например, пропуска атаки DetectIn) не гарантирует взлома системы, так как остальные уровни (ShieldIn и FilterOut) продолжают контролировать поток данных.

Результаты на реальном трафике

Тестирование проводилось в условиях эксплуатации с помощью бота @FlautBot. За три месяца система обработала более 45 000 запросов. Анализ включал обычные обращения, попытки инъекций, извлечения системных инструкций и adversarial input.

Классификатор DetectIn показал эффективность примерно 95% на тестовом наборе. Однако автор подчеркивает, что эта цифра не означает полного решения проблемы. Главное достижение заключается в том, что запросы, пропущенные первым фильтром, блокировались или обезвреживались последующими слоями защиты.

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

Заключение

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