✅ Как защитить LLM в продакшене: чек-лист

Как защитить LLM в продакшене — вопрос, который встаёт перед каждой командой ровно в тот момент, когда прототип на большой языковой модели (Large Language Model, LLM) превращается в боевой сервис с реальными пользователями, реальными данными и реальными последствиями. Это руководство — практический чек-лист безопасности LLM в продакшене: от модели угроз и контроля ввода-вывода до защиты агентов, аудита и реагирования. Каждый пункт сопровождается привязкой к движкам платформы Spectorn и тем, что настраивается в политике тенанта.

Это руководство опирается на OWASP Top 10 для LLM (2025) и дополняет концептуальные страницы Что такое AI Firewall и LLM Guardrails практикой развёртывания.

Шаг 0. С чего начать: модель угроз

Прежде чем включать детекторы, опишите модель угроз по OWASP LLM Top 10: какие данные видит модель, к каким инструментам имеет доступ агент, откуда приходит недоверенный контент (RAG, письма, веб), что произойдёт при компрометации. Это определяет, какие движки и правила вам действительно нужны, и помогает не «золотить» защиту там, где риска нет.

Ключевой первый контроль — закрыть «летальную тройку» (lethal trifecta, формулировка Саймона Уиллисона): не давайте агенту одновременно (1) доступ к приватным данным, (2) контакт с недоверенным контентом и (3) канал вывода наружу. Достаточно разорвать любое из трёх свойств — и одной инъекции уже не хватит для кражи данных.

Чек-лист защиты LLM в продакшене

1. Контроль ввода: инъекции и джейлбрейки

Задача. Любой пользовательский и внешний ввод — недоверенный. Prompt injection (LLM01) остаётся риском №1: модель не отличает доверенные инструкции от недоверенного текста.

☑️ Детекция прямой и косвенной prompt injection.
☑️ Детекция джейлбрейков (DAN, Skeleton Key, many-shot, Crescendo).
☑️ Нормализация Unicode — отлов скрытых/невидимых символов и гомоглифов.
☑️ Контроль социальной инженерии и извлечения системного промпта.

Spectorn: injection, jailbreak, intent_revelation, social. Детальный разбор — в руководстве по Prompt Injection и джейлбрейкам.

2. Контроль вывода: «любой ответ модели — недоверенный ввод»

Задача. Improper Output Handling (LLM05): вывод LLM, переданный в SQL/shell/HTML/API без валидации, даёт XSS, SQLi, command injection. System Prompt Leakage (LLM07): ответ может содержать фрагменты скрытых инструкций.

☑️ Инспекция ответа на исполняемые/опасные конструкции (shell, SQL, HTML).
☑️ Перехват фрагментов системного промпта в ответе.
☑️ Никогда не исполняйте код от модели без ревью/песочницы.

Spectorn: output_scanner, injection. В режиме шлюза проверяется и ответ модели; если политика его блокирует, клиент получает 403 spectorn_output_blocked вместо ответа, а что показать пользователю, решает ваше приложение. Подробнее — в небезопасной обработке вывода.

3. Защита данных: PII, секреты, эксфильтрация

Задача. Sensitive Information Disclosure (LLM02): модель раскрывает PII, ключи, секреты — через ответ, логи или RAG. Особо критична межпользовательская утечка из векторного хранилища.

☑️ Обнаружение PII в ответе .
☑️ Недизаблируемое обнаружение секретов, ключей и токенов на исходящем рубеже.
☑️ Детекция аномальной выгрузки данных (markdown-каналы, EchoLeak-паттерны).

Spectorn: pii, exfiltration, output_scanner. Подробнее — в утечке данных и эксфильтрации.

4. Защита агентов: инструменты и предсказуемость цели

Задача. Excessive Agency (LLM06): агент с избыточными полномочиями при компрометации совершает необратимые действия — рассылает письма, удаляет файлы, проводит транзакции.

☑️ Принцип наименьших привилегий + human-in-the-loop для необратимых действий (организационный контроль).
☑️ Контроль злоупотребления инструментами и cross-tool цепочек.
☑️ Runtime-оценка риска по предсказуемости цели агента.
☑️ Контроль «летальной тройки» на уровне действия.

Spectorn: tool_abuse, cross_tool_guard, goal_predictability, lethal_trifecta, model_containment. Подробнее — в избыточных полномочиях и автономных агентах.

5. RAG и внешний контент

Задача. Косвенная инъекция и отравление базы знаний (LLM04, LLM08) приходят именно через поднятый контент.

☑️ Инспекция RAG-чанков на встроенные инструкции до подачи в контекст.
☑️ ACL-aware retrieval и изоляция тенантов в общем векторном хранилище.
☑️ Детекция спящих полезных нагрузок (dormant payload).

Spectorn: injection, output_scanner, dormant_payload, pii. Полный разбор — в безопасности RAG-систем.

6. Контроль потребления и квот

Задача. Unbounded Consumption (LLM10): неконтролируемый расход токенов/вызовов → DoS и «Denial of Wallet».

☑️ Rate-limiting, квоты и таймауты на уровне шлюза (инфраструктурный контроль).
☑️ Поведенческий rate-limiting по семантике промпта, а не только по числу токенов.
☑️ Алерт на аномальный всплеск событий от одного источника.

Закономерность, растянутую на много событий, ловит ваша SIEM: Spectorn отправляет туда каждую находку с правилом, категорией, серьёзностью и verdict_id; собственная корреляция SOC (GoMCP) в облачных контурах не развёрнута. Подробнее — в неограниченном потреблении. Дополнительно движок resource_exhaustion выявляет нагрузочные паттерны во вводе.

7. Учётные данные и supply chain

Задача. Supply Chain (LLM03): скомпрометированные модели, LoRA, пакеты, MCP-серверы. Статичные ключи — лишний риск.

☑️ Замена статичных API-ключей на эфемерные, scoped-креденшелы.
☑️ SBOM/ML-BOM, верификация подписей и хешей моделей и зависимостей (DevSecOps-процесс).
☑️ Рантайм-детекция спящих нагрузок и аномального исходящего трафика.

Spectorn (честная граница): прямого «сканера зависимостей» нет — это зона DevSecOps. На рантайме помогают dormant_payload и exfiltration (снижение радиуса поражения). Подробнее — в supply-chain рисках.

8. Аудит, корреляция и реагирование

Задача. Многоступенчатая атака видна как цепочка событий; без хеш-связанного следа невозможно ни расследование, ни предъявление регулятору.

☑️ Хеш-связанный журнал решений (хеш-цепочка, пригодная для аудита).
☑️ Корреляция событий в инцидент с привязкой к MITRE ATLAS / OWASP.
☑️ Плейбуки реагирования (авто-блок сессии, карантин).
☑️ Интеграция с SIEM/SOC.

Spectorn: каждый вердикт записывается в хеш-связанную цепочку SHA-256 без содержимого запросов, а каждая находка уходит в вашу SIEM JSON-событием по HTTPS (spectorn.ai-finding.v1). Корреляция и плейбуки реагирования живут в SIEM; собственная корреляция SOC в Spectorn (GoMCP) в контурах RU и Global не развёрнута. Карта тактик — в MITRE ATLAS.

9. До и после запуска

☑️ Red teaming перед продом: прогон вредоносных промптов, проверка, что ответы держат планку.
☑️ Провенанс данных дообучения (версионирование, trust-оценки) для детекции отравления.
☑️ Регулярные сканы и пентесты; DPIA для высокорисковой обработки (GDPR/ФЗ-152).
☑️ Мониторинг дрейфа и регресса после обновления модели или промптов.

🛠️ Настройка политики

Файла конфигурации, который нужно развернуть, нет: политику вашего тенанта по запросу задаёт оператор платформы, включая режим проверки (блокировка или наблюдение, при котором видно, что было бы заблокировано), списки разрешений и запретов, порог блокировки и веса категорий. Для этой отрасли важнее всего движки: injection, jailbreak, social, output_scanner, pii, exfiltration, lethal_trifecta, tool_abuse, cross_tool_guard, goal_predictability, dormant_payload. Начните с режима наблюдения на своём трафике, посмотрите, что было бы заблокировано, и затем включите блокировку. Маскирование персональных данных в облачных контурах не включено: запрос с персональными данными блокируется или отмечается, а не переписывается.

Честные границы: что чек-лист не закрывает движками

Зрелая защита не делает вид, что один продукт решает всё. Преимущественно организационными и инфраструктурными мерами остаются:

Supply chain (LLM03) — SBOM/ML-BOM, подписи, пиннинг версий.
Контроль потребления (LLM10) — rate-limiting и квоты на шлюзе.
Дезинформация / галлюцинации (LLM09) — RAG с доверенными источниками, обязательные цитаты, human review.
Безопасное кодирование инструментов — параметризованные запросы, отказ от shell=True.
Наименьшие привилегии и human-in-the-loop для необратимых действий агента.

Spectorn дополняет эти процессы детекцией, корреляцией и аудитом, но не подменяет их.

❓ Частые вопросы (FAQ)

С чего начать защиту LLM в продакшене?

С модели угроз по OWASP LLM Top 10, затем закройте «летальную тройку» (не давайте агенту одновременно приватные данные, недоверенный контент и канал наружу). Дальше включайте детекцию инъекций и джейлбрейков на входе, сканирование вывода (PII/секреты), контроль действий агента, а сверху — корреляцию и хеш-связанный аудит.

Какой самый важный контроль для LLM в проде?

Контроль ввода против prompt injection (LLM01) — это структурный риск №1. Но в одиночку он недостаточен: нужна эшелонированная защита — вход, выход, действия агента, аудит. «Один фильтр на входе» инъекцию не закрывает.

Достаточно ли встроенного выравнивания модели (alignment)?

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

Как защитить LLM-агента с доступом к инструментам?

Принцип наименьших привилегий и human-in-the-loop для необратимых действий — организационная база. Поверх неё включите контроль злоупотребления инструментами, cross-tool цепочек, предсказуемости цели и «летальной тройки» (tool_abuse, cross_tool_guard, goal_predictability, lethal_trifecta).

Нужен ли red teaming перед запуском LLM в прод?

Да. Прогон вредоносных промптов до релиза показывает, держат ли защита и сами ответы планку под атакой. Red teaming дополняет, а не заменяет рантайм-детекцию: он находит дыры заранее, а файрвол ловит атаки в бою.

Можно ли развернуть защиту LLM on-premise?

Для регулируемых отраслей это часто требование. Spectorn работает как облачный сервис в двух раздельных контурах, RU и Global, и трафик остаётся в контуре своего региона; установка в периметре заказчика в текущий релиз не входит. Движки написаны на Rust и работают на CPU без обязательной GPU.

Как доказать регулятору, что инцидент обработан?

Нужен хеш-связанный аудит. Закономерность, растянутую на много событий, ловит ваша SIEM: Spectorn отправляет туда каждую находку с правилом, категорией, серьёзностью и verdict_id; собственная корреляция SOC (GoMCP) в облачных контурах не развёрнута.

Чем защита RAG отличается от защиты обычного чат-бота?

В RAG добавляется недоверенный поднятый контент: косвенная инъекция и отравление базы знаний приходят через документы, а не только через пользователя. Нужны инспекция чанков, ACL-aware retrieval и изоляция тенантов — подробно в безопасности RAG-систем.

Источники

Связанные руководства: Что такое AI Firewall · LLM Guardrails · Гайд покупателя по безопасности ИИ · OWASP Top 10 для LLM · Безопасность RAG-систем · Отраслевые сценарии