Один промпт, один агент, целая учётная запись AWS: внутри AgentCorruption на Amazon Bedrock AgentCore

8 октября 2026 года, Zenity Labs раскрыла AgentCorruption: цепочка уязвимостей в Amazon Bedrock AgentCore, управляемой платформе AWS для развертывания и запуска ИИ-агентов, которая позволяла одной подсказке на естественном языке, отправленной одному публичному агенту, взять под контроль всех агентов AgentCore в том же аккаунте и регионе AWS. Исследование было опубликовано вместе с докладом на SecTor 2026 в Торонто, где директор по исследованиям безопасности Zenity, Tamir Ishay Sharbat, представил его (Dark Reading, 8 октября 2026 года). Собственный отчет Zenity, авторами которого указаны Sharbat, Lana Salameh, Dmitry Lozovoy и João Donato, начинается с механизма: агент AgentCore, имеющий любой инструмент, способный выполнить исходящий запрос, можно заставить обратиться к AWS Instance Metadata Service (IMDS) по локальному адресу 169.254.169.254, который возвращает временные учетные данные для собственной роли исполнения агента. Zenity заявляет, что экспортировала эти учетные данные на свою машину и подтвердила, что они работают оттуда. Идентификатор CVE не был присвоен.

В архиве это зафиксировано как уязвимость — нечто обнаруженное, но не обязательно использованное — с высокойстепенью серьёзности, уровнем уверенности A, отсутствием зафиксированного реального ущерба и подтверждённым участием ИИ. Стороны расходятся в трактовке, хотя согласны относительно поведения: AWS заявила Dark Reading, что исследование «неточно изображает ожидаемое и документированное поведение как уязвимость».

Чем на самом деле была цепь

AgentCore упаковывает каждого агента в контейнер и для каждой сессии запускает его в Firecracker MicroVM. Первый пост Zenity в этой серии воспроизводит всю точку опоры с помощью запроса на простом языке к тестовому агенту, созданному с помощью Strands SDK, открытого фреймворка для агентов от AWS, который поставляется со встроенным инструментом HTTP-запросов и инструментом оболочки. МикроВМ не ограничивала трафик к службе метаданных, поэтому запрос исходил изнутри экземпляра, и IMDS ответил на него. После этого исследователи прошли по эндпоинтам: имя роли IAM, сами временные учетные данные STS, эндпоинт пользовательских данных — который вернул идентификатор аккаунта, полные ARN, URL среды выполнения и Amazon Elastic Container Registry (ECR) URI образа агента — и теги экземпляра, включая цепочку сертификатов mTLS, закрытый ключ и предподписанный URL к внутреннему хранилищу. Zenity утверждает, что тот же результат был получен через инструмент оболочки, потому что сбой изоляции находится на уровне платформы, а не в каком-либо отдельном инструменте.

Две детали в этой последовательности легко упустить при чтении. Учётные данные не остались в песочнице: Zenity экспортировала их за пределы AgentCore и выполнила вызов идентификации AWS, который вернулся как принятая роль агента. А украденная роль могла загрузить образ контейнера — именно так исходный код агентов стал доступен для чтения. В публикации Zenity отмечается, что образы обычно содержат жёстко закодированные ключи, оставшиеся токены и конфигурацию, которые никогда не должны были быть вшиты, и что загруженный образ — это карта лежащей в основе бизнес-логики.

Роль по умолчанию — это место, где точка опоры превратилась в учетную запись.

Вторая уязвимость, о которой сообщалось отдельно, заключается в том, что роль выполнения, которую AgentCore по умолчанию назначал агентам, не была ограничена одним агентом. Zenity описывает разрешения, распространяющиеся на все ресурсы AgentCore в учетной записи и регионе, включая bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent а также, на завершающем этапе цепочки, связанном с учетными данными, bedrock-agentcore:GetResourceApiKey и secretsmanager:GetSecretValue.

Перечислимость превратила эти подстановочные знаки в список целей. Zenity использовала разрешение роли logs:DescribeLogGroups, поскольку AgentCore присваивает группе журналов CloudWatch каждого агента имя /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, и выводила идентификаторы агентов из этих имён групп журналов. Имена репозиториев ECR следовали соглашению, которое заметили исследователи — bedrock-agentcore-<agent_name> — поэтому можно было извлечь образ каждого агента в регионе. Ресурсы памяти обнаруживались таким же образом, по шаблону группы журналов /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, а разрешения роли ListActors, ListSessions и ListEvents давали идентификаторы акторов и сессий, необходимые для чтения содержимого бесед.

В отчёте Zenity приводится конкретная демонстрация бокового перемещения: вход через публично доступного агента, обнаружение инструментов billing_agent в том же регионе, обнаружение файла с именем billing.json и его эксфильтрация через инструмент чтения файлов. В пресс-релизе тот же сценарий описывается в общих чертах — злоумышленник, входящий через доступного из интернета агента службы поддержки клиентов, может перейти к внутреннему финансовому агенту, развёрнутому в том же регионе, вызвать его и получить доступ к его данным, инструментам, связанным с ним учётным данным и приватным беседам.

Память была той частью, что пережила промпт

AgentCore Memory хранит сам разговор как кратковременную память и сохраняет извлечённые записи как долговременную память, используя стратегии с названиями SEMANTIC, USER_PREFERENCE, SUMMARIZATION и EPISODIC. В Zenity использовали CreateEvent для записи событий разговора в ресурсы памяти других агентов. В своей публикации они аккуратно описывают, что этот примитив может, а что не может: CreateEvent не позволяет вызывающему выбрать долговременное пространство имён или напрямую перезаписать запись — настроенные стратегии целевой памяти решают, что будет извлечено и куда это попадёт. Zenity также описывает, что DeleteEvent использовался для удаления событий с результатами инструментов, чтобы агент сделал неверный вывод из-за отсутствующих данных, и для заметания следов путём удаления события, которое создало память.

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

Учётные данные за пределами AWS

Последняя публикация в серии замыкает тему подключённых инструментов. AgentCore Identity и Outbound Auth хранят учётные данные инструментов как секреты в AWS Secrets Manager, под именами, составленными из названия провайдера и фиксированного шаблона, такого как bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity восстановила названия провайдеров, спарсив исходный код агента, ранее извлечённый из ECR, а другие восстановила перебором: по её данным, стандартный пятисимвольный суффикс генерируется на стороне клиента из цифр и строчных букв, что даёт 2 x (10+26)^5 = 120,932,352 комбинаций для двух типов провайдеров. При той скорости запросов, которую она могла поддерживать к Secrets Manager, по словам Zenity, полный перебор занимает несколько часов — дольше, чем живут учётные данные STS, — поэтому она построила цикл, который заново запрашивал свежие учётные данные у конечной точки IMDS агента по мере истечения старых. Zenity добавляет, что переменные окружения были доступны для чтения через конечную точку user-data метаданных, при этом каждое имя имело префикс CONTAINER_ENV_, включая ключ, который агент использует для аутентификации у своего провайдера модели, и что вызов каждого обнаруженного агента с подходящим промптом позволял массово собирать эти значения.

Установлено и оспаривается на формальном основании.

Установленное узко и конкретно. Агенты AgentCore могли получить доступ к IMDS и получить временные учётные данные своей собственной роли выполнения — AWS это не оспаривает, описывая в своём заявлении как «документированное и ожидаемое». Стандартная роль выполнения имела разрешения, действовавшие на уровне аккаунта и региона, а не одного агента; с тех пор AWS изменила её, и Zenity заявляет, что её собственное тестирование подтвердило сокращение. Это исследование — демонстрация, а не наблюдаемая кампания: Шарбат рассказал Dark Reading, что Zenity не обнаружила доказательств эксплуатации этой уязвимости в реальных условиях до исправления, частично объяснив это сложностью выявления организаций, которые запускают агентов на AgentCore, и добавив, что он «на 100% уверен, что есть способы это сделать».

Спорным является вопрос о том, следует ли вообще что-либо из этого называть уязвимостью. Заявление AWS, в том виде, в каком оно было предоставлено Dark Reading и The Next Web, гласит: «AWS осведомлена об исследовании, опубликованном об Amazon Bedrock AgentCore, в котором ожидаемое и документированное поведение неточно представляется как уязвимость. Агент может получить доступ к ресурсам в другом аккаунте AWS, только если разработчик явно предоставит разрешения как для роли выполнения агента, так и для целевого ресурса». Заявление AWS, воспроизведённое в собственных публикациях Zenity, сохраняет суть первого предложения — «описанное поведение является документированным и ожидаемым» — и добавляет, что клиентам следует предоставлять ролям выполнения только те разрешения, которые нужны их агентам. В основе разногласия лежат два момента. AWS описывает границу с точки зрения доступа к ресурсам в другом аккаунте AWS, тогда как находка Zenity касается агентов внутри одного аккаунта AWS и одного региона; а роли, которые описывает Zenity, происходили из настроек платформы по умолчанию, а не из политики, написанной клиентом вручную.

Поправку The Next Web к собственной статье стоит зафиксировать, потому что она показывает, как утверждение было уточнено кем-то помимо самих исследователей. Сначала издание опубликовало, а затем исправило заголовок, в котором говорилось, что исследователи перехватили контроль над каждым агентом AgentCore в регионе; в исправленной версии говорится, что исследование охватывало агентов в пределах одной учетной записи AWS и одного региона, и отмечается, что в более раннем заголовке утверждение исследователей было подано как факт.

Хронология раскрытия информации

Zenity подала два отчёта вместо одного, и ответы на них были разными. Отчёт о доступе к IMDS был отправлен 25 декабря 2025 года; AWS закрыла его 12 апреля 2026 года как «информационный», написав, что AgentCore использовала IMDSv2 только с 14 февраля 2026 года, при этом вновь развёрнутые агенты запускаются именно так. Эта правка важна для конкретных деталей данного исследования, поскольку IMDSv2 требует сессионный токен при каждом запросе и ломает простой неаутентифицированный запрос, который исследователи использовали для получения учётных данных. Второй отчёт — о роли по умолчанию и её радиусе поражения — был отправлен 12 января 2026 года. AWS сообщила Zenity 25 февраля 2026 года, что команда работает над этим, тогда как роль оставалась без изменений; Zenity пересмотрела роль снова 22 июня 2026 года и обнаружила, что её разрешения не изменились. Финальная проверка 29 сентября 2026 года показала, что роль существенно сузилась, и в пресс-релизе Zenity говорится, что удаление затронуло вызов других агентов, чтение приватных переписок и доступ к секретам в AWS Secrets Manager, а другие разрешения также были значительно ограничены. В собственных публикациях Zenity отмечается, что с тех пор AWS сделала IMDSv2 значением по умолчанию для развёртываний AgentCore и что обе стороны сотрудничали в этом процессе.

Что неизвестно

Zenity не публиковала, сколько агентов или организаций работали с ролью по умолчанию в период между февральским изменением IMDSv2 и сужением в конце сентября, и ни в одном из цитируемых источников не утверждается, что какие-либо данные клиентов были раскрыты за пределами собственной среды исследователей. Изменение IMDSv2 применяется к агентам, развёрнутым после 14 февраля 2026 года, согласно AWS, как сообщает Zenity; что это означает для агентов, развёрнутых до этой даты, в рассмотренных здесь источниках не указано. В архиве не зафиксировано реального вреда, и источники поддерживают такую трактовку, описывая демонстрацию и то, что AWS оспаривает ярлык уязвимости, а не сообщает о собственном инциденте.

Шарбат сообщил Dark Reading, что Zenity сейчас изучает другие облачные платформы на предмет аналогичных проблем с доступом к метаданным и что компания пока не называет их. Его главный вывод касается разрешений, а не только службы метаданных: «Даже если кто-то получит доступ к IMDS, радиус поражения будет намного меньше».

Почему эта запись хранится

AgentCorruption примечателен тем, что эндпоинты метаданных — это новая идея. Шарбат обратил внимание аудитории SecTor на утечку в Capital One в 2019 году, когда SSRF добрался до IMDS и обернулся кражей учетных данных, и охарактеризовал это как нарушение принципа наименьших привилегий того же типа. Новым является то, кто выполняет запрос. Запрос, который создал идентичность AWS, был сделан агентом AWS, выполнявшим то, о чем его попросили, на простом языке, через инструмент, который ему дали, чтобы он мог быть полезен, — и агент передал ответ обратно. Двумя условиями, которые превратили это в проблему в масштабе всей учетной записи, были эндпоинт метаданных, который песочница не заблокировала, и роль по умолчанию, более широкая, чем агент, который ею обладал.

Полное исследование, включая пятичастную серию технических материалов и демонстрационное видео, доступно по ссылке из пресс-релиза Zenity от 8 октября 2026 года. Эта запись — одна из записей о задокументированных инцидентах с агентами в архиве инцидентов ИИ, где каждая запись содержит собственные источники, серьезность, степень уверенности и флаг спорности — поля, которые позволяют отличить спор вендора о трактовке, как здесь, от оспариваемого вывода о причинении вреда.

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