Positive Technologies представила LLM Firewall для ИИ-агентов

Positive Technologies 16 октября представила LLM Firewall — модуль для защиты приложений на основе больших языковых моделей. Он проверяет сообщения, которыми приложение обменивается с моделью, и помогает обнаруживать попытки перехватить управление ИИ-ассистентом или вывести через него закрытые данные. Решение уже включено в PT Application Firewall Cloud; появление в локальной версии PT AF PRO пока только анонсировано.

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

Что объявила Positive Technologies

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

Подключение предусмотрено через API, совместимый с OpenAI Chat Completions и Responses. Управление выполняется в PT AF: для разных ИИ-сервисов можно задавать собственные политики и выбирать мониторинг или блокировку. О запуске также сообщили CNews и SecurityLab. Эти публикации подтверждают анонс, но не заменяют независимое испытание заявленной защиты.

Почему опасный запрос не обязательно похож на взлом

Prompt injection, или внедрение инструкций в промпт, — попытка изменить поведение модели через обрабатываемый ею текст. Пользователь может прямо попросить бота игнорировать правила. Более сложный вариант — поместить инструкции в документ или веб-страницу, которые ассистент получил для анализа. Такой сценарий называют косвенной инъекцией.

Например, сотрудник просит помощника кратко пересказать коммерческое предложение. В документе находится посторонняя инструкция: включить в ответ сведения из другого, закрытого материала. Для человека это чужой текст внутри файла, а модель может принять его за указание к действию. Это условный пример риска, а не описание проведённого теста LLM Firewall.

OWASP выделяет prompt injection в отдельную категорию рисков и отмечает, что подключение поиска по документам или дообучение сами по себе не устраняют проблему. Поэтому вопрос касается не только публичного чата на сайте: внутренний помощник с доступом к базе знаний тоже обрабатывает содержимое, которому нельзя автоматически доверять.

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

Зачем проверять и запрос, и ответ

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

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

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

Фильтр сообщений не заменяет ограничения полномочий

ИИ-агент отличается от текстового помощника возможностью вызывать инструменты: искать документы, менять записи, отправлять сообщения. Если дать ему лишние права, ошибка интерпретации может превратиться в нежелательную операцию. О таком устройстве программ подробнее рассказано в заметке «Что такое AI-агент простыми словами».

OWASP описывает эту проблему как Excessive Agency — избыточные полномочия и автономность. Рекомендации включают минимальный набор инструментов, ограниченные права и подтверждение человеком действий с существенными последствиями. Проверять разрешение на операцию должна вызываемая система, а не только сама модель.

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

Поэтому LLM Firewall разумно оценивать как дополнительный слой проверки содержимого. Он не делает безопасным общий административный ключ, не исправляет права доступа к документам и не доказывает корректность каждого ответа. Базовые вопросы обращения с рабочими материалами разобраны в статье о безопасности ИИ для бизнеса.

Что проверить перед подключением

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

• Границы проверки. Какие обращения действительно идут через фильтр? Важно учесть фоновые задачи и другие способы вызова модели, а не только видимый веб-чат.
• Содержимое файлов. Как обрабатываются документы и результаты поиска? Поддержку нужных форматов и этап извлечения текста стоит уточнить отдельно.
• Обычные рабочие запросы. Нужны примеры допустимых сообщений, включая обсуждение безопасности. Упоминание атаки в учебном материале не равно попытке атаковать бота.
• Поведение при блокировке. Что увидит пользователь, сохранится ли задание и сможет ли сотрудник разобраться в причине остановки?
• Задержка и журналирование. Как проверка влияет на время ответа, какие сведения записываются в журнал и кто может их читать?

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

Что пока остаётся за рамками анонса

В найденных сообщениях о запуске нет независимых замеров доли обнаруженных атак, ложных срабатываний и добавленной задержки. Публичной цены нового модуля и точной даты выхода в PT AF PRO там также не указано. Эти параметры нужно выяснять для конкретного варианта подключения; переносить свойства облачного выпуска на локальный заранее нельзя.

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