✅ Как защитить LLM в продакшене: чек-лист
Как защитить LLM в продакшене — вопрос, который встаёт перед каждой командой ровно в тот момент, когда прототип на большой языковой модели (Large Language Model, LLM) превращается в боевой сервис с реальными пользователями, реальными данными и реальными последствиями. Это руководство — практический чек-лист безопасности LLM в продакшене: от модели угроз и контроля ввода-вывода до защиты агентов, аудита и реагирования. Каждый пункт сопровождается привязкой к движкам платформы SYNTREX и примером syntrex.yaml, чтобы из списка задач сразу получалась конфигурация.
Это руководство опирается на 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 — отлов скрытых/невидимых символов и гомоглифов.
- ☑️ Контроль социальной инженерии и извлечения системного промпта.
SYNTREX: 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).
- ☑️ Перехват фрагментов системного промпта в ответе.
- ☑️ Никогда не исполняйте код от модели без ревью/песочницы.
SYNTREX: output_scanner, injection. SYNTREX инлайн инспектирует каждый ответ и при опасности блокирует или заменяет его безопасной заглушкой. Подробнее — в небезопасной обработке вывода.
3. Защита данных: PII, секреты, эксфильтрация
Задача. Sensitive Information Disclosure (LLM02): модель раскрывает PII, ключи, секреты — через ответ, логи или RAG. Особо критична межпользовательская утечка из векторного хранилища.
- ☑️ Маскирование PII в ответе (redact, не обязательно блок всего запроса).
- ☑️ Недизаблируемое маскирование секретов, ключей и токенов на исходящем рубеже.
- ☑️ Детекция аномальной выгрузки данных (markdown-каналы, EchoLeak-паттерны).
SYNTREX: pii, exfiltration, output_scanner. Подробнее — в утечке данных и эксфильтрации.
4. Защита агентов: инструменты и предсказуемость цели
Задача. Excessive Agency (LLM06): агент с избыточными полномочиями при компрометации совершает необратимые действия — рассылает письма, удаляет файлы, проводит транзакции.
- ☑️ Принцип наименьших привилегий + human-in-the-loop для необратимых действий (организационный контроль).
- ☑️ Контроль злоупотребления инструментами и cross-tool цепочек.
- ☑️ Runtime-оценка риска по предсказуемости цели агента.
- ☑️ Контроль «летальной тройки» на уровне действия.
SYNTREX: tool_abuse, cross_tool_guard, goal_predictability, lethal_trifecta, model_containment. Подробнее — в избыточных полномочиях и автономных агентах.
5. RAG и внешний контент
Задача. Косвенная инъекция и отравление базы знаний (LLM04, LLM08) приходят именно через поднятый контент.
- ☑️ Инспекция RAG-чанков на встроенные инструкции до подачи в контекст.
- ☑️ ACL-aware retrieval и изоляция тенантов в общем векторном хранилище.
- ☑️ Детекция спящих полезных нагрузок (dormant payload).
SYNTREX: injection, output_scanner, dormant_payload, pii. Полный разбор и syntrex.yaml для RAG — в безопасности RAG-систем.
6. Контроль потребления и квот
Задача. Unbounded Consumption (LLM10): неконтролируемый расход токенов/вызовов → DoS и «Denial of Wallet».
- ☑️ Rate-limiting, квоты и таймауты на уровне шлюза (инфраструктурный контроль).
- ☑️ Поведенческий rate-limiting по семантике промпта, а не только по числу токенов.
- ☑️ Алерт на аномальный всплеск событий от одного источника.
SYNTREX: rate-limiting выполняется на уровне шлюза; SOC Correlation Engine содержит правило ALERT_FLOOD (100+ событий от одного сенсора за 60 секунд). Подробнее — в неограниченном потреблении. Дополнительно движок resource_exhaustion выявляет нагрузочные паттерны во вводе.
7. Учётные данные и supply chain
Задача. Supply Chain (LLM03): скомпрометированные модели, LoRA, пакеты, MCP-серверы. Статичные ключи — лишний риск.
- ☑️ Замена статичных API-ключей на эфемерные, scoped-креденшелы.
- ☑️ SBOM/ML-BOM, верификация подписей и хешей моделей и зависимостей (DevSecOps-процесс).
- ☑️ Рантайм-детекция спящих нагрузок и аномального исходящего трафика.
SYNTREX (честная граница): прямого «сканера зависимостей» нет — это зона DevSecOps. На рантайме помогают dormant_payload и exfiltration (снижение радиуса поражения). Подробнее — в supply-chain рисках.
8. Аудит, корреляция и реагирование
Задача. Многоступенчатая атака видна как цепочка событий; без неизменяемого следа невозможно ни расследование, ни предъявление регулятору.
- ☑️ Неизменяемый журнал решений (хеш-цепочка, пригодная для аудита).
- ☑️ Корреляция событий в инцидент с привязкой к MITRE ATLAS / OWASP.
- ☑️ Готовые плейбуки реагирования (авто-блок сессии, карантин).
- ☑️ Интеграция с SIEM/SOC.
SYNTREX: Decision Logger (SHA-256/HMAC), SOC Correlation Engine. Карта тактик — в MITRE ATLAS.
9. До и после запуска
- ☑️ Red teaming перед продом: прогон вредоносных промптов, проверка, что ответы держат планку.
- ☑️ Провенанс данных дообучения (версионирование, trust-оценки) для детекции отравления.
- ☑️ Регулярные сканы и пентесты; DPIA для высокорисковой обработки (GDPR/ФЗ-152).
- ☑️ Мониторинг дрейфа и регресса после обновления модели или промптов.
Как SYNTREX закрывает чек-лист: сводный syntrex.yaml
SYNTREX — защитный слой платформы Spectorn, разворачиваемый standalone на внутренних контурах заказчика (on-prem, изолированный периметр; движки на Rust/Go, CPU-эффективная инспекция). Минимальный продакшен-профиль, покрывающий ядро чек-листа:
# syntrex.yaml — продакшен-профиль защиты LLM
version: "1.0"
mode: firewall
engines:
# 1. контроль ввода
injection:
action: block
normalize_unicode: true
confidence_threshold: 0.75
jailbreak:
action: block
confidence_threshold: 0.85
social:
action: alert
# 2. контроль вывода
output_scanner:
action: sanitize
# 3. защита данных
pii:
action: redact
mask_character: "*"
exfiltration:
action: block
exfiltration:
action: block
confidence_threshold: 0.90
# 4. защита агентов
lethal_trifecta:
action: block
tool_abuse:
action: block
cross_tool_guard:
action: alert
goal_predictability:
action: block
# 5/7. RAG и спящие нагрузки
dormant_payload:
action: alert
shield:
dmz: true # инлайн-стадия инспекции содержимого ответа
audit:
decision_logger: true # неизменяемая цепочка SHA-256/HMAC
Правило корреляции SOC: инъекция → исполнение инструмента
rules:
- id: INJECTION_TO_EXEC
name: "Prompt Injection → Tool Execution"
description: "Инъекция, за которой следует исполнение инструмента в течение 3 минут"
enabled: true
conditions:
- sequence:
- category: injection
min_confidence: 0.7
- category: tool_abuse
min_confidence: 0.5
within: "3m"
same_field: "source_ip"
action:
create_incident: true
severity: CRITICAL
playbook: "auto_block_session"
metadata:
mitre_atlas: ["AML.T0051"]
owasp_llm: ["LLM01", "LLM05", "LLM06"]
Честные границы: что чек-лист не закрывает движками
Зрелая защита не делает вид, что один продукт решает всё. Преимущественно организационными и инфраструктурными мерами остаются:
- Supply chain (LLM03) — SBOM/ML-BOM, подписи, пиннинг версий.
- Контроль потребления (LLM10) — rate-limiting и квоты на шлюзе.
- Дезинформация / галлюцинации (LLM09) — RAG с доверенными источниками, обязательные цитаты, human review.
- Безопасное кодирование инструментов — параметризованные запросы, отказ от
shell=True. - Наименьшие привилегии и human-in-the-loop для необратимых действий агента.
SYNTREX дополняет эти процессы детекцией, корреляцией и аудитом, но не подменяет их.
❓ Частые вопросы (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?
Да, и для регулируемых отраслей это часто требование. SYNTREX разворачивается standalone на внутренних контурах: трафик не покидает периметр, движки на Rust/Go работают на CPU без обязательной GPU.
Как доказать регулятору, что инцидент обработан?
Нужен неизменяемый аудит. Decision Logger пишет каждое решение движков в хеш-цепочку (SHA-256/HMAC), а SOC Correlation Engine связывает события в инцидент с привязкой к OWASP/MITRE ATLAS — это и есть пригодный для предъявления след.
Чем защита RAG отличается от защиты обычного чат-бота?
В RAG добавляется недоверенный поднятый контент: косвенная инъекция и отравление базы знаний приходят через документы, а не только через пользователя. Нужны инспекция чанков, ACL-aware retrieval и изоляция тенантов — подробно в безопасности RAG-систем.
Источники
- OWASP Top 10 for LLM Applications 2025
- Oligo — LLM Security in 2025: Risks, Examples, and Best Practices
- Datadog — LLM guardrails: best practices for deploying LLM apps securely
- PremAI — 12 Best Practices for Deploying LLMs in Production
- Wiz — LLM Security: Protecting Models, RAG & Data Pipelines
- Simon Willison — the lethal trifecta
- MITRE ATLAS
Связанные руководства: Что такое AI Firewall · LLM Guardrails · Гайд покупателя по безопасности ИИ · OWASP Top 10 для LLM · Безопасность RAG-систем · Отраслевые сценарии