Глава 1 — Почему безопасность ИИ иная

Первый пост поглавного разбора LLM Primer VII: AI Security. Глава, утверждающая, что безопасность ИИ — это не традиционная безопасность с приставкой ML: подложка изменилась, и всё дальнейшее в книге следует из этого сдвига.

Зачем существует эта глава

Три десятилетия инженерия безопасности опиралась на устойчивую основу: код и данные — разные вещи, уязвимости — расхождение между заявленным и фактическим поведением, а патчи их закрывают. Большие языковые модели ломают эту основу конкретным образом. Поведение, которое надо защищать, закодировано не в исходном коде, а в миллиардах выученных весов, исполняемых против входа, где доверенные инструкции смешаны с недоверенным содержимым в одной строке. «Уязвимость» часто не баг — это модель, делающая ровно то, чему её учили, в контексте, которого дизайнеры не предвидели. Нет патча для «модель была слишком услужлива». Есть только редизайн, переобучение или дополнительная изоляция. Эта глава называет структурные различия, определяющие всё, что последует далее.

1.1 Подложка изменилась

Традиционная безопасность приложений работает потому, что поведение специфицировано в коде, а дефекты локализуемы. У SQL-инъекции есть структурное решение — параметризованные запросы — потому что есть синтаксическое различие между запросом и параметром. У языковой модели такой спецификации нет. Есть цель обучения и распределение весов, а поведение на конкретном входе — эмерджентно. Когда модель отказывает на одной формулировке и подчиняется на другой, править нечего. Вопрос безопасности сдвигается от «есть ли баг на этом пути кода» к «на что эта система способна и при каких условиях эта способность становится опасной». Традиционная безопасность также предполагала детерминизм как базовую линию; здесь базовая линия вероятностная. Фильтр безопасности, успешный на тысяче тестов, может дать сбой на тысяча первом, потому что сэмплирование пошло другим путём. Защитник рассуждает распределениями и доверительными интервалами, а не доказательствами недостижимости. Обновлённый в 2025 году OWASP Top 10 для приложений LLM — с prompt injection на LLM01 и неограниченным потреблением на LLM10 — попытка назвать этот новый слой, но это этаж выше существующего этажа веб-приложений, а не его замена.

1.2 Поверхность атаки расширяется

Приложение, интегрированное с LLM, вводит поверхности, которых раньше не было. Сам промпт — конкатенация инструкций разработчика, извлечённого контекста, ввода пользователя и результатов работы инструментов, — и всё это токены, которые модель читает без встроенных границ доверия. Если пользователь может повлиять на любую часть, он делит канал с разработчиком. Retrieval-путь — вторая новая поверхность: каждый индексируемый документ становится косвенным входом, и всякий, кто может повлиять на то, что попадает в индекс, влияет на то, что видит модель. Гресаке и коллеги назвали это косвенной prompt-инъекцией в 2023 году и показали, что канал и реален, и трудно закрываем. Граница tool-use — третья: каждый инструмент, выданный модели, — это привилегия, чьи последствия выходят за пределы текста ответа и достигают реальных систем. Обучающий конвейер — четвёртая, поскольку любые данные, использованные для обновления модели, становятся частью границы доверия. Артефакт модели — пятая: большие бинарники, чья десериализация, как показал CVE-2024-3568, может исполнить код при загрузке. Обработка вывода — шестая, поскольку сгенерированный моделью контент, передаваемый ниже по конвейеру, — это недоверенный вход под другим именем. MITRE ATLAS каталогизирует тактики и техники против этой расширенной поверхности.

1.3 Модели становятся инфраструктурой

С 2012 по 2022 год модели были фичами внутри приложений. Сбой рекомендательной системы давал худшие рекомендации. Большие языковые модели, особенно с tool-use, это изменили. Модель всё чаще — оркестровочный слой: читает документы, решает, какой инструмент вызвать, набрасывает сообщение, генерирует код, который исполняет другой компонент. Часто это самый мощный компонент системы, и одновременно самый податливый — управляемый естественно-языковым вводом, который может написать кто угодно. У традиционной базы данных есть языки запросов и контроли доступа; у LLM в роли оркестратора нет ни одного из этих внутренних ограничителей — только те, что добавило окружающее приложение. Именно это «инфраструктура» здесь и значит: несущие компоненты, чей компромисс распространяется. Инфраструктуре определяют SLO, обеспечивают всестороннее логирование, контроль изменений и реагирование на инциденты. Большинство развёртываний LLM в 2024–2025 годах ещё не достигли этой зрелости. Инфраструктурный фрейм касается и закупок: когда организация встраивает управляемый LLM-сервис в свой стек, дисциплина обновления модели вендором, оценочные ворота и практики раскрытия становятся частью риск-профиля покупателя.

Что подготавливает глава 1

Остальная часть книги — ответ на структурные сдвиги, названные здесь. Глава 2 вводит моделирование угроз, адаптированное для систем LLM, — фреймворки STRIDE и PASTA, обращённые к активам, противникам и поверхностям атаки, не появляющимся на обычных диаграммах. Глава 3 прорабатывает данные-измерение на всём жизненном цикле. Главы 4–6 проходят внутренность промпта и взаимодействия: инъекция, фильтрация и RAG. Главы 7–9 проходят слой модели. Главы 10–12 проходят системную архитектуру вокруг. Главы 13–15 добавляют регуляторный, ответственно-ИИшный и организационный периметр. Глава 16 разбирает файн-тюнинг как отдельную поверхность безопасности, а глава 17 смотрит на угрозы, которые ещё формируются. Вся дуга опирается на посылку, установленную этой главой: подложка изменилась, и дисциплина должна измениться вместе с ней.

Дальше — Глава 2: Моделирование угроз для систем LLM. Четыре вопроса Шостака, STRIDE и PASTA против активов LLM и MITRE ATLAS как каталог тактик противников, которых эта новая поверхность притягивает.