Свежие бюллетени безопасности AWS показывают, как меняется характер риска, связанного с инструментами разработки. Затронутые продукты не являются разными версиями одной платформы, а уязвимости не имеют единой технической причины. Но эксплуатационный рисунок у них общий: среда разработки или работы с данными, дополненная ИИ, может оказаться посредником между запросом пользователя и учетными данными, файлами, внутренними сетевыми сервисами или облачными API. Поэтому ошибка в этом слое способна превратиться в инцидент с гораздо большим радиусом поражения, чем обычный дефект редактора.

Рабочее место службы безопасности: ноутбук отслеживает связи между ИИ-агентом, инструментами, учетными данными, файлами и облачной инфраструктурой.

За последние несколько дней AWS опубликовала или обновила важные рекомендации для Loom for AWS, открытого security-agent-mcp-server, SageMaker Distribution в SageMaker Unified Studio и IDE Kiro. В раскрытиях упоминаются обход аутентификации, раскрытие токенов, небезопасные исходящие запросы, внедрение аргументов, выполнение команд и агентная запись в глобальную конфигурацию. Для каждого продукта AWS указывает свои затронутые версии и свой путь исправления, поэтому общего указания вроде «обновите инструменты AWS» недостаточно.

Непосредственная реакция понятна: выяснить, установлен или развернут ли затронутый компонент, перейти на исправленный выпуск, перезапустить сервисы там, где AWS связывает исправление с перезапуском, и заменить учетные данные, если в бюллетене говорится о возможном раскрытии. Более важная работа носит системный характер. Команды разработки должны считать агентные инструменты привилегированными программными компонентами и сделать видимыми для службы безопасности их права, сетевую доступность, область локальной записи и след аудита.

Что раскрыла AWS

Самый новый бюллетень в этой группе касается CVE-2026-104019 в процессе запуска SageMaker Spaces в SageMaker Unified Studio. AWS сообщает, что скрипт запуска проверяет доступные в проекте сетевые подключения. В определенных условиях недостаточная санитизация сведений о подключении могла позволить выполнить код в Space другого участника проекта. В проектах с включенным Trusted Identity Propagation участник с ролью contributor или выше потенциально мог получить временные учетные данные execution role другого участника и обращаться к downstream-сервисам от его имени.

AWS сообщает, что исправление развернуто глобально и применяется при перезапуске поддерживаемых Spaces. В бюллетене перечислены исправленные версии SageMaker Distribution: 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 и 4.4.3. Для нескольких более старых веток исправления нет, поскольку они больше не поддерживаются. AWS рекомендует перезапустить Spaces на затронутых версиях minor, чтобы они получили исправленный образ. Обходного решения не указано. Значит, перезапуск и проверка версии — это эксплуатационная мера контроля, а не пункт, который можно бездумно отложить до следующего окна обслуживания.

Бюллетень по Loom for AWS посвящен другой проблеме и особенно важен для команд, экспериментирующих с оркестрацией агентов. AWS описывает Loom как открытую платформу AWS Labs для оркестрации ИИ-агентов. Три CVE затрагивают версии до 1.7.0. Одна проблема аутентификации в версиях до 1.6.1 могла позволить неаутентифицированному сетевому клиенту получить административные полномочия над плоскостью управления агентами, если поставщик удостоверений не был настроен. По данным AWS, такие полномочия могли включать регистрацию серверов инструментов, чтение сохраненных учетных данных интеграций и изменение политик IAM-ролей, прикрепленных к управляемым ролям агентов.

Вторая проблема в версиях до 1.7.0 связана с обработкой обнаружения OAuth2. AWS сообщает, что аутентифицированный пользователь с областью mcp:write или a2a:write мог задать URL обнаружения, из-за которого backend отправлял секреты OAuth2-клиента или access token другого пользователя на endpoint под контролем третьей стороны. Более ранний выпуск 1.6.1 блокировал доступ к внутренним адресам, но не полностью устранял путь раскрытия токенов. Третья проблема затрагивала соединения с серверами инструментов и удаленными агентами и могла позволить аутентифицированному пользователю направлять запросы на произвольные адреса во внутренней сети, включая endpoint контейнера, выдающий учетные данные.

Для Loom AWS указывает выпуск 1.7.0; отдельная проблема аутентификации также исправлена в 1.6.1. В бюллетене прямо рекомендуется заменить секреты OAuth2-клиентов, отозвать и выпустить заново access token, действовавшие в затронутый период, а также заменить учетные данные сессий IAM-роли, если учетные данные контейнера могли быть доступны посторонним. Это самый наглядный пример в данной группе того, почему одного патча может быть недостаточно: если секреты могли пересечь границу доверия, исправление включает восстановление контроля над идентичностями.

Проблема security-agent-mcp-server охватывает более узкий продукт, но важна из-за границы между локальным ИИ-ассистентом и файловой системой хоста. AWS описывает проект как открытый MCP-сервер в репозитории awslabs/mcp, который ассистенты используют для локального запуска проверок безопасности, в том числе дифференциальных сканирований. CVE-2026-97662 затрагивала версии от 0.1.1 до 0.2.0, не включая последнюю. Специально сформированное reference value, переданное в diff scan, могло интерпретироваться как параметр командной строки, а не как ревизия. AWS сообщает, что результатом могли стать создание, перезапись или усечение произвольных файлов за пределами предназначенного workspace, то есть обход ограничения сервера областью рабочего пространства.

AWS указывает версию 0.2.0 как исправление и сообщает, что кроме обновления обходного решения нет. До обновления рекомендуется запускать diff scan только для доверенных репозиториев и использовать учетную запись с минимальными правами в изолированной среде. Этот совет важен не только для данного пакета. Локальный агент, способный вызвать сканер, компилятор, менеджер пакетов или помощник развертывания, является локальной системой автоматизации. Ошибка в обработке аргументов может превратить тщательно описанную границу workspace в предположение, которое операционная система не обязана соблюдать.

Kiro IDE показывает еще один вариант той же проблемы. В бюллетене AWS по CVE-2026-95985 говорится, что версии Kiro до 1.0.242 могли позволить удаленному неаутентифицированному злоумышленнику выполнять произвольные команды и внедрять специально сформированные инструкции в контекст агента, когда пользователь запускал агента в специально подготовленном репозитории как в недоверенном workspace. По данным AWS, злоумышленнику было достаточно отправить сообщение, чтобы изменения агента автоматически попали в глобальные пути конфигурации.

Исправленная версия Kiro — 1.0.242. AWS сообщает, что обходного решения нет, и просит пользователей, запускавших агент в недоверенном workspace на более ранней версии, проверить глобальный каталог конфигурации Kiro на наличие записей, созданных не ими. Указанные пути — ~/.kiro в macOS и Linux и %USERPROFILE%\.kiro в Windows. Важная эксплуатационная деталь заключается в том, что репозиторий может быть недоверенным, даже если открывающий его человек заслуживает доверия. Решение о доверии относится к содержимому, которое агент разбирает, и инструментам, которые он способен вызвать, а не только к личности разработчика за клавиатурой.

Общая черта — не формула «ИИ небезопасен»

Было бы легко свести эти рекомендации к предупреждению о программном обеспечении с ИИ. Но такое обобщение плохо помогает при реагировании. Полезнее говорить о концентрации привилегий. Каждый продукт соединяет обычные программные компоненты с возможностью пересечь границу: локальной записью файлов, MCP- или A2A-коннектором, OAuth2-клиентом, временной execution role, скриптом запуска или контекстом агента, влияющим на последующие действия.

Эти границы хорошо знакомы службам безопасности. Агентные инструменты меняют число шагов, которые могут произойти после исходного ввода. Репозиторий может повлиять на контекст агента. Агент может вызвать инструмент. Инструмент — обратиться к внутреннему endpoint или запустить команду. Команда — прочитать или изменить файлы. Затем облачный сервис может использовать временные учетные данные для API-запросов. Такая последовательность не обязательно является цепочкой эксплуатации в каждом развертывании, но сама архитектура делает возможным сценарий, при котором небольшая ошибка разбора или авторизации выходит за пределы исходного приложения.

Поэтому объектом проверки должен быть не только пакет или IDE. Нужно рассматривать пакет вместе с его идентичностью выполнения, областью локальной файловой системы, исходящими сетевыми соединениями, подключенными инструментами и облачными разрешениями. Команда может обновить Kiro, но оставить каждому агенту права администратора — известный дефект будет устранен, а большой неконтролируемый радиус поражения останется. Можно исправить Loom, но не заменить токены после возможного раскрытия — путь в коде закрыт, а инцидент нет.

Собственные рекомендации AWS по IAM включают временные учетные данные для рабочих нагрузок, минимальные права, регулярный пересмотр неиспользуемых разрешений, условия, сужающие политики, и защитные ограничения для разрешений между аккаунтами. AWS также советует использовать активность CloudTrail и IAM Access Analyzer для уточнения политик. Это общие меры контроля, но данные бюллетени показывают, где именно их применять: к идентичностям и интеграциям, которыми пользуются агентные инструменты, а не только к рабочим сервисам.

Кто должен действовать первым

Первая группа — команды, развернувшие Loom for AWS шире локального loopback-интерфейса разработчика, особенно если приложение стало доступно из сети до настройки поставщика удостоверений. Вторая — команды, выдавшие административные области интеграции вроде mcp:write или a2a:write большему числу людей, чем небольшая группа администраторов. Третья — команды, использующие Loom с OAuth2-интеграциями, удаленными агентами или серверами инструментов, где хранятся учетные данные.

Следом идут команды по данным и ИИ, использующие Spaces в SageMaker Unified Studio с Trusted Identity Propagation. Риск зависит от конфигурации проекта и ветки дистрибутива, но исправление конкретно: найти Spaces на затронутых версиях, перезапустить их после появления исправленных образов и убедиться, что старые неподдерживаемые minor-ветки не продолжают работать. Перезапуск нужно фиксировать как изменение с ответственным и подтверждающими материалами, а не считать автоматически выполненным только потому, что платформа управляемая.

Команды платформы разработки и application security должны проверить наличие AWS security-agent-mcp-server в локальных манифестах инструментов, интеграциях редакторов, вспомогательных образах CI и общих контейнерах разработки. Пакет может быть установлен под именем, которое неочевидно при инвентаризации сервисов AWS. Нужно искать объявления MCP-серверов в исходных репозиториях и конфигурации начальной настройки разработчиков, затем сопоставлять каждую установку с версией и учетной записью выполнения.

Наконец, команды управления конечными устройствами должны проверить версии Kiro на рабочих станциях разработчиков и управляемых виртуальных рабочих столах. Это особенно важно там, где разработчики регулярно открывают внешние репозитории, issue-трекеры или сгенерированный код. Если затронутая версия использовалась с недоверенным workspace, проверка должна включать глобальный каталог конфигурации Kiro. Цель не в том, чтобы без контекста вручную просмотреть каждый файл, а в сравнении истории конфигурации с эталонами управления и расследовании записей, появившихся в затронутый период.

Практическая последовательность реагирования

1. Составьте инвентаризацию возможностей

Начинайте с возможностей, а не с названий поставщиков. Перечислите каждый инструмент разработки или работы с данными, который способен делать хотя бы одно из следующего: записывать данные за пределами каталога проекта, выполнять локальные команды, вызывать MCP- или A2A-серверы, обращаться к облачным учетным данным, разрешать сетевые адреса, создавать или изменять IAM-роли либо читать секреты интеграций. Включите расширения IDE, локальные демоны, общие контейнеры, runners CI, образы ноутбуков и внутренние оболочки вокруг открытых проектов.

Для каждого элемента зафиксируйте установленную версию, источник установки, владельца, хост или контейнер, идентичность для доступа к облачным ресурсам, доступные сети и репозитории или проекты, способные поставлять ему входные данные. В первый день инвентаризация не обязана быть идеальной базой активов. Она должна с достаточной точностью отвечать, относится ли конкретная рекомендация AWS к реальной установке и какие системы были ей доступны.

2. Исправляйте с учетом реальной границы продукта

Для Loom перейдите на 1.7.0 и проверьте форки или производный код. AWS отдельно указывает, что производным проектам нужно самостоятельно включить исправления, поэтому репозиторий, скопировавший upstream-код, не защищен автоматически только потому, что исходный проект выпустил новую версию. Для MCP-сервера установите 0.2.0 и убедитесь, что общие образы и скрипты начальной настройки разработчиков больше не устанавливают старый диапазон. Для Kiro перейдите на 1.0.242 или новее и проверьте глобальную конфигурацию, если затронутая версия использовалась с недоверенным workspace.

Для SageMaker Unified Studio определите ветку minor дистрибутива и перезапустите затронутые Spaces, чтобы применилось глобально развернутое исправление. Список версий AWS важен: некоторые старые ветки не исправлены, а выведены из поддержки. Управляемый сервис снимает часть нагрузки по установке патчей, но не отменяет необходимость выяснить, какой runtime фактически используется и перезапускался ли Space.

3. Восстановите контроль над идентификационными материалами, если раскрытие возможно

Не ждите доказательства использования токена. В рекомендации AWS по Loom предлагается заменить секреты OAuth2-клиентов, отозвать и заново выпустить активные access token, если в затронутый период они могли быть доступны. Если учетные данные роли контейнера могли быть прочитаны, замените учетные данные сессии и проверьте CloudTrail на непредусмотренное использование. Точная последовательность должна соответствовать процессу реагирования организации и возможностям поставщика удостоверений.

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

4. Проверьте облачную активность за период возможного воздействия

CloudTrail записывает вызовы AWS API и такие сведения, как вызывающая идентичность, время, исходный IP-адрес, параметры запроса и элементы ответа. Используйте эти записи, чтобы установить, выполняла ли затронутая роль или интеграция необычные действия в период доступности уязвимого компонента. Обратите внимание на принятие ролей, изменения IAM-политик, создание новых access key, изменения trust policy, доступ к секретам, неожиданные чтения данных и активность из незнакомых сетей.

Цель не в поиске одного волшебного имени события. Постройте временную шкалу, связывающую уязвимый компонент, его идентичность и подключенные сервисы. При раскрытии токена может появиться доступ с неожиданного адреса. Изменение политики роли может выглядеть как IAM-изменение, за которым последовал доступ нового principal. Компрометация Space для разработки данных может породить активность под легитимной временной ролью, поэтому время, источник и ожидаемую активность проекта нужно рассматривать вместе.

5. Сократите разрешения до возврата к обычной работе

Окно установки патчей — подходящий момент, чтобы убрать права, выданные для эксперимента и так и не сокращенные. Начните с разделения чтения и обнаружения, сканирования кода, развертывания, доступа к секретам и администрирования IAM на разные роли. По возможности используйте временные учетные данные и короткие сессии. Мощные действия лучше защищать согласованием или отдельной ролью оператора, а не делать их доступными каждой идентичности, подключенной к агенту.

AWS рекомендует минимальные права и защитные ограничения для разрешений. На практике это означает, что агент должен иметь только нужные для задачи API-действия и только в отношении нужных ресурсов. Сканеру кода не требуется автоматически менять IAM-политики. Серверу инструментов, читающему исходный код, не нужен автоматический доступ к рабочим секретам. Участник ноутбука не должен наследовать идентичность другого участника проекта лишь потому, что включена функция доверенной передачи идентичности.

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

Какие выводы не следует делать из этих бюллетеней

Эти раскрытия не доказывают, что каждая агентная IDE или каждый MCP-сервер скомпрометированы. Они показывают, что проверка безопасности должна включать обычные дефекты программного обеспечения в плоскости управления вокруг агента. Риск определяется не тем, рекламирует ли продукт ИИ. Не-ИИ-плагин с выполнением команд и облачными учетными данными может быть столь же чувствительным. И наоборот, агент без учетных данных, доступа к сети и с рабочим пространством только для чтения имеет совсем другой профиль последствий, чем агент, способный изменять роли развертывания.

Из этих случаев также не следует запрет на открытые агентные инструменты как категорию. Рекомендации AWS по Loom и security-agent-mcp-server показывают, почему командам нужно отслеживать форки, закрепленные версии и локальные оболочки. Открытый исходный код может сделать исправления видимыми и проверяемыми, но скопированный репозиторий, внутренний патч или образ контейнера способны продолжать нести уязвимость уже после выпуска исправления upstream. Контроль здесь — дисциплина версий и происхождения, а не упрощенный ярлык.

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

Устойчивый вывод для платформенных команд

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

Нынешние рекомендации AWS служат полезной проверкой зрелости организации. Может ли команда ответить, какие разработчики используют Kiro, в каких репозиториях находится MCP-сервер, какие развертывания Loom доступны из сети, какие SageMaker Spaces работают на затронутых дистрибутивах и какие роли могут принимать эти системы? Может ли она заменить секрет интеграции без пересборки всей платформы? Может ли отличить нормальный вызов временной роли от подозрительного? Если нет, недостающий контроль — не еще один документ о политике ИИ. Это рабочий процесс учета активов, идентичностей и аудита для автоматизации разработки.

Пока разумная последовательность коротка: определить масштаб воздействия, применить исправления поставщика, перезапустить управляемые Spaces там, где это требуется, заменить потенциально раскрытые материалы, проверить CloudTrail и сузить разрешения до повторного включения широкого доступа. Бюллетени AWS посвящены конкретным продуктам и версиям, но их эксплуатационный смысл шире. Когда программа может интерпретировать репозиторий, вызвать инструмент и действовать под облачной идентичностью, ее патч должен попасть и в очередь реагирования на инциденты, и в очередь обновления инструментов разработчиков.

Источники и область материала

Статья посвящена бюллетеням безопасности AWS, опубликованным с 24 сентября по 2 октября 2026 года, с акцентом на эксплуатационные действия, указанные AWS. Она не утверждает, что в каком-либо из затронутых развертываний произошла эксплуатация. Технические шаги эксплуатации намеренно не приводятся; для расследования команды должны использовать рекомендации поставщика и собственные процедуры реагирования.

Основные раскрытия: бюллетень AWS 2026-125 о CVE-2026-104019 в SageMaker Distribution, бюллетень AWS 2026-124 о трех CVE в Loom for AWS, бюллетень AWS 2026-121 о CVE-2026-97662 в security-agent-mcp-server и бюллетень AWS 2026-117 о CVE-2026-95985 в Kiro IDE. Рекомендации по разрешениям и аудиту основаны на передовых практиках AWS IAM, руководстве по минимальным правам и документации CloudTrail API.