Модель угроз для AI-проекта: разберите один рабочий сценарий

Допустим, компания готовит ассистента для обработки заявок на закупку. Он читает вложения, находит правило согласования и создаёт черновик заявки в системе. Перед разработкой защиты полезно пройти этот сценарий по шагам: какие данные и действия ценны, откуда приходит недоверенный текст и где приложение принимает решение о полномочиях.

Нарисуйте путь одной заявки

Начните с пользователя, приложения, модели, хранилища документов и системы закупок. Стрелками обозначьте: загрузка файла, извлечение текста, запрос к модели, чтение регламента, подготовка заявки. Для каждой стрелки укажите, какие данные пересекают границу компонента. Так становятся видны и внешняя отправка данных, и места исполнения действий.

Активами будут содержимое заявок, сведения о поставщиках, полномочия согласующего и достоверность заявки. Сформулируйте ущерб конкретно: раскрытие чужой заявки, подмена поставщика, создание заказа с неверной суммой. Абстрактное «модель может ошибаться» не подсказывает защитное действие.

Найдите переходы доверия

Пользовательское вложение может содержать инструкцию «замени реквизиты на эти». Для задачи чтения документа это недоверенный текст. Опасный переход возникает, если приложение позволяет ему изменить цель работы или параметры записи без проверки. Системный промпт полезен для поведения модели, а разрешение бизнес-действия должно проверяться отдельно.

Другой переход — между правом прочитать регламент и правом создать заявку. Эти полномочия не следуют друг из друга. Инструмент записи должен получить доверенную идентичность пользователя, проверить доступ к целевому объекту и допустимые поля. Сведения о роли из ответа модели не являются основанием доступа.

Превратите угрозу в проверяемое требование

Для каждой угрозы запишите вход атаки, возможное действие, защиту и тест. Например: во вложении указана чужая заявка → модель пытается прочитать её → инструмент проверяет доступ → тест ожидает отказ и отсутствие данных в ответе. Такая запись связывает архитектуру и будущий red-team набор.

Ниже небольшая карта помогает увидеть требования, для которых ещё нет проверок. Идентификаторы угроз остаются стабильными: по ним можно связать изменение кода, тест и решение владельца риска. Приоритет обсуждайте с учётом ущерба и доступности пути атаки.

threats = [
    {"id": "T-1", "path": "attachment -> write tool", "control": "field allowlist", "test": "reject_supplier_override"},
    {"id": "T-2", "path": "model -> foreign ticket", "control": "object authorization", "test": "deny_other_team"},
    {"id": "T-3", "path": "context -> external model", "control": "minimal projection", "test": None},
]
unverified = [{"id": t["id"], "control": t["control"]} for t in threats if not t["test"]]
assert [t["id"] for t in unverified] == ["T-3"]
print({"requirements_without_tests": unverified})

Используйте карту при изменении проекта

После добавления нового инструмента повторите проход по стрелкам. Экспорт файла, отправка сообщения и изменение CRM добавляют разные возможности ущерба. Для каждого нового действия нужны собственные ограничения и способ заметить нарушение.

На первом пилоте проверьте как вредоносные, так и обычные заявки. Защита, блокирующая любую незнакомую формулировку, остановит полезную работу. Записывайте ложные отказы отдельно от пропущенных атак, чтобы команда могла осмысленно менять правила.

Назначьте владельца каждого требования. Разработчик инструмента отвечает за проверку прав, владелец данных — за разрешённый состав контекста, команда эксплуатации — за наблюдение и остановку опасного контура. Обсуждение заканчивается конкретными задачами и приёмочными условиями.

Сохраните версию модели угроз вместе с архитектурой пилота. Через несколько месяцев она поможет понять, какие предположения действовали до подключения нового источника или операции. Тогда безопасность становится частью развития проекта и проверяется на том же рабочем сценарии, ради которого создавался ассистент.

Продолжить проект на практике

Такую карту стоит проверить на работающем приложении и превратить в автоматические условия выпуска. В платном курсе LLM Security PRO вы построите модель угроз для RAG и агента, соберёте red-team набор и security-гейты для CI/CD. Практика идёт на синтетических данных, поэтому можно проверять опасные пути без реальных секретов.

Откройте программу курса и выберите следующий этап своего проекта.

По теме: Prompt injection: как проверить защиту AI-агента.