Prompt injection — это не просто грубая просьба пользователя. Это ситуация, когда недоверенный контент влияет на AI-систему так, будто он содержит указание владельца приложения.
Размер бизнес-риска определяется не красотой атаки, а тем, что система после неё может прочитать, изменить, отправить или подтвердить.
Различайте прямую и косвенную инъекцию
OWASP разделяет прямую инъекцию в запросе пользователя и косвенную, спрятанную во внешнем материале: сайте, письме или файле.
Прямая атака может попросить support-бота забыть правила и показать закрытую запись. Косвенная помещает ту же команду внутрь документа, который сотрудник просит кратко пересказать.
Второй случай легко пропустить: запрос сотрудника законный, а враждебная инструкция приходит через данные, которые система должна читать.
Оценивайте права, а не интеллект модели
Модель, которая только готовит текст, создаст плохой черновик. Подключение к почте, CRM, хранилищу и платежам превращает тот же сбой во внешнее действие.
Для каждого процесса составьте таблицу полномочий: какие данные AI читает, что меняет, максимальный scope, обязательное подтверждение и способ отката.
OWASP об избыточной агентности советует убрать лишние функции, права и автономность. Read-only безопаснее коннектора, который одновременно умеет отправлять и удалять.
Считайте внешний контент данными, а не властью
Письма, PDF, заметки CRM, сайты, ответы инструментов и найденные знания остаются недоверенным содержимым даже внутри знакомой системы.
Отмечайте их границы, отделяйте от инструкций разработчика и указывайте, что внутри возможен враждебный текст. Это усиливает защиту, но не превращает модель в security boundary.
Microsoft рекомендует defence in depth: изоляцию контента, prompt shields, контроль отклонения плана, анализ цепочки инструментов, политики и минимальные права. Архитектура должна локализовать последствия даже при пропуске атаки.
Проверяйте политикой каждый вызов инструмента
Модель может предложить действие в типизированной структуре. Код обязан проверить название операции, аргументы, пользователя, tenant, владельца записи, лимиты, адрес назначения и состояние процесса.
При интеграции AI с CRM не разрешайте модели строить произвольные запросы или выбирать tenant. Откройте узкие функции: прочитать один разрешённый лид или подготовить одно обновление.
Используйте короткоживущие credentials и минимальный scope. Успешная инъекция должна упереться в жёсткую границу прав, а не получить всю учётную запись сотрудника.
Проверяйте ответ модели как враждебный ввод
Ответ AI может содержать сломанный JSON, опасный HTML, выдуманный URL, SQL или команду для другой системы. Не исполняйте и не отображайте его без проверки для конкретного контекста.
OWASP о неправильной обработке ответов требует относиться к сгенерированному содержимому как к пользовательскому вводу до передачи дальше.
Используйте schemas, allowlists, escaping, параметризованные запросы и отдельные parsers. Ответ модели нельзя напрямую передавать shell, базе, браузеру или API отправки сообщений.
Требуйте осмысленное подтверждение важных действий
Рецензент должен видеть, что произойдёт, с какой записью или получателем, какие данные уйдут и почему AI предложил действие. Общая кнопка после выполнения не является контролем.
Отправка, удаление, изменение прав, возвраты, публикация и подписание остаются вне автономного режима, пока отдельная оценка риска не обосновала другое.
Такой же рубеж защищает обработку документов с AI: извлечение автоматическое, а запись в бухгалтерскую или договорную систему проходит проверку.
Тестируйте процессы, а не набор хитрых фраз
Хороший тест начинается с бизнес-цели и ожидаемой политики, затем враждебный контент подаётся через каждый входной канал.
- прямая команда игнорировать задачу;
- скрытые и разделённые инструкции в документах;
- команды из базы знаний;
- враждебный текст из инструмента или сайта;
- необычная последовательность tool calls;
- попытки получить секреты, данные другого клиента или внешний эффект.
Наблюдайте за решениями и ограничивайте последствия
Логируйте источник недоверенного контента, решения политик, предложенные tool calls, подтверждения, отказы и итоговые эффекты. Не складывайте секреты и полные документы в общие логи.
Подготовьте kill switch для каждого коннектора, отзыв короткоживущих прав, остановку очереди и минимальные данные для воспроизведения ошибки.
Эти меры должны совпадать с архитектурой защиты данных компании. Инъекция становится опасной, когда достигает информации, не нужной процессу.
Используйте детекторы как один слой
Классификаторы атак и model guardrails снижают риск, но пропуски и новые шаблоны неизбежны. Они дополняют права, валидацию и подтверждение, а не заменяют их.
NIST Generative AI Profile связывает риски с функциями управления, картирования, измерения и контроля. Для injection нужен тот же цикл: понять контекст, испытать защиту, наблюдать изменения и поддерживать план ответа.
Как я не позволяю содержимому статьи стать инструкцией
В автоматизированном блоге страницы источников и HTML статьи считаются содержимым. Фраза внутри страницы не может сменить разрешённый API-метод, добавить адрес назначения или раскрыть bearer token.
У кода фиксированная последовательность: загрузить именованную картинку, создать draft, прочитать его, отправить полное обновление и проверить публичные страницы. Модель готовит данные, но прочитанный контент не переопределяет шаги.
Такое разделение надёжнее просьбы к модели быть осторожной. Полномочия находятся в коде и credentials, документы остаются документами.
Вопросы и ответы
Prompt injection и jailbreak — это одно и то же?
Понятия пересекаются, но бизнес-угроза шире. Инъекция использует ввод пользователя или внешний контент, чтобы изменить поведение приложения, включая инструменты и доступ к данным.
Поможет ли более строгий system prompt?
Он полезен, но не является контролем доступа. Нужны минимальные права, проверки политик, валидация и подтверждение вне модели.
Почему опасны письма и PDF?
В них может быть текст, который модель примет за команду, хотя приложение должно было использовать его только как материал для чтения.
Можно ли агенту автоматически отправлять сообщения?
Только после отдельной оценки риска, узких правил адресатов и содержимого, валидации, лимитов, мониторинга и испытанного отката. Безопаснее начинать с черновиков.
Что руководителю спросить до запуска?
Что система читает и меняет, какие входы недоверенные, где работает жёсткая политика, что требует подтверждения и как быстро отключается один коннектор.