Что делает агент уязвимой категорией
Обычное LLM-приложение — это вопрос и ответ: ущерб от ошибки ограничен содержанием текста. Агентная архитектура выстраивает цепочку «модель — план — инструменты — результат»: модель сама решает, какое действие выполнить, передаёт ему параметры и интерпретирует ответ. Классы рисков здесь те же, что в OWASP LLM Top-10, но у каждого множитель — физическое исполнение. Успешная промпт-инъекция в чате выдаёт лишний текст; в агенте она выдаёт команду на отправку письма или изменение записи в учётной системе.
Вторая особенность — композиция. Агент состоит из модели, памяти, набора инструментов, протоколов связи между узлами. Каждый элемент доверяет соседям, и скомпрометированный компонент тянет за собой всю цепочку. Третья — асинхронность: мультиагентные схемы работают без человека часами, и ущерб накапливается до первой проверки.
Карта угроз по слоям
| Слой системы | Типовая угроза | Вопрос для самопроверки |
|---|---|---|
| Модель | джейлбрейк, утечка системного промпта | проверяли ли поведение на нештатных вводных |
| Инструменты | злоупотребление tool use, инъекция через результат | валидируются ли параметры и ответы |
| Данные | отравление контекста, чужие инструкции в документах | фильтруются ли внешние данные перед контекстом |
| Права | избыточные полномочия агента | что случится при худшем сбое доверия |
| Связи | вредоносный MCP-сервер, подмена endpoint | откуда берётся список серверов и инструментов |
| Надзор | действия без следов | логируются ли шаги агента дословно |
Эта таблица — рабочий инструмент: колонка «вопрос» превращается в чек-пункты внутреннего аудита, а пустые ответы показывают, где контур не спроектирован, а собран по привычке.
Принципы, которые держат конструкцию
Первый принцип — минимальные полномочия. Агенту выдаётся ровно тот набор действий, который нужен сценарию, и ровно на тот срок. Подробно техники разобраны в материале об ограничении полномочий ИИ-агентов.
Второй — изоляция среды исполнения. Песочница для файловых операций, сетевых запросов и кода ограничивает радиус поражения даже при полном захвате логики агента.
Третий — контроль границ доверия. Всё, что попадает в контекст модели извне (страницы, письма, файлы, ответы других сервисов), — это данные, а не инструкции. Техники разделения — в разборе атак на tool use.
Четвёртый — наблюдаемость. Каждый шаг агента журналируется: вход, принятое решение, вызов инструмента, результат. Без этого расследование инцидента превращается в гадание, а мониторинг — в формальность.
Пятый — человек-в-контуре для необратимых действий. Платежи, массовые рассылки, удаления, изменения прав — только через подтверждение оператора.
Корпоративный контур и регуляторная рамка
В enterprise агентные сценарии чаще всего затрагивают персональные и коммерческие данные, поэтому модель угроз полезно сверять с обязательными режимами: 152-ФЗ для персональных данных, требования к защите ГИС по приказу ФСТЭК России от 11.04.2025 № 117 (действует с 01.03.2026). Сфера ИИ получила собственный рамочный закон — Федеральный закон от 26.07.2026 № 243-ФЗ: с 01.09.2026 действуют понятия и меры поддержки, обязанности разработчиков крупных моделей подключаются с 01.03.2027. Корпоративные агенты на чужих фундаментальных моделях в периметр закона, как правило, не попадают, но требования к защите данных вокруг агента это не отменяет — обзор темы есть в разделе о законе 243-ФЗ.
С чего начать внедрение защиты
- Инвентаризация: перечень агентов, их инструментов и прав — в формате реестра ИИ-активов.
- Классификация сценариев по разрушительности: что агент может испортить безвозвратно.
- Обрезание прав и песочница для верхнего риска.
- Журналирование шагов и алерты на аномалии.
- Регулярные тесты на устойчивость — от базовых прогонов инъекций до полноценного ИИ-RED.
Такой порядок даёт быстрый выигрыш на самых опасных сценариях и не требует переписывать систему целиком.
Три заблуждения, которые дорого стоят
Первое: «агент безопасен, если модель хорошая». Стойкость модели — только один слой; большинство реализуемых сценариев атак использует связки с правами и инструментами, которые от модели не зависят. Второе: «у нас простой сценарий, угроз нет». Простота сценария снижает ущерб, но не канал: агент, читающий почту, атакуется письмом; агент с браузером — страницей. Третье: «защита — задача разработки». Без владельца процесса, без журналов и без тестов разработка закрывает только то, что видит в коде, а инциденты живут между слоями. Проверка этих трёх пунктов — самая дешёвая профилактика, доступная до любых вложений в инструменты.