Большинство продуктов ломаются не потому, что никто не произносил слово «безопасность». А потому, что безопасность осталась слайдом, пока реальная система жила по своим правилам.
1. Безопасность — это поведение продукта, а не настроение комплаенса
Слово safety до сих пор заставляет одних думать о папках с правилами, а других — о цензуре. Ни то ни другое особенно не помогает.
В продуктовых терминах всё проще:
- что системе разрешено видеть
- что ей разрешено делать
- что ей разрешено утверждать
- от чего она обязана отказаться
- как ошибки наблюдаются и локализуются
Именно поэтому хорошие решения по безопасности в коде обычно выглядят скучно:
- более узкие права
- яснее точки согласования
- безопаснее поведение по умолчанию
- трассируемые действия
- релизные гейты вокруг рискованного поведения
Скука здесь скорее достоинство.
2. Prompt injection — это нормальная часть модели угроз
OWASP по-прежнему начинает список LLM-рисков с prompt injection. Не потому, что это модная страшилка, а потому, что слишком много систем до сих пор доверяют тексту, который читает модель, гораздо больше, чем следует.
Рабочее правило простое:
Недоверенному контенту нельзя позволять переписывать системные инструкции или расширять права системы.
Это значит, что поднятые документы, письма, веб-страницы и любые внешние источники в чувствительных сценариях нужно считать враждебными по умолчанию.
Если модель читает документ, это ещё не значит, что она имеет право ему подчиняться.
3. Лишняя агентность — это баг дизайна, а не амбициозная функция
OWASP отдельно выделяет excessive agency, и это очень по делу.
Проблема не в агентности как таковой. Проблема — в широких правах, расплывчатых границах и слабом контроле.
Здоровый контур гораздо уже:
- узкий набор прав у инструментов
- узкие контракты инструментов
- явные согласования для необратимых действий
- обратимые операции там, где это возможно
- телеметрия для каждого внешнего действия
Если система может отправлять письма, покупать, удалять, деплоить или менять записи, модель прав нужно воспринимать как часть инфраструктуры, а не как приписку к промпту.
4. Валидация ответа важна потому, что внешние системы буквальны
Опасный ответ — это не только грубый текст или токсичный ответ.
Это ещё и:
- кривой JSON, ушедший в рабочий контур
- невалидный SQL или совет по коду, попавший в путь исполнения
- неподтверждённое юридическое или медицинское утверждение, выданное уверенным тоном
- ссылка, команда или инструкция, получившая слишком много доверия только из-за интерфейса
Поэтому категории OWASP про insecure output handling и sensitive information disclosure остаются практичными. Ответ — это место, где расплывчатая модель встречается с буквальной системой.
Эта встреча требует присмотра.
5. Проверки безопасности должны стоять там, где они реально помогают
Не вся защита должна жить в критическом пути.
Полезное разделение такое.
Критический путь
Здесь остаётся то, что предотвращает немедленный вред:
- границы прав
- проверка схемы
- согласование для опасных действий
- жёсткие блоки на известные запрещённые паттерны
Мониторинг и разбор
Сюда лучше вынести:
- более глубокий red-team анализ
- трендовый мониторинг
- judge-модельные оценки
- широкий разбор аномалий
Часто команды делают наоборот: либо перегружают критический путь дорогими проверками, либо оставляют опасное поведение на потом. Ни один из вариантов нельзя назвать зрелым.
6. Evals делают safety труднее подделать
Хорошая история про безопасность должна выдерживать встречу с набором evals.
Мне нужны кейсы хотя бы для такого:
- попытки prompt injection
- неподтверждённые утверждения
- опасные предложения вызвать инструмент
- попытки вытащить чувствительные данные
- отказные сценарии по правилам
- границы эскалации
Недавние тексты Anthropic про evals для агентных систем здесь полезны именно своей сухостью: определить задачу, определить критерии, мерить регулярно. Безопасность становится лучше в тот момент, когда перестаёт звучать как ритуал и начинает выглядеть как дизайн проверок.
7. Мониторинг должен объяснять решения, а не только считать инциденты
Панель мониторинга, которая сообщает, что случилось что-то плохое, уже лучше, чем её отсутствие.
Но по-настоящему полезная система ещё и объясняет:
- какой запрос это вызвал
- какой контекст был у модели
- какой инструмент система попыталась вызвать
- какое правило или точка согласования сработала
- что в итоге увидел пользователь или внешняя система
Иначе разбор инцидента превращается в археологию. Только с худшим настроением.
8. Зрелый защитный контур выглядит трезво
Системы, которым я доверяю, обычно не производят впечатления паранойи. Они производят впечатление дисциплины.
Они не обещают невозможного. Они не рассказывают, что модель теперь «безопасна» в каком-то мистическом общем смысле. Они просто уменьшают число способов, которыми система может устроить дорогую неприятность.
На практике это и есть большая часть работы.
Что бы я внедрял первым
Если бы мне нужно было сейчас быстро ужесточить LLM-продукт, я бы шёл так:
- расписал реальные внешние эффекты и утечки данных
- сузил права инструментов и точки согласования
- добавил safety evals на главные рискованные сценарии
- поставил валидацию ответа перед буквальными внешними системами
- дотянул телеметрию до уровня, где разбор инцидентов перестаёт быть гаданием
Церемония может подождать. Контроль — нет.