Модель угроз приложения с языковой моделью
Безопасность AI и LLM: интеграции, агенты, guardrailsЧем архитектура с LLM отличается от обычного веб-приложения и какие новые границы доверия появляются.
Зачем это нужно
- LLM — не просто ещё один сервис: она видит данные и выполняет действия от имени приложения.
- Без модели угроз проверка сводится к перебору промптов и не находит реальных дефектов.
- Ошибки проектирования здесь приводят к утечкам и действиям, которые невозможно откатить.
Теория
Ключевое отличие: модель — это компонент, который получает на вход управляемый пользователем текст и возвращает данные, влияющие на дальнейшее поведение системы. Атака на интеграцию часто похожа на подделку запросов на стороне сервера: пользователь не имеет прямого доступа к системе, но заставляет её выполнить действие от своего имени. Поэтому в модели угроз отдельно описывают: какие входы контролирует пользователь (прямые — сообщение в чат, косвенные — содержимое документа, страницы, письма, ответа внешнего API), к каким данным и API модель имеет доступ, какие действия она может инициировать и кто подтверждает эти действия.
Второй слой — происхождение данных. Если модель получает сведения из базы знаний или внешних источников (подход поиска с дополнением, RAG), атакующий может влиять на эти источники: опубликовать страницу, отправить письмо, оставить комментарий. Данные могут попадать в контекст из недоверенного места и содержать инструкции. Это и есть основа косвенной инъекции промптов: вредоносный текст приходит не от пользователя, а из обрабатываемого контента.
Третий слой — цепочка действий. Агент может вызывать функции и внешние API: читать почту, формировать документы, создавать записи, отправлять данные. Каждый такой вызов — точка контроля. Правильная архитектура подразумевает, что решение о доступе принимает код приложения и политика прав, а не сама модель, и что для опасных действий есть подтверждение человеком. Отсюда практическое следствие: API, доступные модели, нужно рассматривать как публичные и защищать аутентификацией и правами.
Ключевые концепции
- Прямой и косвенный вход
- Прямой — сообщение пользователя; косвенный — содержимое документа, страницы, письма или ответа API, попадающее в контекст.
- Границы доверия
- Места, где данные переходят из недоверенной зоны в доверенную: контент из интернета, файлы пользователей, внешние API.
- RAG (поиск с дополнением)
- Схема, при которой модель получает фрагменты из базы знаний: источник дополнительного риска, если база пополняется извне.
- Полномочия агента
- Набор действий и API, доступных модели через вызываемые функции и инструменты.
- Подтверждение человеком
- Обязательный шаг одобрения для действий с последствиями: платежи, изменения прав, отправка данных.
- Модель не является границей безопасности
- Принцип: решение о доступе принимает код и политика, а не инструкции в промпте.
Инструменты
- Диаграммы потоков данных для LLM-архитектуры: входы, источники, инструменты, действия.
- Каталог техник MITRE ATLAS и OWASP Top 10 for LLM Applications как основа перечня рисков.
- Средства трассировки запросов к модели: что вошло в контекст, какие функции вызваны.
- Реестр инструментов и API, доступных модели, с указанием прав и подтверждений.
- Чек-листы ревью дизайна для функций, использующих модель.
Практика в легальных лабораториях
- Нарисуйте схему своего учебного LLM-приложения: входы, источники данных, инструменты, действия.
- Отметьте границы доверия и для каждой опишите, какой текст может попасть в контекст извне.
- Составьте перечень API, доступных модели, с правами и требованием подтверждения.
- Определите пять действий, которые должны требовать одобрения человека, и объясните почему.
- Опишите, какие данные вообще не должны подаваться модели.
Защита, детект и защитные меры
- Ограничивайте полномочия: минимальный набор инструментов, узкие права, отдельные учётные данные для сервиса модели.
- Вводите подтверждение человеком для действий с необратимыми последствиями.
- Фильтруйте и помечайте недоверенный контент, приходящий в контекст из внешних источников.
- Логируйте контекст и вызванные инструменты: без этого инцидент невозможно разобрать.
Правовая рамка и этика
- Проверка LLM-приложений выполняется на своих системах или на учебных площадках, созданных для этого.
- Отправка промптов в чужие публичные ассистенты для получения внутренних инструкций рассматривается как атака на чужой сервис.
- Не подавайте в модели персональные данные без правовых оснований.
Типичные ошибки
- Считать, что модель «поймёт» и не выполнит вредоносную инструкцию.
- Давать агенту широкие права «чтобы было удобнее».
- Не различать данные, полученные от пользователя, и данные из внешних источников.
- Не вести журнал контекста и вызовов инструментов.
Чек-лист «умею»
- Строю модель угроз для LLM-приложения: входы, источники, инструменты, действия.
- Различаю прямые и косвенные входы и указываю границы доверия.
- Веду реестр инструментов с правами и подтверждениями.
- Определяю данные, которые нельзя подавать модели.
- Понимаю, почему модель не является границей безопасности.
Вопросы на интервью
- Чем модель угроз LLM-приложения отличается от обычного веб-приложения?
- Какие действия агента вы обязательно потребуете подтверждать?
- Как вы ограничите последствия косвенной инъекции промптов?