Исследователи Check Point заявили, что за год нашли 11 уязвимостей в LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework и Google ADK. Для компаний, которые уже пустили ИИ-агентов в почту, документы, CRM и внутренние API, это неприятный сигнал: проблема не сводится к одному лишь prompt injection, потому что вредный текст может дотянуться до памяти, состояния и инструментов агента.
Старые баги переехали в агентную обвязку
О находках Ярден Порат и Шахар Таль рассказали на Black Hat USA 2026. Их тезис звучит без лишней мистики: атакующий почти наверняка сможет подсунуть агенту документ, письмо или сообщение с вредными инструкциями. Реальный вопрос в другом: что фреймворк делает с этим вводом дальше.
Если недоверенный текст просачивается из уровня данных в оркестрацию, память и маршрутизацию задач, начинается уже не спор о «капризах модели», а обычная эксплуатация серверной логики. И набор проблем знаком любому инженеру по безопасности приложений: SQL-инъекции, небезопасная десериализация, SSRF, чтение произвольных файлов и ошибки в работе со снимками состояния.
Публичный пример уже есть у LangGraph
Самый хорошо задокументированный кейс Check Point уже опубликовала отдельно: в июне 2026 года компания описала три уязвимости в LangGraph. Две из них, SQL-инъекцию в SQLite-checkpointer и небезопасную десериализацию msgpack, можно было связать в цепочку до удалённого выполнения кода. Третья уязвимость затрагивала Redis-вариант того же слоя хранения состояния.
Это важная деталь для рынка: память агента и история его шагов, не «служебная мелочь», а полноценная поверхность атаки. Если приложение отдаёт наружу методы вроде просмотра истории состояния и принимает пользовательские фильтры как есть, злоумышленник получает шанс не просто испортить ответ модели, а исполнить свой код на сервере.
Microsoft и Google показывают ту же проблему с другой стороны
В Microsoft Agent Framework чувствительное место, механизм checkpoints, то есть снимков состояния. В актуальной документации Microsoft прямо пишет, что хранилище checkpoints нужно считать доверенной границей и что загружать данные из недоверенных источников нельзя. Сам по себе этот комментарий показателен: риск уже лежит не в модели, а в том, как платформа сохраняет и восстанавливает состояние агента.
У Google ADK история упирается в API-слой. Документация ADK открыто описывает HTTP-маршруты для списка приложений, сессий и запуска агента. Критичный момент здесь не «скрытый API», а конфигурация доступа: при выкладке в Cloud Run сервис можно держать закрытым с обязательной аутентификацией. Проблемы начинаются, когда команды публикуют агентный API наружу как обычный веб-сервис и оставляют ему слишком широкие права на файлы, переменные окружения и сервисные аккаунты.
Что это значит для рынка
Для российских и СНГ-команд вывод довольно приземлённый. Модель угроз для ИИ-агентов надо строить не только вокруг защиты от prompt injection. Проверять придётся сериализацию и восстановление состояния, права сервисных аккаунтов, доступность внутренних HTTP-эндпоинтов, работу плагинов и импортов, чтение файлов, сетевой доступ из контейнера и набор инструментов, который агент получает по умолчанию. Иначе «удобный помощник» быстро превращается в ещё один привилегированный сервис, который читает почту, ходит в CRM и при этом ломается самыми классическими способами.
После Black Hat рынок вряд ли сможет и дальше делать вид, что фреймворки ИИ-агентов, это просто тонкая обвязка вокруг LLM: слишком много в них уже зависит от обычной, очень земной безопасности бэкенда.
Источники: , , , .