Как защитить ИИ-агента: 7 практических правил безопасности

ИИ-агент — это языковая модель, которая не просто отвечает, а совершает действия: вызывает инструменты и API, читает и пишет файлы, выполняет код, ходит в интернет. Самый полезный и самый опасный класс ИИ-систем: если агента удаётся заставить действовать через prompt-инъекцию, его полномочия превращают утечку в реальный ущерб. И это уже происходит в проде.

Реальные атаки на агентов

• EchoLeak (CVE-2025-32711, 2025). Zero-click уязвимость в Microsoft 365 Copilot: одно письмо с косвенной инъекцией заставляло Copilot самостоятельно собрать чувствительные данные из переписки и слить их наружу — без единого клика жертвы. Первый публично пронумерованный CVE класса «атака на ИИ-агента».
• «Living off Microsoft Copilot» (Black Hat 2024). Исследователь Майкл Баргури показал, как через инъекции превратить корпоративный Copilot в инструмент фишинга и кражи данных — используя его же легитимные полномочия.

Мораль обоих кейсов одна: проблема не в «плохой модели», а в том, что агенту дали доступ к данным и действиям, а недоверенный вход (письмо, документ) он воспринимает как команду. Атакующему не нужен эксплойт — нужен один документ, который агент прочитает.

Почему агент опаснее чат-бота

Чат-бот в худшем случае скажет лишнее. Агент с инструментами — отправит письмо, изменит запись в БД, выполнит команду, потратит деньги. В терминах OWASP LLM это связка Excessive Agency (LLM06) + Prompt Injection (LLM01), и самые дорогие инциденты живут на их стыке.

7 правил защиты ИИ-агента

1. Минимум привилегий. Ровно те инструменты и права, без которых задача не решается. Уберите «на всякий случай» доступ к shell, ФС, внешней сети.
2. Подтверждение критичных действий человеком (human-in-the-loop): платежи, отправка, удаление, изменение прод-конфигурации.
3. Изоляция инструментов и песочница. Выполнение кода — в контейнере без доступа к секретам, к 169.254.169.254 (метаданные облака) и внутренней сети. Помните SSRF: агент с интернетом = потенциальный доступ к ключам.
4. Недоверенный вход. Любой авто-обрабатываемый контент (письма, документы, веб, ответы API) — источник косвенной инъекции; отделяйте инструкции от данных.
5. Валидация ввода и вывода. Особенно опасны сгенерированные модель командные строки и SQL — их нельзя исполнять «как есть».
6. Логирование и мониторинг действий. Полный аудит вызовов инструментов; алерты на аномалии — последний рубеж, если инъекция сработала.
7. Состязательное тестирование. Регулярный Red Team против агента.

Мини-модель угроз перед запуском агента

1. Какие инструменты у агента и что худшее он может ими сделать?
2. Откуда в контекст попадают недоверенные данные (документы, веб, письма, тикеты)?
3. Что произойдёт, если атакующий полностью контролирует один входящий документ?
4. Какие действия необратимы и обязаны требовать подтверждения человека?
5. Есть ли у агента доступ к секретам/метаданным, которого можно избежать?

Экспертное наблюдение: 9 из 10 критичных находок в агентах — это избыточные полномочия. Агент, которому «чтобы работал гибче» выдали ключи от всего. Урезание прав закрывает больше рисков, чем любой фильтр на входе. Проектируйте агента так, будто его вход уже скомпрометирован — потому что рано или поздно так и будет.

Как мы это тестируем

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

Читайте также: Prompt-инъекции, Защита и харденинг ИИ.

Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Пентест ИИ и LLM.