{"schema_version":"1.0","service":"Publicasta","type":"article","id":648,"slug":"aws_lambda_microvms_make_agent_sandboxes_an_operations_problem","title":"Lambda MicroVM от AWS упрощают запуск песочниц для ИИ-агентов — и случайно усложняют управление ими","excerpt":"Референсная архитектура AWS для Lambda MicroVM дает быстрые изолированные среды выполнения для задач ИИ-агентов. Но главное изменение связано с эксплуатацией: идентификацию, исходящий трафик, хранение, наблюдаемость и очистку придется проектировать как единую систему.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru","image":{"url":"https://publicasta.com/storage/projects/17/pages/648/2026/09/9ce2aef8-5d39-4769-8619-63fe72237dd9.webp","alt":"Редакционная иллюстрация задачи ИИ-агента внутри изолированной облачной MicroVM, окружённой контролями идентификации, сети, наблюдаемости, сохранения состояния и очистки."},"publisher":{"id":17,"slug":"it_today_news","name":"ИТ сегодня","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-09-19T13:57:35+00:00","updated_at":"2026-09-19T13:57:35+00:00","content_markdown":"AWS опубликовала референсную архитектуру для запуска самостоятельно размещаемых песочниц ИИ-агентов на Lambda MicroVM. Схема практична: API принимает задачу, запускает изолированную среду, позволяет агенту работать, передает или сохраняет результат, а после завершения удаляет среду либо переводит ее в приостановленное состояние. Архитектура рассчитана на команды, которым нужно выполнять агентов в собственном аккаунте AWS, а не в рабочем пространстве разработки, управляемом поставщиком.\n\n ![Редакционная иллюстрация задачи ИИ-агента внутри изолированной облачной MicroVM, окружённой контролями идентификации, сети, наблюдаемости, сохранения состояния и очистки.](https://publicasta.com/storage/projects/17/pages/648/2026/09/9ce2aef8-5d39-4769-8619-63fe72237dd9.webp)\n\n Новость легко свести к разговору о производительности. Lambda MicroVM обеспечивают быстрый запуск, изоляцию уровня виртуальной машины, состояние на основе снимков и управляемую сеть. Это полезно. Но более существенный сдвиг происходит в другом месте: песочница, которую можно создать по запросу, подключить к настоящей VPC и наделить доступом к внутренним сервисам, перестает быть только защитным механизмом. Это краткоживущая рабочая нагрузка продакшен-класса, внутри которой модель принимает решения.\n\n Поэтому первый вопрос для платформенной команды должен звучать не так: безопаснее ли microVM контейнера? Важнее понять, может ли организация сделать весь путь выполнения наблюдаемым, ограниченным и одноразовым. Надежный механизм изоляции помогает, но сам не решает, какие учетные данные получит агент, к каким доменам он сможет обращаться, какие данные сможет скопировать в рабочее пространство и можно ли будет возобновить приостановленную среду после изменения политики.\n\n ## Что объявила AWS\n\n В публикации AWS Compute Blog от 18 сентября описана самостоятельно размещаемая архитектура на базе AWS Serverless Application Model и нескольких управляемых сервисов. В числе заявленных компонентов — Amazon S3, IAM, Systems Manager Parameter Store, API Gateway, Lambda, AWS WAF, CloudWatch Logs и Lambda MicroVM. Схема предназначена для вызовов инструментов ИИ-агентом, которым недостаточно короткого запуска функции: агенту может понадобиться установить пакеты, выполнить команды, работать с файловой системой, запустить процессы и сохранить состояние интерактивной сессии.\n\n Сервис Lambda MicroVM — более новый вычислительный примитив, построенный вокруг виртуализации Firecracker. AWS описывает его как бессерверную среду с полноценными возможностями операционной системы, запуском на основе снимков и управлением входящим и исходящим сетевым доступом. К MicroVM можно подключить сетевой коннектор во время выполнения. В зависимости от конфигурации среда получает доступ к публичному интернету, VPC или закрытым сервисам AWS через VPC endpoints.\n\n Такое сочетание закрывает реальное несоответствие в современных агентских системах. Обычная функция удобна, но узка: у нее ограниченная модель выполнения, эфемерная локальная файловая система и ограниченное время работы. Традиционная виртуальная машина или pod Kubernetes дают больше свободы, однако платформенной команде приходится управлять мощностями, выпуском образов, изоляцией, планированием и очисткой. Контейнер может запускаться быстро, но делит ядро хоста с другими рабочими нагрузками. MicroVM помещает гостевую операционную систему между задачей и базовым хостом, сохраняя при этом управляемый жизненный цикл по требованию.\n\n Референсная архитектура AWS не является готовой границей безопасности для любого агента. Это набор строительных блоков и схема развертывания. Различие важно, поскольку главные средства контроля находятся выше слоя виртуализации. Платформе по-прежнему нужно решить, как аутентифицировать запросы, как разделять арендаторов, как авторизовать задачи, как проверять артефакты, сколько может жить сессия и что делать, если агент снова и снова запрашивает разрешение, которого у него быть не должно.\n\n ## Почему это не обычный serverless-код\n\n Обычная бессерверная функция обычно имеет довольно узкое назначение. Событие вызывает известный обработчик, обработчик обращается к известному набору сервисов, а конвейер развертывания заранее определяет большую часть поведения. Проблемы безопасности все равно серьезны, но оператор часто может рассуждать о функции по ее коду, IAM-политике и контракту входных данных.\n\n ИИ-агент меняет форму пути выполнения. Он может динамически выбирать инструменты, интерпретировать недоверенный текст, установить зависимость, изучить репозиторий, вызвать командный клиент, повторить попытку после ошибки или решить, что задаче нужен новый сетевой запрос. Итоговая последовательность действий не полностью задана манифестом развертывания. Она частично генерируется во время выполнения из промпта, описаний инструментов, найденных документов, содержимого файлов и результатов предыдущих команд.\n\n Здесь нужно отдельно рассматривать несколько границ. Граница модели касается того, какие инструкции агент способен интерпретировать и как он обрабатывает вредоносный контент. Граница инструментов определяет, какие API и команды он может вызвать. Вычислительная граница показывает, на что способен повлиять код внутри среды. Граница данных отвечает за то, что можно прочитать, скопировать или сохранить. Организационная граница определяет, может ли один клиент, проект или команда наблюдать за другим либо влиять на него. MicroVM прежде всего укрепляет вычислительную границу. Остальные четыре автоматически не исчезают.\n\n Поэтому слово «песочница» может вводить в заблуждение. Под ним могут понимать новую среду операционной системы, контейнер с ограниченной файловой системой, процесс с профилем seccomp, слой изоляции браузера или просто рабочее пространство, помеченное как временное. У этих механизмов разные сценарии отказа. Гостевое ядро и монитор виртуальных машин способны снизить последствия выхода вредоносного процесса из контейнера, однако агент с действительными учетными данными все равно может сделать разрешенный, но разрушительный вызов API, не нарушив изоляцию.\n\n Практическая цель — не добиться состояния, в котором ничего плохого произойти не может. Нужно ограничить радиус поражения: у каждой задачи должны быть минимальные идентичность, набор данных, сетевой путь, срок жизни, объем хранилища и бюджет действий, достаточные для завершения работы. Система должна сохранить достаточно свидетельств для объяснения произошедшего, а затем сделать уничтожение среды дешевым и предсказуемым.\n\n ## Архитектурные элементы, требующие проверки\n\n ### 1. Шлюз запросов\n\n Слой API — это первое политическое решение, а не просто входная дверь. API Gateway и WAF помогают аутентифицировать запросы, отбрасывать явно вредоносный трафик и применять ограничения скорости, но даже корректный запрос требует отдельного решения об авторизации задачи. Пользователь, которому разрешено создать песочницу для документации, не должен автоматически получать возможность запросить среду с доступом к производственной базе данных.\n\n Запрос должен содержать явно заданный класс рабочей нагрузки. Полезные поля — идентификатор проекта или арендатора, разрешенные источники данных, допустимый сетевой профиль, максимальное время работы, требуемый тип результата и признак того, может ли задача вносить внешние изменения. Запускающий компонент должен выводить среду из этой политики, а не принимать от вызывающей стороны произвольные имена IAM-ролей, идентификаторы VPC или параметры групп безопасности.\n\n Здесь же должны находиться квоты. Без ограничений на пользователя и проект агентский цикл может создать множество сред, подключить дорогое хранилище или удерживать сессии активными повторяющимися действиями. Бюджет запроса должен охватывать не только число вызовов API. В него следует включить количество одновременно работающих MicroVM, суммарные CPU и память, исходящий объем данных, размер артефактов и число привилегированных вызовов инструментов.\n\n ### 2. Образ и файловая система\n\n Одноразовая среда настолько надежна, насколько надежен образ, из которого она запускается. Образ нужно версионировать, подписывать или иным образом связывать с записью о выпуске, регулярно пересобирать и проверять на уязвимые пакеты операционной системы и инструменты агента. Команда должна понимать, получает ли задача стабильный базовый образ, образ конкретного проекта или изменяемое рабочее пространство поверх основы. Каждый вариант по-разному влияет на воспроизводимость и исправление уязвимостей.\n\n Агенту часто нужно устанавливать пакеты или компилировать нативный код. Для полноценной операционной системы это законный сценарий, но он расширяет поверхность атаки и усложняет анализ конечного состояния. Более безопасный подход — отделить записываемую файловую систему задачи от доверенного базового образа, хранить ее недолго и считать все созданные бинарные файлы, кэши и скрипты недоверенными артефактами.\n\n Снимки добавляют менее очевидный вопрос жизненного цикла. Они ускоряют запуск и позволяют сохранить интерактивную сессию, но одновременно сохраняют состояние памяти и диска. Если при приостановке среды внутри находятся токен, cookie сессии, закрытый исходный файл или вывод команды, все это может остаться в возобновленном состоянии. Операторам нужно задокументировать, что разрешено хранить между приостановкой и возобновлением, и иметь механизм отзыва либо ротации чувствительных материалов до возобновления.\n\n Снимок также отражает политику на момент создания. Если позже организация изменит разрешенные сетевые направления или отзовет зависимость, возобновление старого состояния не должно молча вернуть прежние привилегии. Сетевую политику и политику идентичности следует проверять при запуске и возобновлении, а не только в момент сборки образа.\n\n ### 3. IAM и доставка секретов\n\n Передать MicroVM IAM-роль удобно, но роль не является политикой агента. Это механизм облачной авторизации. Роль должна быть специально создана для класса задач и ограничена разрешениями на уровне ресурсов, условиями, тегами сессии и, где возможно, короткоживущими учетными данными. Универсальная роль, способная читать все бакеты проектов или вызывать любой внутренний сервис, превращает песочницу в ценное хранилище полномочий.\n\n Parameter Store позволяет не помещать секреты в образы, но получение секрета все равно остается действием, которое нужно обосновать. Запускающий компонент не должен открывать агенту широкое пространство параметров и рассчитывать, что модель выберет правильное значение. Вместо этого внешний по отношению к процессу агента брокер может выдать узкую, ограниченную по времени учетную запись после проверки политики задачи. Он же способен не допустить появления исходных секретов в промптах, журналах и видимом модели выводе команд.\n\n Тот же принцип действует для исходных репозиториев. Токен, позволяющий клонировать репозиторий, может также дать право отправлять изменения, открывать pull request или читать другие проекты. Пути чтения и записи нужно разделять. Если агенту требуется предложить изменение, результатом по умолчанию должны быть патч или артефакт, переданный на проверку, а не учетные данные, с помощью которых можно изменить каноническую ветку.\n\n Короткоживущие учетные данные уменьшают воздействие утечки, но не отменяют аудит. Скомпрометированный агент может использовать действующий токен до истечения его срока. Поэтому каждую чувствительную операцию следует записывать вместе с идентификатором задачи, субъектом, идентификатором среды и политическим решением, разрешившим действие. CloudTrail и журналы конкретных сервисов нужно связывать с трассами команд и инструментов изнутри среды.\n\n ### 4. Исходящий трафик — часть набора возможностей агента\n\n Документация AWS предусматривает управление как входящим, так и исходящим трафиком. Это важно, поскольку многим агентским задачам нужны загрузка пакетов, получение исходников или вызовы внешних API. Одновременно именно здесь песочница может превратиться в неуправляемый ретранслятор. При неограниченном интернете модель способна отправить исходные файлы, обратиться к контролируемой злоумышленником конечной точке, загрузить непроверенный инструмент или участвовать в канале управления и контроля.\n\n Безопасным вариантом по умолчанию должен быть небольшой список разрешенных направлений, связанный с задачей. Установку пакетов по возможности следует выполнять через одобренные зеркала или репозитории. Доступ Git нужно ограничить организациями или хостами, необходимыми для работы. Внутренние сервисы следует подключать через явно определенные VPC endpoints и группы безопасности, а не через широкую маршрутизацию. Важно учитывать и DNS: список доменов, который игнорирует DNS rebinding, перенаправления или новые разрешенные адреса, слабее, чем кажется.\n\n Сетевую политику нужно связывать с идентичностью и классом рабочей нагрузки, а не только с общей подсетью. Агент для разработки, агент для code review и агент для миграции могут запускаться из одного базового образа, но нуждаться в совершенно разных сетевых путях. Это различие должно быть видно в объектах развертывания и журналах.\n\n Контроль исходящего содержимого полезен, когда данные чувствительны. Прокси может записывать назначение, метод, размер ответа и результат применения политики. Для высокорисковых нагрузок он способен блокировать загрузки, скачивание исполняемых файлов или запросы с известными шаблонами секретов. Такие меры несовершенны и не должны выдаваться за гарантию предотвращения утечек, однако они создают свидетельства и уменьшают вероятность случайной передачи данных.\n\n ### 5. Для вызовов инструментов нужен слой политики\n\n Агенту не следует выдавать неограниченную оболочку только потому, что песочница изолирована. Shell часто остается самым полезным инструментом для работы с программами, но он одновременно объединяет доступ к файлам, создание процессов, использование сети и поиск учетных данных. Брокер инструментов должен классифицировать команды по эффекту и требовать дополнительного одобрения для публикации пакетов, изменения инфраструктуры, удаления данных, изменения средств контроля доступа или отправки внешних сообщений.\n\n Полезная архитектура отделяет наблюдение от изменения. Чтение журнала сборки, запуск теста или проверка дерева зависимостей могут разрешаться автоматически. Запись в ветку, создание тикета, изменение манифеста развертывания или вызов производственного API могут превращаться в предложение, которое должен одобрить другой сервис или человек. MicroVM содержит работу, но не решает, можно ли этой работе попасть в продакшен.\n\n Описания инструментов — еще один вход для политики. Если инструмент заявляет, что операция доступна только для чтения, но вызывает endpoint с побочными эффектами, агент может сделать опасный выбор, тогда как окружающая система сочтет действие безопасным. Схемы инструментов, реализацию и записи аудита нужно тестировать вместе. Разрешение должно зависеть от фактического эффекта вызова, а не от его удобного названия.\n\n ## Что новая архитектура меняет для платформенных команд\n\n Главное эксплуатационное преимущество состоит в том, что вычисления для агентов могут стать платформенным примитивом. Команды получают внутренний сервис «запустить задачу» с единым API, общими журналами, управлением образами, квотами и правилами жизненного цикла. Разработчикам не придется разворачивать отдельный пул воркеров под каждый новый агентский сценарий. Команды безопасности смогут проверять небольшое число профилей рабочих нагрузок вместо длинного списка специальных хостов.\n\n Это преимущество появляется только тогда, когда платформа владеет плоскостью управления. Если каждая продуктовая команда сама создает запускающий компонент, IAM-роль, сетевой коннектор и бакет журналов, MicroVM могут размножить именно те проблемы управления, которые должны были упростить. Внутренняя платформа должна предлагать безопасные возможности как продукты: задачу для репозитория только на чтение, изолированный тестовый запуск, анализ зависимостей или воркер для подготовки предложения об изменении. Для каждого профиля должны быть известны образ, сетевая политика, контракт учетных данных и правило хранения.\n\n Учет затрат тоже становится точнее и важнее. Бессерверная модель оплаты может сделать короткие задачи привлекательными, но интерактивные агенты способны долго ждать, повторять попытки или удерживать состояние. Приостановка снижает потребление в простое, однако не делает рабочую нагрузку бесплатной. На итоговую сумму влияют хранилище, запросы API Gateway, журналирование, передача данных, обработка WAF, вызовы модели и хранение артефактов. Задача, которая кажется дешевой на уровне вычислений, может оказаться дорогой, если агент постоянно опрашивает сервис или загружает большие рабочие пространства.\n\n Теги должны быть обязательными уже при создании. Минимальный набор — владелец, проект, тип задачи, срок окончания среды, классификация данных и центр затрат. Теги должны попадать в журналы и отчеты по биллингу. Платформа, которая не может ответить, какая команда создала среду, какую политику она использовала и почему среда оставалась активной, еще не готова широко предоставлять автономное выполнение.\n\n ## Изоляция: лучше контейнеров, но не готовый ответ\n\n AWS позиционирует Lambda MicroVM через изоляцию уровня виртуальной машины, используя технологию Firecracker, связанную с Lambda. Это существенное отличие от обычных контейнеров, где процессы разделяют ядро хоста. Такой субстрат может быть правильным для выполнения недоверенного или частично доверенного кода, особенно если рабочей нагрузке нужны возможности операционной системы, которые трудно обеспечить песочницей на уровне языка.\n\n Но механизмы изоляции нужно сравнивать по всей системе, а не по одному ярлыку. У microVM может быть уязвимая гостевая операционная система, чрезмерно привилегированная роль, открытый сетевой путь, отравленный кэш пакетов, опасная интеграция на стороне хоста или конвейер журналирования, раскрывающий секреты. Контейнер с тщательно спроектированной политикой может быть достаточен для низкорисковой задачи, тогда как microVM с неограниченными учетными данными все равно способна привести к серьезному инциденту.\n\n Недавние исследования песочниц для ИИ-кода показывают то же самое с точки зрения измерений. Имеют значение поверхность атаки хоста, утечки информации, эшелонированная защита, история уязвимостей, скорость установки исправлений и качество фаззинга в upstream-проектах. Класс изоляции важен, но не меньше значат процессы обновления и эксплуатационная практика продукта. MicroVM нужно считать одним уровнем эшелонированной защиты, а не сертификатом безопасности задачи.\n\n Это особенно важно для prompt injection. Вредоносный README, issue, веб-страница или зависимость могут убедить агента выполнить действие внутри среды. Если действие меняет только одноразовые файлы, ущерб может быть ограничен. Если агент может прочитать токен исходного кода, отправить его на внешний хост, вызвать внутренний API или изменить общий бакет артефактов, тот факт, что он оставался внутри MicroVM, не делает результат приемлемым.\n\n ## Практическая последовательность запуска\n\n Командам, которые оценивают сервис, стоит начать с задачи, полезный результат которой можно получить, а отказ которой легко исправить. Анализ зависимостей, тестирование на синтетическом репозитории, генерация документации по публичным материалам и проверка сборки подходят лучше, чем изменение инфраструктуры или поддержка продакшена. Цель первого развертывания — наблюдать за плоскостью управления не меньше, чем измерять успешность задачи.\n\n Сначала определите контракт, а уже потом включайте модель. Зафиксируйте входные данные, разрешенные инструменты, ожидаемые артефакты, максимальное время работы, сетевые направления, идентичность, поля журналов и поведение при завершении. Отдельно запишите, что агенту запрещено всегда. Короткая политика, которую можно принудительно применить, ценнее широкого заявления, существующего только в документе проверки.\n\n Затем протестируйте нежелательные сценарии. Поместите вредоносную инструкцию в файл репозитория. Добавьте зависимость со скриптом установки. Верните ошибку инструмента, побуждающую агента повторить запрос с более широкими правами. Вставьте в fixture строку, похожую на секрет. Попробуйте заставить агента обратиться к внутреннему имени хоста, создать вторую среду, записать файл за пределами каталога задачи, сохранить токен в снимке и удерживать сессию после крайнего срока. Цель — проверить поведение политик, а не обучить агента обходить защиту в продакшене.\n\n Инструментируйте всю цепочку. Полезная запись включает запрос, субъекта, профиль политики, digest образа, идентификатор MicroVM, время начала и окончания задачи, вызовы инструментов, команды, сетевые назначения, выдачу учетных данных, экспортированные файлы, события приостановки и возобновления, а также результат очистки. Журналы должны быть защищены от изменения и отделены от доступной для записи файловой системы задачи. Если отказ нельзя восстановить по свидетельствам, платформе будет трудно отличить ошибку модели, пользователя, сервиса и атаку.\n\n Сделайте очистку полноценным рабочим процессом. Для каждой среды нужен срок окончания, который контролируется вне агента. Очистка должна отозвать временные учетные данные, удалить или изолировать артефакты согласно политике данных, убрать сетевые ассоциации, завершить сессию и записать финальное состояние. Если воркер завершился с ошибкой, пока агент работал, это не должно оставлять бесконечно действующую среду. Периодическая сверка должна находить ресурсы, потерявшие запись в плоскости управления, и применять к ним те же правила истечения срока.\n\n Только после того, как эти средства контроля заработают, платформе следует добавлять закрытые данные или права на изменения. Даже тогда граница разрешений должна оставаться узкой. Агент, исправляющий код, может создать патч, но не иметь права объединить его. Агент, планирующий миграцию, может подготовить SQL, но не выполнить его. Агент поддержки может составить ответ, но не отправить его. На переходе от анализа к внешнему эффекту платформа должна сохранять точку проверки человеком или детерминированным процессом.\n\n ## Что операторам стоит спросить у AWS и своих команд\n\n Публичная документация объясняет базовую модель сервиса, но для запуска в продакшене все равно нужны ответы, относящиеся к конкретному аккаунту и рабочей нагрузке. Операторам следует проверить, как обновляются образы, как шифруется и истекает состояние снимков, как сетевые коннекторы ведут себя при возобновлении, какие ограничения действуют для параллелизма и хранилища и какие события доступны для аудита. Нужно также подтвердить региональную доступность, составляющие цены и модель поддержки конкретных возможностей MicroVM, которые планируется использовать.\n\n Внутри организации следует спросить, кто владеет базовым образом, кто утверждает сетевые профили, кто может добавить секрет, как останавливается задача, как специалист по реагированию получает свидетельства и что произойдет, если сотрудник или клиент отзовет доступ во время работы задачи. Это не вопросы для поздней операционной фазы. Они определяют, является ли архитектура управляемой платформой или лишь удобным запускателем.\n\n Есть и вопрос дизайна продукта: что видит пользователь, когда агент хочет пересечь границу? Хорошая система делает предлагаемое действие понятным. Она должна показать репозиторий, назначение, категорию данных, ожидаемый побочный эффект и причину запроса. Кнопка «Разрешить» не должна быть единственным вариантом. Платформе нужны безопасные альтернативы: создать патч, сохранить отчет, запросить более узкий токен или остановить задачу.\n\n ## Более широкое значение\n\n AWS реагирует на модель, которая распространяется по облачным платформам: агентам нужны настоящие среды выполнения, но организации не хотят, чтобы каждая команда строила собственную удаленную оболочку. Управляемая MicroVM может уменьшить объем инфраструктурной работы, необходимой для предоставления такой возможности. Одновременно центр тяжести безопасности агентов может сместиться от фильтрации промптов к инженерии рабочих нагрузок.\n\n Это здоровый сдвиг. Фильтрация промптов снижает число очевидных атак через инструкции, но не способна выразить каждое правило движения данных и авторизации. Профиль рабочей нагрузки может сказать, что задача вправе читать этот репозиторий, обращаться к этим зеркалам пакетов, записывать только в этот бакет артефактов и работать десять минут. IAM, сетевая политика, брокер инструментов и внешний контроллер очистки могут принудительно обеспечить части этого контракта даже при непредсказуемом поведении модели.\n\n Риск состоит в том, что удобство бессерверного выделения ресурсов скрывает цену управления. Разработчик может несколькими вызовами API запустить мощную среду выполнения, подключить роль, дать ей интернет и назвать результат песочницей. Для демонстрации функции этого достаточно. Для автономной системы, работающей с закрытыми данными или производственными средствами контроля, этого недостаточно.\n\n Поэтому совет для следующей оценки должен быть конкретным: создайте один узкий профиль задачи, оставьте данные синтетическими или публичными, запретите широкий исходящий трафик, не выдавайте долгоживущие секреты, записывайте каждый вызов инструмента и сетевое действие, установите внешний крайний срок и проверьте очистку. Измеряйте не только задержку запуска и завершение задачи, но и нарушения политики, необъяснимые сетевые запросы, чистоту снимков, срок хранения артефактов и усилия, необходимые для расследования неудачного запуска.\n\n Lambda MicroVM могут упростить развертывание изолированного выполнения для агентов. Но доверие не возникает автоматически. Выиграют команды, которые будут относиться к MicroVM как к вычислительному слою управляемого сервиса выполнения, проектируя вокруг него идентичность, сеть, данные, наблюдаемость и политику жизненного цикла с самого начала.\n\n ## Источники\n\n Материал основан на публикации AWS Compute Blog о самостоятельно размещаемых песочницах ИИ-агентов на AWS Lambda MicroVM, документации AWS по Lambda MicroVM и сетевому взаимодействию, объявлении поддержки AWS PrivateLink, описании бессерверных сред с изоляцией уровня виртуальной машины, а также исследовании безопасности песочниц для ИИ-кода на arXiv. Для контекста также учитывалась дискуссия сообщества AWS на Reddit.","available_translations":[{"language":"ar","title":"تجعل MicroVMs في AWS Lambda نشر بيئات عزل وكلاء الذكاء الاصطناعي أسهل، لكنها تجعل حوكمتها عرضة للتعقيد غير المقصود","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ar","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=ar","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ar"},{"language":"de","title":"AWS-Lambda-MicroVMs machen Agenten-Sandboxen leichter bereitstellbar – und versehentlich schwerer steuerbar","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=de","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=de","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=de"},{"language":"en","title":"AWS Lambda MicroVMs make AI-agent sandboxes easier to deploy—and harder to govern by accident","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=en","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=en","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=en"},{"language":"es","title":"Los MicroVM de AWS Lambda facilitan el despliegue de sandboxes para agentes de IA, pero vuelven más difícil su gobierno accidental","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=es","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es"},{"language":"fr","title":"Les MicroVM Lambda d’AWS simplifient le déploiement des environnements pour agents IA — et compliquent leur gouvernance par accident","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=fr","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=fr","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=fr"},{"language":"pl","title":"MicroVM-y AWS Lambda ułatwiają wdrażanie piaskownic dla agentów AI — i przypadkiem utrudniają ich zarządzanie","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=pl","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=pl","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=pl"},{"language":"ru","title":"Lambda MicroVM от AWS упрощают запуск песочниц для ИИ-агентов — и случайно усложняют управление ими","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=ru","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru"},{"language":"zh","title":"AWS Lambda MicroVM 让 AI 智能体沙箱更易部署，也让治理更容易被意外忽略","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=zh","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=zh","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru","html":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru","canonical":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru","markdown":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=ru","json":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}