Один запрос к публичному AI-агенту на Amazon Bedrock AgentCore мог выдать временные AWS-учётные данные, а затем открыть доступ к другим агентам, их контейнерам и пользовательским сессиям в том же регионе. Для команд, строящих корпоративных помощников на AWS, история про безопасность AWS AgentCore — неприятное напоминание: промпт-инъекция и избыточные IAM-права способны превратить чат-бота в точку входа в облачный аккаунт.
Об исследовании Zenity Labs сообщает The Register. Исследователи Тамир Ишай Шарбат и Лана Саламех обнаружили, что развёрнутый через AgentCore агент мог по запросу обратиться к Instance Metadata Service — службе метаданных виртуальной машины. Такой сервис нужен облачной инфраструктуре: через него рабочая нагрузка получает сведения о регионе, сети и конфигурации. В данном случае ответ мог содержать и временные токены IAM-роли самого агента.
Сценарий атаки не требовал доступа к консоли AWS. Достаточно было иметь возможность переписываться с выставленным наружу агентом и попросить его вернуть содержимое URL, указывающего на endpoint метаданных, в JSON. Получив временные учётные данные, атакующий мог отправлять AWS API-запросы уже от имени роли AgentCore. Исследователи описали, как с такими правами перечисляли других агентов в регионе, получали образы контейнеров из Elastic Container Registry и изучали их локально с правами root.
Самая болезненная часть находки — не только доступ к метаданным. По данным Zenity, роль AgentCore по умолчанию была выдана слишком широко: её полномочия распространялись на ресурсы AgentCore во всём регионе, а не на конкретного агента. Поэтому временный токен позволял запускать других агентов, читать сессии, менять память агентов и обращаться к секретам в AWS Secrets Manager. В терминах продуктовой безопасности это уже не утечка одного диалога, а возможный переход от внешнего чата к инфраструктуре целого сервиса.
Через механизм памяти можно было закрепиться надолго. Исследователи утверждают, что создавали записи памяти для других агентов и пользователей; такие данные сохранялись и могли влиять на поведение агента в будущих сессиях. То есть злоумышленник получал не только возможность прочитать разговор, но и шанс незаметно подменить цели помощника. Для AI-систем, которым доверяют поиск по внутренним данным, выполнение операций или работу с клиентскими обращениями, это особенно опасная комбинация.
Почему MicroVM не стала защитной границей
Причиной исследователи назвали недостаточную сетевую изоляцию Firecracker MicroVM, на которой работает AgentCore. Агент мог выступить посредником для SSRF-атаки: модель по инструкции пользователя делает серверный запрос туда, куда сам пользователь обратиться не должен. IMDSv1 исторически считался более рискованным вариантом метаданных именно из-за подобных сценариев. IMDSv2 добавляет механизм получения токена и снижает вероятность эксплуатации через простые SSRF-запросы, но не отменяет необходимость ограничивать доступ и права рабочей нагрузки.
Zenity сообщила AWS о проблемах в декабре 2025 года, а в январе 2026-го отдельно передала сведения об избыточных разрешениях. AWS ответила 12 апреля, что отчёт носит информативный характер, и закрыла его, указав: с 14 февраля AgentCore использует только IMDSv2. Однако проверка исследователей 22 июня показала, что широкие права ещё сохранялись. Финальная проверка 29 сентября, по их данным, подтвердила устранение оставшихся проблем.
Что проверить командам на AWS
Для российских разработчиков и компаний, использующих Bedrock и похожие агентные платформы, эта история не сводится к одному исправленному сервису. Агент с доступом к сети, инструментам и облачным ролям нужно рассматривать как код, который пользователь частично программирует естественным языком. Значит, опасно выдавать ему роль «на всякий случай», разрешать произвольные URL и считать контейнерную изоляцию полной защитой от ошибок в бизнес-логике.
Практический минимум выглядит прозаично, но работает: закреплять IAM-права за отдельным агентом и задачей, сокращать доступ к Secrets Manager и ECR, запрещать или фильтровать обращения к адресам метаданных, разделять среды и регионы по уровню доверия. Отдельно стоит проверять, может ли внешний пользователь заставить агента делать HTTP-запросы, читать внутренние URL, возвращать заголовки, токены или «сырой JSON». В этом классе инцидентов вежливо сформулированная просьба пользователя иногда оказывается эффективнее эксплойта.
После публикации AWS заявила The Register, что исследование Zenity представляет документированное поведение как уязвимость и что для атаки якобы требовалась ошибка разработчика. Изложенный исследователями сценарий с этим объяснением расходится: они говорят об агенте, доступном через чат, сетевом доступе к IMDS и региональных полномочиях роли по умолчанию. Главный вопрос теперь не в том, закрыта ли конкретная цепочка, а в том, успели ли команды пересмотреть доверие к агентам как к обычным приложениям. В эпоху AI-автоматизации у каждого промпта всё чаще появляется собственный IAM-профиль.