LLM-файрвол: как защитить корпоративные ИИ-приложения

LLM-файрвол — это единая точка контроля между пользователями, внутренними сервисами и языковыми моделями, которая проверяет каждый запрос к модели и каждый её ответ: ищет промпт-инъекции и попытки джейлбрейка, вычищает персональные данные, пароли и ключи, а при угрозе предупреждает, маскирует, отправляет запрос в карантин или блокирует его. Он нужен, когда в компании десятки и сотни ИИ-приложений и агентов, а классические DLP и WAF не понимают смысла текстовых запросов. Но файрвол — один слой защиты, а не замена минимальным правам агентов, журналированию и проверке человеком рискованных действий.

Материал подготовлен AIrassvet 15 октября 2026 года по описанию запроса информации «Ростелекома» на систему контроля коммуникаций LLM-приложений (TAdviser, октябрь 2026 года) и по перечню рисков OWASP Top 10 for LLM Applications 2025. Он адресован ИТ-директорам, руководителям служб информационной безопасности и владельцам продуктов, у которых ИИ-ассистенты, чат-боты и агенты уже работают с корпоративными данными. Мы не тестировали коммерческие LLM-файрволы и не сравниваем вендоров: чек-лист требований и план внедрения — методика редакции. AIrassvet не аффилирован с «Ростелекомом», TAdviser и OWASP; раздел в конце статьи описывает услуги издателя.

Содержание

Кратко
Почему о LLM-файрволах заговорили сейчас
Что такое LLM-файрвол и чем он отличается от DLP и WAF
Как устроен LLM-файрвол
От каких рисков он защищает, а от каких нет
Чек-лист требований к LLM-файрволу
План внедрения по этапам
Как понять, что защита работает
Частые вопросы
Первоисточники и метод проверки

Кратко

Рост числа ИИ-приложений создаёт новую поверхность атаки. По оценке «Ростелекома», в его контуре работает не менее 1,5 тыс. решений на основе больших языковых моделей — от внутренних ассистентов до клиентских чат-ботов.
LLM-файрвол анализирует смысл, а не только сигнатуры. Он проверяет и входящий промпт, и сгенерированный ответ, потому что утечка может произойти в любую сторону.
Реакция не обязательно блокировка. Описанная в запросе «Ростелекома» система предусматривает предупреждение, маскирование данных, карантин и блокировку с отправкой карточки инцидента в SOC и SIEM.
Полной защиты от промпт-инъекций нет. OWASP прямо пишет, что надёжных методов предотвращения пока не известно, поэтому файрвол сочетают с минимальными правами и проверкой человеком.
Начинать стоит с инвентаризации и режима наблюдения, а не с жёсткой блокировки: сначала нужно увидеть реальный трафик и долю ложных срабатываний.

Почему о LLM-файрволах заговорили сейчас

В октябре 2026 года TAdviser сообщил, что «Ростелеком» изучает возможность создания «системы контроля коммуникаций LLM-приложений» и разместил запрос информации для поставщиков; заявки принимаются до 19 октября (TAdviser; новость также опубликована на Хабре 15.10.2026). Из описания технического задания следует:

система должна защищать от атак классов Prompt Injection и Jailbreak, от утечек персональных данных, коммерческой тайны и учётных записей через запросы к языковым моделям;
она встаёт в единую точку прохождения трафика между пользователями, внутренними сервисами, внешними языковыми моделями и базами знаний (RAG), а под мониторинг попадают и действия автономных ИИ-агентов;
проверка идёт «на лету»: анализируются входящие промпты и ответы модели, пресекаются попытки извлечь системные настройки и скрыто выгрузить закрытые данные наводящими вопросами;
контентный фильтр вычищает клиентские данные, коммерческую тайну, пароли, токены доступа и API-ключи;
софт должен входить в реестр Минцифры, а для тяжёлого анализа запросов в контуре предусмотрены серверы с ускорителями уровня NVIDIA H100 или отечественными аналогами.

Руководитель проектов блока информационной безопасности «Ростелекома» Екатерина Филиппова пояснила TAdviser, что базовый уровень защиты уже обеспечен, а компания пилотирует решения для дополнительного контроля LLM-сервисов. Эксперты в том же материале отмечают, что с новыми вызовами классические DLP и WAF уже не справляются, а Владислав Тушканов из «Лаборатории Касперского» называет основой безопасности многослойную защиту, в которой гардрейлы, например в рамках LLM-файрвола, — один из вариантов.

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

Что такое LLM-файрвол и чем он отличается от DLP и WAF

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

Гардрейлы (guardrails) — это правила и механизмы, которые ограничивают поведение модели: запрещённые темы, обязательный формат ответа, фильтры чувствительных данных. LLM-файрвол — один из способов применять гардрейлы централизованно, а не прописывать их в каждом приложении.

	DLP	WAF	LLM-файрвол
Что защищает	Каналы передачи данных: почта, USB, облака	Веб-приложения от атак через HTTP	Диалог с языковой моделью и действия агентов
Как распознаёт угрозу	Шаблоны и метки конфиденциальных данных	Сигнатуры и правила для HTTP-запросов	Смысл текста запроса и ответа, контекст диалога
Видит ли промпт-инъекцию	Нет	Как правило, нет: инъекция выглядит как обычный текст	Да, это его основная задача
Проверяет ли ответ модели	Только если ответ уходит по контролируемому каналу	Нет	Да
Типичная реакция	Блокировка передачи	Блокировка запроса	Предупреждение, маскирование, карантин, блокировка

Таблица — обобщение редакции по назначению классов решений, а не сравнение конкретных продуктов.

Как устроен LLM-файрвол

Схема ниже собрана по описанию запроса «Ростелекома» и рекомендациям OWASP. Это логика работы, а не архитектура конкретного продукта.

Единая точка входа. Все приложения и агенты обращаются к моделям только через шлюз: прямые ключи к внешним API у отделов отзываются.
Идентификация источника. Шлюз знает, какое приложение, какой пользователь и какой агент отправил запрос, — без этого нельзя ни применить политику, ни расследовать инцидент.
Проверка входящего запроса. Поиск признаков промпт-инъекции и джейлбрейка, попыток вытащить системный промпт, чувствительных данных: персональных данных, коммерческой тайны, паролей, токенов и ключей.
Проверка внешнего контента. Документы из базы знаний, веб-страницы и файлы, которые агент подмешивает в контекст, проверяются отдельно: именно через них приходит непрямая инъекция.
Проверка ответа модели. Ответ сверяется с политикой до того, как попадёт пользователю или в другую систему: не раскрывает ли он закрытые данные, соответствует ли ожидаемому формату.
Реакция по уровню риска. Предупредить пользователя, замаскировать фрагмент, поместить запрос в карантин для ручного разбора или заблокировать.
Журнал и инциденты. Каждое срабатывание пишется в журнал, а серьёзные — уходят карточкой инцидента в SOC и SIEM.

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

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

От каких рисков он защищает, а от каких нет

OWASP — открытое сообщество по безопасности приложений — ведёт перечень десяти главных рисков для приложений на основе LLM (OWASP Top 10 for LLM Applications 2025). Ниже — оценка редакции, какие из них закрывает шлюз, который видит запросы и ответы, а какие требуют других мер.

Риск OWASP 2025	Чем помогает LLM-файрвол	Что нужно помимо него
LLM01 Prompt Injection	Распознаёт часть прямых и непрямых инъекций, отделяет внешний контент	Минимальные права, проверка человеком рискованных действий, регулярные атаки на себя
LLM02 Sensitive Information Disclosure	Маскирует и блокирует чувствительные данные в запросах и ответах	Классификация данных, права доступа к базе знаний
LLM05 Improper Output Handling	Проверяет формат и содержание ответа до передачи дальше	Валидация ответа кодом в принимающей системе
LLM06 Excessive Agency	Видит и журналирует действия агентов	Ограничение инструментов и прав агента — это решается не фильтром
LLM07 System Prompt Leakage	Пресекает попытки извлечь системные настройки	Не хранить секреты в системном промпте
LLM10 Unbounded Consumption	Может ограничивать объём и частоту запросов	Лимиты бюджета у провайдера, мониторинг расходов
LLM03 Supply Chain, LLM04 Data and Model Poisoning	Почти не помогает	Проверка моделей, библиотек и данных для обучения

Главное ограничение сформулировано в самом OWASP: из-за вероятностной природы моделей неясно, существуют ли надёжные методы предотвращения промпт-инъекций (OWASP, LLM01). OWASP предлагает набор мер, которые снижают ущерб: ограничить поведение модели, проверять формат вывода кодом, фильтровать вход и выход, давать приложению минимальные права, требовать подтверждения человека для рискованных действий, отделять внешний контент и регулярно проводить атакующее тестирование. Фильтрация — только одна из семи мер.

Поэтому LLM-файрвол не отменяет архитектурных решений. Если агент может удалить файлы или отправить письмо, это право нужно ограничить в самой системе, а не надеяться, что шлюз распознает вредную инструкцию. Как устроены атаки через изображения и документы, мы разбирали в статье о мультимодальной prompt injection, а базовые правила защиты ИИ-чата — в материале о защите ИИ-агентов.

Чек-лист требований к LLM-файрволу

Чек-лист составлен редакцией по описанию запроса «Ростелекома» и мерам OWASP. Его можно использовать как основу технического задания или опросника для поставщика.

Покрытие

Все ли приложения, чат-боты и агенты можно направить через шлюз, включая обращения к RAG и инструментам агентов?
Поддерживаются ли нужные модели и провайдеры, в том числе локальные модели в собственном контуре?
Проверяются ли и запросы, и ответы, и внешний контент, который подмешивается в контекст?

Качество обнаружения

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

Реакции и процессы

Есть ли градация реакций: предупреждение, маскирование, карантин, блокировка?
Кто разбирает карантин и за какое время?
Передаются ли инциденты в SOC и SIEM, которые уже используются?

Эксплуатация

Какую задержку добавляет проверка и как она масштабируется под пиковую нагрузку?
Где хранятся журналы диалогов, кто к ним имеет доступ и сколько они хранятся? Журнал промптов сам по себе содержит чувствительные данные.
Нужен ли продукт из реестра российского ПО и совместим ли он с вашей инфраструктурой?

Если компания отправляет данные внешним провайдерам, отдельно проверьте, что происходит с ними на стороне провайдера; о режимах без хранения данных мы писали в статье о Zero Data Retention, а о правилах передачи клиентских данных — в материале об обезличивании.

План внедрения по этапам

Это план редакции, а не результат нашего внедрения. Сроки этапов зависят от числа приложений и не приводятся.

Инвентаризация. Составьте реестр ИИ-приложений и агентов: кто владелец, какие модели вызываются, какие данные передаются, есть ли доступ к инструментам. Без реестра непонятно, что вообще защищать.
Единая точка выхода к моделям. Переведите обращения к моделям через общий шлюз. Это полезно и без фильтров: появляется учёт запросов и расходов. Как устроен такой слой маршрутизации, мы описывали в статье о роутере моделей.
Режим наблюдения. Включите проверки только на запись в журнал. Несколько недель реального трафика покажут, какие данные действительно уходят в модели и сколько было бы ложных блокировок.
Маскирование и мягкие реакции. Начните с маскирования очевидно чувствительных данных и предупреждений пользователям, затем включайте карантин.
Блокировка для высокого риска. Жёсткую блокировку включайте для категорий, по которым доля ложных срабатываний на вашем трафике приемлема.
Атакующее тестирование. Регулярно проверяйте защиту набором инъекций и джейлбрейков на русском языке, включая инъекции через документы базы знаний.

Как понять, что защита работает

Метрики ниже — ориентиры для отчёта, а не нормативы. Пороговые значения стоит определить по своему трафику на этапе наблюдения.

Метрика	Что показывает
Доля приложений и агентов, подключённых через шлюз	Полноту покрытия
Число срабатываний по категориям: инъекции, персональные данные, секреты	Где реальные риски
Доля ложных срабатываний по итогам разбора карантина	Мешает ли защита работе
Пропуски, найденные атакующим тестированием	Реальную эффективность обнаружения
Медиана и 95-й перцентиль добавленной задержки	Цену защиты для пользователей
Время разбора карантина	Нагрузку на службу безопасности

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

Что такое LLM-файрвол?

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

Чем LLM-файрвол отличается от DLP?

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

Защищает ли LLM-файрвол от всех промпт-инъекций?

Нет. OWASP указывает, что надёжных методов предотвращения промпт-инъекций пока не известно. Файрвол снижает риск, но его нужно сочетать с минимальными правами приложений и агентов, проверкой человеком рискованных действий и регулярным атакующим тестированием.

Нужен ли LLM-файрвол, если в компании одно ИИ-приложение?

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

Замедляет ли LLM-файрвол ответы модели?

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

С чего начать внедрение LLM-файрвола?

С инвентаризации ИИ-приложений и агентов и перевода обращений к моделям через единый шлюз. Затем — режим наблюдения без блокировок, маскирование и мягкие реакции, и только после замера ложных срабатываний — блокировка для высокого риска.

Первоисточники и метод проверки

Метод: 15 октября 2026 года мы прочитали описание проекта «Ростелекома» на TAdviser и новость на Хабре, выписали требования к системе, сверили формулировки рисков и мер защиты с актуальными страницами OWASP. Собственных испытаний LLM-файрволов AIrassvet не проводил; таблицы сравнения, чек-лист, план внедрения и метрики — методика редакции.

TAdviser: «Ростелеком» создаст систему контроля коммуникаций для 1,5 тыс. ИИ-приложений — описание запроса информации, требования, комментарии «Ростелекома» и «Лаборатории Касперского».
Хабр, 15.10.2026: новость о системе контроля коммуникаций LLM-приложений.
OWASP: Top 10 for LLM Applications 2025, LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure.

Ограничения: проект «Ростелекома» находится на стадии запроса информации, итоговая архитектура и поставщик неизвестны; эффективность обнаружения конкретных продуктов в статье не измерялась.

Как AIrassvet помогает защитить корпоративные ИИ-приложения

LLM-файрвол работает лучше, когда сами ИИ-приложения спроектированы с расчётом на него: понятно, какие данные куда уходят и что разрешено агентам. На сайте AIrassvet описаны направления, которые относятся к этой задаче напрямую:

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

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

Обсудить задачу.

Итог: файрвол как слой, а не как стена

Запрос «Ростелекома» показывает, куда движутся крупные компании: от разрозненных ИИ-сервисов к единой точке контроля, которая видит каждый запрос к модели и каждый ответ. LLM-файрвол закрывает то, чего не видят DLP и WAF, — манипуляции моделью и утечки внутри диалога.

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