Исследователи Check Point за год нашли 11 уязвимостей в LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework и Google ADK. По данным The Register, проблема шире привычного prompt injection: в ряде случаев фреймворки AI-агентов позволяют контенту, который контролирует атакующий, влиять не только на ответ модели, но и на доверенную логику самой платформы. Для команд, которые уже дали агентам доступ к почте, документам, CRM и внутренним API, это означает простую вещь: ломается не «магия LLM», а слой, на котором держатся корпоративные AI-приложения.
О находках на Black Hat рассказали Ярден Порат и Шахар Таль. Они потратили год не на поиск экзотических трюков против одной модели, а на разбор того, как устроена обвязка вокруг агентов в популярных корпоративных стеках. Итог получился неприятно системным: если баг живет в агентном фреймворке, это дефект не одного продукта, а целого класса приложений, которые на нем собраны. Ирония в том, что список проблем звучит до боли знакомо любому AppSec-инженеру: insecure deserialization, SSRF, path traversal, use-after-free. Старые баг-классы просто переехали под новую вывеску.
Главный тезис Check Point выглядит трезво: prompt injection надо считать не исключением, а исходным условием. Атакующий документ, письмо или сообщение почти наверняка рано или поздно попадет в контур агента. Вопрос не в том, можно ли подсунуть модели вредный текст, а в том, что фреймворки AI-агентов делают с этим текстом дальше. По словам исследователей, многие из них не удерживают недоверенный контент в плоскости данных: он протекает в оркестрацию, память, состояние, маршрутизацию задач и системные инструкции. После этого спор о качестве guardrails быстро заканчивается и начинается обычная эксплуатация доверенной серверной логики.
Самый показательный пример связан с Microsoft Agent Framework. Check Point нашла критическую уязвимость в механизме checkpoint-ов, то есть снимков состояния агента, которые позволяют продолжить работу после сбоя или откатиться к прежнему шагу. Через prompt injection атакующий мог добиться загрузки недоверенных сериализованных данных, а дальше срабатывала цепочка до удаленного выполнения кода. Сценарий почти учебный: один пользователь «сажает» полезную нагрузку в состояние, другой откатывает свою сессию, фреймворк поднимает checkpoint, и на сервере уже исполняется чужой код. Microsoft признала проблему, выплатила исследователям $10 тыс. и закрыла показанный путь эксплуатации, но CVE не выпустила, потому что на момент находки фреймворк еще не был общедоступным продуктом.
С Google ADK история вышла менее уютной. Исследователи обнаружили, что встроенный помощник для разработки может писать файлы и остается доступным через HTTP API, хотя в списке приложений он скрыт. Дальше схема прямолинейная: злоумышленник открывает сессию, просит ADK создать агента с Python-кодом, который исполняется во время import, а затем заставляет сервер загрузить этого агента. По версии Check Point, у этого API по умолчанию не было аутентификации, а команда adk deploy cloud_run публиковала тот же интерфейс наружу, поэтому при стандартном разворачивании в Cloud Run он оказывался доступен без учетных данных. Последствия уже совсем не академические: доступ к ключам окружения и сервисному аккаунту Google Cloud внутри контейнера. По словам исследователей, Google сначала не посчитала это багом, позже выплатила $3 133,70 и внесла частичное исправление, но полного закрытия проблемы и CVE на момент публикации не было. Суммарно за найденные уязвимости команда получила $17 133,70.
Самая неприятная часть этой истории в том, что она не сводится к спору Microsoft против Google или LangChain против CrewAI. Шахар Таль формулирует проблему иначе: если бы одна платформа была явным исключением, разговор шел бы о конкретном вендоре. Но одни и те же баг-классы повторяются во всех протестированных стеках. Это уже сигнал для рынка: вокруг AI-агентов растет инфраструктурный слой, который продается как удобная сборка памяти, инструментов, роутинга и управления состоянием, но по факту часто наследует худшие привычки старого серверного кода. Контекст тут тоже важен. Еще недавно большинство команд обсуждали prompt injection как проблему уровня «модель сказала не то». Но архитектура агентов изменила ставки: у них есть память, откат состояния, внешние инструменты, файловые операции, доступ к облачным сервисам и API без участия человека. Если входные данные могут дотянуться до trusted-логики, злоумышленнику уже не нужно спорить с моделью — достаточно аккуратно направить фреймворк туда, где он и сам умеет ломаться.
Для разработчиков и ИТ-руководителей вывод довольно приземленный. Если команда внедряет фреймворки AI-агентов, threat model надо строить не вокруг одной лишь защиты от prompt injection. Проверять придется и более скучные вещи: как сериализуется и восстанавливается состояние, кто имеет доступ к внутренним HTTP-эндпоинтам, какие инструменты доступны агенту по умолчанию, с какими правами живет контейнер, можно ли через импорт, плагины или расширения подсунуть исполняемый код, где лежат API-ключи и сервисные учетные записи. Отдельный вопрос к «удобным» дефолтам: если помощник скрыт в интерфейсе, но доступен через API, это не особенность UX, а поверхность атаки.
Для бизнеса здесь тоже нет ничего абстрактного. Когда поставщик обещает, что агент будет читать почту, открывать тикеты, менять записи в CRM и писать код, он фактически просит доверить фреймворку права уровня внутреннего сотрудника, а иногда и выше. В такой модели баг в оркестрации быстро превращается в инцидент с секретами, клиентскими данными и инфраструктурой. Следующий большой спор в AI-безопасности, похоже, будет не о том, можно ли еще раз обмануть модель, а о том, готовы ли вендоры признать фреймворки AI-агентов security-critical слоем и перестать относиться к доверенной обвязке как к второстепенной детали реализации.