FlawOpen

flawopen.com/AI Security/agentcorruption-bedrock-agentcore-metadata-role-scope-october-2026

● Соответствие FlawOpen: CWE-918 · Редакционная оценка: Средний
Исследования · FlawOpen

AgentCorruption: риски метаданных и IAM в AgentCore

В исследовании Zenity за октябрь 2026 года сообщается, что инструменты под влиянием модели могли обращаться к метаданным среды AgentCore, а прежние разрешения роли по умолчанию расширяли доступ. AWS считает доступ к учетным данным собственной роли среды ожидаемым и рекомендует минимальные привилегии. В исследовании Zenity не указан идентификатор CVE и исследование не устанавливает компрометацию клиентов.[1], [4]

💡 Простыми словами (ELI5)

Представьте агента в мастерской, которому выдали пропуск для назначенных задач. По данным Zenity, инструмент, управляемый моделью, мог запросить этот пропуск во внутреннем бюро; прежние права пропуска открывали больше помещений, чем требовалось агенту. AWS говорит, что агенту внутри мастерской положено получать учетные данные собственной роли. Практическая защита — ограничить двери, которые открывает каждый пропуск, и контролировать, какие инструменты могут отправлять внутренние запросы.[1], [4]

Ключевые понятия и термины

AgentCorruption
Название Zenity Labs для контролируемой исследовательской цепочки против Amazon Bedrock AgentCore. Zenity не указывает идентификатор CVE, а исследование не подтверждает утечку данных клиентов.[1], [7]
MMDS и учетные данные роли выполнения
AWS документирует, что код внутри микровиртуальной машины AgentCore может получить через MMDS временные учетные данные роли выполнения этой среды. Сервис считает такое поведение ожидаемым; права роли определяют, что разрешают эти учетные данные.[4], [5]
Радиус действия разрешений
Роль выполнения определяет, к каким действиям и ресурсам AWS может обращаться код агента. Zenity сообщает о широких исторических разрешениях в пределах одного аккаунта и региона. AWS рекомендует минимальные привилегии; авторизация зависит от применимых к операции политик идентификации и ресурсов. AWS отдельно указывает, что для доступа между аккаунтами нужны явные разрешения и в роли, и в целевом ресурсе.[3], [1], [6]
CWE-918 — редакционная классификация
В этой статье CWE-918 используется как редакционная классификация запроса, отправленного инструментом агента к внутренней службе метаданных. AWS не назначала эту CWE; доступ к метаданным является документированным поведением.[8], [4], [1]

Связи со стандартами

  • Концептуальное соответствие FlawOpen для MITRE CWE; ни поставщик, ни запись CVE не присваивали этот идентификатор слабого места данной исследовательской демонстрации. CWE-918

Пошаговый сценарий атаки

Шаг 1

У публичного агента есть инструмент исходящих запросов

Zenity проверила общедоступного агента AgentCore с инструментом, способным отправлять запросы наружу. Для сценария требуются доступный агент и путь к инструменту, на который может влиять модель; это не описание каждой конфигурации.[2], [1]

Шаг 2

Влияние модели достигает службы метаданных

Zenity сообщает, что тестовый агент удалось побудить обратиться к локальной службе метаданных. AWS документирует доступ к учетным данным MMDS из микровиртуальной машины; предмет спора — путь доверия от модели к инструменту и полномочия этих учетных данных, а не наличие учетных данных самой среды.[2], [1], [4]

Шаг 3

Ответ содержит учетные данные роли агента

AWS документирует, что MMDS выдает временные учетные данные настроенной роли выполнения. Эти учетные данные не предоставляют автоматически доступ ко всем ресурсам; разрешенные операции задаются применимыми политиками IAM и ресурсов. Для доступа между аккаунтами AWS отдельно требует явных разрешений как в роли, так и в целевом ресурсе.[4], [6], [1]

Шаг 4

Прежние разрешения расширяли последствия

Zenity сообщает, что прежняя роль по умолчанию разрешала операции с другими ресурсами AgentCore в том же аккаунте и регионе, включая вызовы, доступ к сессиям и событиям, операции с памятью и доступ к секретам. По сообщению Zenity, к 29 сентября 2026 года AWS существенно сузила эту роль. Это не доказывает автоматического изменения ролей, управляемых клиентами.[3], [1], [6]

Шаг 5

Текущие меры защищают разные границы

По данным Zenity, новые агенты перешли на MMDSv2 14 февраля 2026 года. В актуальной документации AWS указано, что с 30 июня 2026 года MMDSv2 необходимо включить для вызова среды выполнения. AWS по-прежнему документирует доступ к учетным данным роли из кода внутри микровиртуальной машины. Поэтому MMDSv2 не заменяет IAM с минимальными привилегиями и контроль инструментов под влиянием модели. Это разделение мер защиты — вывод из источников.[5], [4], [1]

Доказательства и текущие границы

ГраницаДоказательствоДействие защиты
Доступ к метаданнымZenity сообщает о доступе в тесте; AWS документирует выдачу учетных данных MMDS коду внутри микровиртуальной машины.Считайте код агента и инструменты под влиянием модели носителями роли выполнения.
Права ролиZenity сообщает о широких прежних разрешениях по умолчанию. AWS указывает, что для доступа между аккаунтами нужны явные разрешения в роли и целевом ресурсе; другие операции регулируются соответствующими политиками IAM и ресурсов.Проверьте развернутые роли и политики ресурсов; установите, какие политики применяются к каждой операции, и не выводите область доступа из промпта или стандартной конфигурации сервиса.
Изменение роли по умолчаниюZenity сообщает, что 29 сентября 2026 года AWS сузила роль по умолчанию. В исследовании не говорится об автоматическом изменении ролей клиентов; идентификатор CVE не указан, утечка данных клиентов не подтверждена.Проверьте действующие роли в каждом аккаунте и регионе; не предполагайте, что роли клиентов изменились.
MMDSv2Zenity датирует переход новых агентов на MMDSv2 14 февраля 2026 года; текущая документация AWS требует включать его для вызова среды с 30 июня 2026 года. AWS по-прежнему документирует доступ к учетным данным изнутри VM.Включите MMDSv2 и отдельно ограничьте действия, ресурсы и вызывающие стороны роли.

Анализ первопричины

Необходимо отдельно оценить две границы: инструменты под влиянием модели могут отправлять запросы изнутри среды, а роль выполнения определяет полномочия таких запросов. AWS считает доступ к учетным данным собственной роли среды ожидаемым; описанное Zenity воздействие на другие агенты зависело от прежнего объема прав роли. Включение MMDSv2 не ограничивает IAM, а сужение прав роли не предотвращает внутренние запросы по указанию модели. Проверяйте исходящий трафик инструментов и авторизацию IAM независимо; ограничения сети сами по себе не доказывают, что код в микровиртуальной машине не может обратиться к MMDS.[1], [3], [4], [5]

Исходный код: Уязвимый vs Защищённый вариант

Только иллюстративные фрагменты политик IAM; это не прежняя политика AWS и не последующее изменение роли по умолчанию. AWS рекомендует указывать конкретные ARN ресурсов и избегать шаблонов. Первая запись показывает широкий шаблон ресурсов; вторая ограничивает вызов одной разрешенной средой, если такое разрешение необходимо. Если оно не нужно, удалите его. Проверьте поддержку действия и ресурса, а также сопутствующие политики ресурсов для конкретного развертывания; это не готовая политика для развертывания.[3], [6], [5]

УЯЗВИМАЯ РЕАЛИЗАЦИЯ
{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}
БЕЗОПАСНЫЙ ИСПРАВЛЕННЫЙ ВАРИАНТ
{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

Чек-лист по защите системы для инженеров

Источники

← AI Security Directory →