Один запрос к публичному AI-чат-боту мог превратить компрометацию одного агента в захват всех агентов организации в аккаунте AWS и том же регионе. Исследователи Zenity Labs обнаружили уязвимость AWS AgentCore, позволявшую получить временные облачные учётные данные через сервис метаданных экземпляра; AWS устранила проблему в феврале.
Об исследовании на конференции SecTor 2026 рассказал директор по исследованиям безопасности Zenity Labs Тамир Ишай Шарбат, сообщает Dark Reading. Речь идёт о Bedrock AgentCore — управляемой AWS-платформе для развёртывания и эксплуатации AI-агентов. Команда Zenity выяснила, что агент, доступный пользователям через чат, можно было склонить к HTTP-запросу во внутренний Instance Metadata Service (IMDS). Ответ сервиса содержал чувствительные данные: временные credentials, идентификаторы экземпляров и конфигурацию.
Такой вектор исследователи назвали AgentCorruption. Его опасность не в очередном «плохом промпте» как таковом, а в связке из prompt injection, сетевой доступности IMDS и слишком широких прав. Агент выполнял запрос из своей среды, поэтому атакующему не требовалось напрямую попадать в VPC или находить отдельную серверную уязвимость. Достаточно было убедить публичного помощника сходить по нужному внутреннему адресу.
Проблема усугублялась архитектурой исполнения. Агенты AgentCore работают внутри Firecracker MicroVM, однако, по данным Zenity, в исследованной конфигурации не хватало сетевой изоляции от службы метаданных. Это напоминает класс атак SSRF: приложение заставляют сделать запрос туда, куда внешний пользователь обратиться не может. В 2019 году похожий доступ к IMDS стал одним из ключевых элементов атаки на Capital One. Разница в том, что здесь роль SSRF-посредника получает разговорчивый агент, которому бизнес уже выдал доступ к инструментам.
Временные credentials сами по себе ещё не означают захват всего облака — всё решает IAM. Но в данном случае исследователи обнаружили слишком привилегированную стандартную роль AgentCore. Получив её учётные данные, они смогли обращаться к другим агентам в регионе, читать их сессии и получать доступ к секретам в AWS Secrets Manager. Кроме бокового перемещения, это открывало путь к отравлению памяти агентов: злоумышленник мог изменить сохранённый контекст, на который затем опираются другие диалоги и действия.
Именно здесь уязвимость AWS AgentCore перестаёт быть узкой проблемой команды, которая сделала чат-бота. У публичного агента обычно минимальный порог взаимодействия: ему пишут клиенты, кандидаты, сотрудники или партнёры. Если этот же агент способен выполнять HTTP-запросы и наследует широкие AWS-права, он становится удобной точкой входа в инфраструктуру. Причём классические проверки безопасности могут не заметить странность: запрос к IMDS формально выполняется легитимным процессом внутри легитимной среды.
AWS получила первое сообщение об ошибке в декабре, а затем — отдельный отчёт о чрезмерных правах роли и масштабе возможного ущерба. В феврале компания изменила платформу: новые агенты AgentCore стали использовать IMDSv2, где для доступа требуется токен аутентификации. AWS также урезала стандартную роль, убрав разрешения на вызов других агентов, чтение приватных разговоров и доступ к секретам, среди прочих ограничений.
Для команд, использующих AgentCore, исправление не повод закрыть тикет с пометкой «облако обновилось». Во-первых, стоит проверить уже развёрнутых агентов: формулировка AWS касается новых развёртываний, а настройки и роли старых ресурсов нуждаются в отдельной инвентаризации. Во-вторых, каждый инструмент агента нужно рассматривать как API с враждебным входом. Возможность делать произвольные HTTP-запросы, читать секреты или вызывать соседние агенты не должна выдаваться «на будущее» — особенно фронтовому помощнику.
Практическая минимальная программа выглядит прозаично, а потому часто откладывается: разделить роли агентов по задачам, ограничить доступ к Secrets Manager конкретными секретами, запретить ненужный egress и убедиться, что IMDSv2 обязателен. Полезно также отделить публичный диалоговый слой от агента, который реально совершает действия в AWS, и логировать обращения к метаданным, секретам и межагентным вызовам. Удобство автономного AI-исполнителя заканчивается там, где он может по текстовой инструкции пользователя менять состояние инфраструктуры.
Zenity не обнаружила признаков эксплуатации до исправления, хотя Шарбат допускает, что способы выявлять развёрнутые на AWS агенты существуют. Исследователи уже проверяют другие облачные платформы на похожую комбинацию доступа к метаданным и избыточных полномочий. Главный вывод здесь шире конкретного сервиса: AI-агент не отменяет старые правила облачной безопасности, а делает цену ошибки в IAM и сетевой изоляции заметно выше.