AI Security агентных систем: риски, которые нельзя закрыть промптом

По состоянию на 30 июня 2026 года AI Security агентных систем уже нельзя сводить к jailbreak-промптам и фильтру токсичных ответов. Агент отвечает текстом и одновременно читает почту и документы, вызывает инструменты, пишет файлы, ходит в API, держит память и иногда передаёт результат другим агентам.

AI Security в этом контексте — практика защиты ИИ-систем и агентных контуров от prompt injection, утечек данных, атак на цепочку поставки, чрезмерных полномочий и каскадных ошибок в инструментах. Главная мысль неприятная: системный промпт помогает задать поведение, но не становится границей безопасности.

Поводом для этого разбора стало свежее интервью на Habr с автором PWN AI о безопасности LLM и агентов. Задача этого материала — собрать практическую рамку, а не пересказать интервью. Раньше мы уже разбирали безопасность агентских систем через MEMO, RAG и инфраструктурные риски. Теперь фокус уже: как строить практическую рамку AI Security вокруг агентного runtime.

Что изменилось в 2026 году

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

OWASP в LLM Top 10 2025 отдельно выделяет Excessive Agency: уязвимость, при которой LLM-система получает слишком много функций, прав или автономии. Это ровно агентная проблема. Чем больше инструментов и чем шире доступ, тем больше радиус поражения у одной неверной команды.

Другой слой — недоверенный контекст. Агент может читать веб-страницу, письмо, README, PDF, картинку, результат поиска или ответ другого агента. Всё это выглядит как «данные», но для LLM оно одновременно может стать инструкцией. Поэтому фраза «мы спрячем правила в системный промпт» быстро перестаёт быть инженерной защитой.

Prompt injection: прямые и косвенные атаки

OWASP LLM01:2025 делит prompt injection на прямые и косвенные атаки. Прямая атака идёт через пользовательский ввод: злоумышленник сам пишет модели инструкцию, которая должна изменить поведение. Косвенная атака опаснее для агентов: вредная инструкция лежит во внешнем источнике, который агент сам подтягивает в контекст.

Классический пример — письмо, веб-страница или документ с невидимой для пользователя инструкцией. Пользователь просит агента «суммировать последние письма», агент читает письмо атакующего и воспринимает чужую команду как часть задачи. Если рядом есть доступ к внутренним данным и возможность отправлять наружу ссылки, сценарий уже похож не на игрушечный jailbreak, а на нормальную цепочку атаки.

EchoLeak показал именно этот класс риска на Microsoft 365 Copilot. В разборе уязвимости CVE-2025-32711 исследователи описывают zero-click prompt injection: специально подготовленное письмо могло привести к утечке данных без клика со стороны пользователя. Важная оговорка: по опубликованной хронологии Microsoft закрыла конкретную уязвимость до публичного раскрытия. Но сам урок шире. Если агент соединяет внешнюю почту, внутренние документы и автоматическую загрузку контента, каждый из этих переходов становится частью threat model.

Мы отдельно разбирали prompt injection и supply-chain атаки на LLM-агентов. Для этой статьи важнее другой вывод: prompt injection нельзя закрыть только промптом. Нужны границы на уровне данных, прав, выходных каналов и инструментов.

MCP и инструменты расширяют поверхность атаки

MCP полезен тем, что стандартизирует доступ модели к инструментам и внешним данным. Но любая стандартизация инструментов делает атаки повторяемее. Если агент выбирает функцию по описанию, схеме и контексту, то описания функций, MCP-серверы, OAuth-переходы и локальные процессы тоже попадают в периметр безопасности.

Официальные Security Best Practices для Model Context Protocol прямо перечисляют риски MCP-реализаций: confused deputy, session hijacking, token passthrough, локальная компрометация MCP-сервера, SSRF и проблемы с authorization URL. В разделе про URL validation документ требует разрешать только безопасные схемы для authorization URL и не открывать такие URL через shell-команды. По сути это обычная прикладная безопасность, которая теперь стала частью агентного стека.

Здесь рядом живёт и function hijacking в MCP: агент может выбрать не тот инструмент или выполнить действие, которое выглядит разрешённым в описании функции, но нарушает реальную политику системы. Поэтому tool description не должен быть единственным механизмом контроля.

Supply chain теперь включает модели, skills и MCP-серверы

В обычной разработке supply chain — это зависимости, пакеты, сборка и доступы. В LLM-системах слой шире. OWASP LLM03:2025 относит к рискам цепочки поставки сторонние компоненты, предобученные модели, датасеты, LoRA-адаптеры, model repositories и deployment-платформы.

У агентов к этому добавляются skills, tool hubs, MCP-серверы и готовые плагины. Разработчик может поставить сервер «для GitHub», «для браузера» или «для файловой системы», а вместе с ним получить лишние права, неочевидные сетевые вызовы или вредную инструкцию в metadata. Проблема знакомая по npm и PyPI, но у агентов она неприятнее: компонент может влиять не только на код, но и на принятие решений моделью.

Практический вывод простой. MCP-сервер и skill нужно проверять как обычную зависимость с доступом к данным: кто автор, какая версия, какие scope, какие сетевые вызовы, какие файлы доступны, что логируется, есть ли способ отозвать права без поломки всего workflow.

Где ставить реальные границы

AI Security агентных систем начинается с инвентаризации действий, а не с идеального промпта. Какие операции агент вообще может выполнить? Какие данные он может читать? Какие внешние адреса доступны? Что считается опасным действием? На каком шаге нужен человек?

OWASP LLM06 даёт хорошую триаду для excessive agency: лишняя функциональность, лишние разрешения и лишняя автономия. Если агенту нужно читать письма, у него не должно быть функции отправки. Если он пишет черновик поста, публикация должна требовать подтверждения. Если он читает базу продуктов, ему не нужен доступ на UPDATE и DELETE.

Guardrails не заменяют архитектуру безопасности

Guardrails полезны как сигнал и дополнительный слой проверки. Но это не периметр. Фильтр может ошибиться, не понять бизнес-контекст, заблокировать нормальный ответ или сам стать каналом доставки вредной инструкции. Чем сложнее агентный цикл, тем хуже работает представление «поставим один классификатор на вход и выход».

Гораздо надёжнее считать все входы и выходы недоверенными. Retrieved-контент не должен автоматически становиться инструкцией. Ответ модели не должен автоматически становиться командой. Tool call должен проходить обычную авторизацию downstream-системы, а не доверять тому, что модель «решила правильно».

В этом месте AI Security сближается с классической безопасностью: least privilege, complete mediation, allowlist, аудит, egress control, sandboxing. Разница только в том, что между пользователем и системой появился вероятностный интерпретатор естественного языка.

Длинные сессии и каскадные атаки

Долгоживущие агенты опасны не только из-за промптов. В длинной сессии накапливаются ошибки контекста, старые инструкции, промежуточные файлы, память и результаты tool calls. Если один агент передаёт другому скомпрометированный фрагмент, атака начинает жить уже не в одном окне чата, а в цепочке.

ClawWorm — хороший пример того, почему multi-agent security нельзя оставлять на потом. Препринт arXiv, отправленный 16 марта 2026 года и обновлённый 20 марта, описывает самораспространяющуюся атаку на агентную среду OpenClaw. Авторы пишут, что OpenClaw имел больше 40 000 активных инстансов, а тестирование ClawWorm включало 1 800 прогонов и показало aggregate success rate 64,5% в контролируемой среде.

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

Если в статье нужен отдельный блок про red teaming, рядом стоит держать RIFT-Bench для проверки безопасности AI-агентов. Но тесты не отменяют архитектурных ограничений. Они лишь показывают, где агент уже вышел за рамки.

Минимальный чеклист для продакшена

• Опишите доверенные и недоверенные источники. Письмо от внешнего контрагента, веб-страница и README из репозитория не должны иметь тот же статус, что системная политика.
• Сделайте no-tool нормальным вариантом. Агент не обязан вызывать инструмент только потому, что инструмент доступен.
• Разделите чтение и запись. Read-only scope должен быть режимом по умолчанию; запись, удаление, отправка и платежи требуют отдельного разрешения.
• Проверяйте tool calls вне модели. Downstream-система должна сама решать, разрешён ли запрос, а не перекладывать это на LLM.
• Ограничьте egress. Автоматические внешние URL, картинки, webhooks и произвольные HTTP-запросы — главный путь для тихой утечки.
• Ведите журнал действий. Нужны финальные ответы, tool calls, источники данных, scope, approvals и отказы.
• Ставьте TTL на сессию и память. Долгий контекст должен пересобираться, а не бесконечно расти.
• High-impact действия отдавайте человеку. Публикация, платежи, удаление, массовая рассылка и изменение прав не должны выполняться автономно.

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

Вывод

AI Security агентных систем выходит далеко за пределы старого jailbreak. Агентные системы соединяют LLM с данными, инструментами, памятью и реальными действиями. Поэтому основной риск лежит не внутри одной модели, а в границах между моделью, контекстом и внешними системами.

Сильная защита начинается с простого принципа: промпт не должен быть единственной линией обороны. Модель может помогать принимать решение, но права, выходящие каналы, tool calls, память и опасные действия должны ограничиваться обычными инженерными механизмами. Чем раньше команда это признает, тем меньше шанс, что «умный помощник» станет самым привилегированным и самым слабо контролируемым процессом в компании.

Источники и дата проверки

Факты в материале проверены 30 июня 2026 года. Для быстро меняющихся деталей по моделям, протоколам и уязвимостям нужна повторная проверка перед публикацией или обновлением.

• Habr: «Агенты удаляют файлы, сливают данные и сами себя взламывают» — инфоповод и тезисы интервью о рисках LLM и агентных систем.
• OWASP Top 10 for LLM Applications 2025 — таксономия LLM01, LLM03, LLM06 и соседних рисков.
• OWASP LLM01:2025 Prompt Injection — различие direct и indirect prompt injection.
• OWASP LLM03:2025 Supply Chain — риски моделей, датасетов, adapters и deployment-платформ.
• OWASP LLM06:2025 Excessive Agency — excessive functionality, permissions и autonomy.
• MCP Security Best Practices — security considerations, attack vectors и mitigations для MCP.
• MCP Authorization specification — требования к authorization, metadata и security considerations.
• EchoLeak: zero-click prompt injection in Microsoft 365 Copilot — case study CVE-2025-32711 и defense-in-depth выводы.
• ClawWorm: Self-Propagating Attacks Across LLM Agent Ecosystems — исследование каскадных атак на LLM-агентов.

Читайте также

• Безопасность агентских систем: атаки, GPU-часы и MEMO
• Prompt injection и supply-chain атаки на LLM-агентов
• Function hijacking в MCP: как ломают tool calling у AI-агентов