Принцип: защищать не модель, а систему вокруг неё
Попытка «научить модель сопротивляться» всеми силами промпта — тупиковый путь: формулировку атаки всегда можно переиначить. Зрелая защита исходит из того, что компромисс модели возможен в любой момент, и строит сервис так, чтобы захваченный контекст не превращался в катастрофу. Ниже — семь слоёв, из которых на практике собирается устойчивый корпоративный контур.
Слой 1. Дисциплина системного промпта
Системный промпт — не сейф. Секреты, ключи, имена внутренних систем и персональные данные в нём размещать нельзя: рассчитывайте, что однажды его увидят посторонние. Правила формулируйте поведенчески — что сервис делает и чего не делает ни при каких условиях, — и дубилируйте критические запреты отдельным контрольным блоком после пользовательских данных, а не только в начале контекста: хвостовые инструкции модели выполняют охотнее.
Слой 2. Разметка и изоляция недоверенных данных
Всё, что пришло в контекст извне, оформляйте рамкой с явным статусом: блок данных, не являющийся инструкциями. Полезны структурные приёмы: закрытые секции с уникальными ограничителями, нумерация блоков, отдельные роли сообщений для стороннего контента. Это не гарантия, но статистически заметное снижение срабатываний — модель получает якорь для различения источника указаний.
Слой 3. Санитизация на входе
Документы и веб-страницы перед подачей в модель очищаются: удаляются скрытые слои текста, невидимые символы Юникода, нулевые ширины, примечания, метаданные, содержимое скрытых слоёв PDF и картинки-вставки с текстом. Для HTML — выборочное извлечение читаемого содержимого вместо сырой разметки. Отдельный класс — кодированные инъекции: строки в base64, юникод-эскейпах и прочих схемах упаковки, которые стоит разворачивать и проверять до попадания в контекст.
Слой 4. Минимальные привилегии инструментов
Самый недооценённый слой. Инъекция без полномочий — это испорченный ответ; инъекция с правом отправлять письма или менять записи — это инцидент. Правила:
- каждый инструмент получает доступ только к нужным сущностям и только с нужными правами (чтение вместо записи, свой бакет вместо всего хранилища);
- необратимые операции — платежи, рассылки, удаление, смена прав — выносятся за пределы автономии модели и требуют подтверждения человеком;
- на каждое действие устанавливаются квоты и лимиты частоты;
- служебные учётные записи, под которыми действует агент, не должны совпадать с административными.
Слой 5. Контроль вывода
Ответ модели до передачи потребителю проверяется по контексту его использования. Если результат вставляется в веб-интерфейс — экранирование разметки; если превращается в запрос к базе — параметризация; если уходит в другую программу — валидация схемы. Отдельно фильтруются попытки вынести служебную информацию: упоминания системного промпта, настроек, внутренних идентификаторов.
Слой 6. Мониторинг и реагирование
Журналы запросов, действий инструментов и ответов модели стекаются в единую точку — SIEM или хотя бы регулярную выгрузку. Настраиваются простые индикаторы: всплески формулировок про «игнорирование инструкций», аномальные цепочки вызовов инструментов, отказы от правил после конкретных сообщений, повторяющиеся аномалии от одного источника. По каждому индикатору должен существовать сценарий реакции — от алерта дежурному до автоматической блокировки сессии.
Слой 7. Регулярные проверки
Защита деградирует тихо: сменилась модель, обновился промпт, добавился инструмент — и прежние барьеры больше не держат. Поэтому корпус тестовых инъекций прогоняется по расписанию и при каждом изменении конвейера. Как это делается технически, разобрано в материале о проверке устойчивости.
Каркас внедрения
| Этап | Что делается | Критерий готовности |
|---|---|---|
| Диагностика | инвентаризация сервисов, входов, данных и полномочий | карта ИИ-контура с уровнями критичности |
| Быстрые меры | чистка секретов, ограничение прав, разметка данных | тяжёлые последствия закрыты дешёвыми средствами |
| Инженерия | санитизация, контроль вывода, журналирование | атаки фиксируются и разбираются |
| Проверка | тестовые прогоны инъекций по всем каналам | доля успешных атак известна и приемлема |
| Эксплуатация | регламент реагирования, повтор тестов по расписанию | процесс живёт без внешнего толчка |
Ожидаемый результат
Цель многослойной защиты — не ноль атак, а управляемый ущерб: попытки инъекций фиксируются, срабатывания локализуются одним слоем, критичные действия требуют человека, а инцидент расследуется по журналам за часы, а не недели. Такой контур заодно закрывает значительную часть требований к безопасности моделей, которые для разработчиков больших систем вступают в силу с 01.03.2027 по 243-ФЗ от 26.07.2026, — но даже без регуляторного давления экономика здесь простая: восстановление после утечки через скомпрометированный ассистент стоит несопоставимо дороже перечисленных барьеров.