ИИ-агент — это языковая модель, которая не просто отвечает текстом, а совершает действия: вызывает инструменты и API, читает и пишет файлы, выполняет код, ходит в интернет. Это одновременно самый полезный и самый опасный класс ИИ-систем: если агента удаётся заставить действовать через prompt-инъекцию, его полномочия превращают утечку в реальный ущерб. Собрали 7 правил, которые снижают риск на порядок.
Почему агент опаснее чат-бота
Обычный чат-бот в худшем случае скажет лишнее. Агент с инструментами может отправить письмо, изменить запись в базе, выполнить команду или потратить деньги. В терминах OWASP LLM это сочетание двух угроз — Excessive Agency (LLM06) и Prompt Injection (LLM01). Самые дорогие инциденты живут именно на их стыке: косвенная инъекция в обрабатываемом документе → агент выполняет действие атакующего своими правами.
7 правил защиты ИИ-агента
1. Принцип минимальных привилегий
Агенту нужен ровно тот набор инструментов и прав, без которого он не решит задачу, — и ни одним больше. Уберите «на всякий случай» доступ к shell, файловой системе и внешней сети. Каждый лишний инструмент — это плюс к поверхности атаки.
2. Подтверждение критичных действий
Необратимые операции — отправка сообщений, платежи, удаление данных, изменение прод-конфигурации — должны требовать явного подтверждения человека (human-in-the-loop), а не выполняться автономно по решению модели.
3. Изоляция инструментов и песочница
Каждый инструмент — в изолированном окружении с ограниченными правами. Выполнение кода — только в песочнице (контейнер без доступа к секретам, метаданным облака и внутренней сети). Помните урок SSRF: агент с доступом в интернет — это потенциальный доступ к 169.254.169.254.
4. Защита от косвенных инъекций
Считайте любой контент, который агент обрабатывает автоматически (письма, документы, веб-страницы, ответы API), недоверенным. Именно через него проходит косвенная инъекция. Явно разделяйте «инструкции системы» и «данные для обработки».
5. Валидация ввода и вывода
Проверяйте не только то, что приходит агенту, но и то, что он передаёт дальше — в инструменты, API и пользователю. Вывод модели — это недоверенные данные, а не готовая к исполнению команда. Особенно опасны сгенерированные командные строки и SQL.
6. Логирование и мониторинг действий
Пишите полный аудит: какие инструменты вызывал агент, с какими аргументами, по какому запросу. Аномалии (внезапный доступ к чувствительным операциям, всплеск вызовов) должны триггерить алерты — это ваш последний рубеж, если инъекция всё-таки сработала.
7. Регулярное состязательное тестирование
Защита, не проверенная атакой, — это предположение. Регулярно прогоняйте Red Team против агента: пытайтесь захватить его действия так, как это сделал бы злоумышленник, — через инъекции в данные, злоупотребление инструментами, обход песочницы.
Экспертное наблюдение: главная ошибка проектирования агентов — «дать доступ пошире, чтобы работал гибче». В нашей практике 9 из 10 критичных находок в агентах — это избыточные полномочия: агент, которому для одной задачи выдали ключи от всего. Урезание прав закрывает больше рисков, чем любой фильтр.
Мини-модель угроз перед запуском
- Какие инструменты у агента и что худшее он может ими сделать?
- Откуда в контекст попадают недоверенные данные (документы, веб, письма)?
- Что произойдёт, если злоумышленник полностью контролирует один входящий документ?
- Какие действия необратимы и требуют подтверждения человека?
Эти вопросы — основа харденинга ИИ-систем. Найти уязвимости поможет тестирование безопасности ИИ-агентов.
Ваш ИИ-агент имеет доступ к проду или данным клиентов?
Проверим, можно ли захватить его действия через инъекцию, и поможем закрыть риски изоляцией и минимизацией прав.
Читайте также: Prompt-инъекции, Защита и харденинг ИИ.