Как работает облачное изолирование агентов в Air

Источник: The JetBrains Blog•

Как работает облачное изолирование агентов в Air

Недавно мы выпустили предварительную версию облачных агентов в JetBrains Air. Облачные агенты позволяют запускать ИИ-агенты удаленно в управляемой JetBrains облачной среде, предоставляя им изолированное рабочее пространство без использования вашего локального компьютера. Вот как это выглядит на…

Агентная среда разработки

Агентный ИИ ИИ JetBrains JetBrains AI

Как работает песочница для облачных агентов в Air

Недавно мы выпустили превью-версию облачных агентов в JetBrains Air. Облачные агенты позволяют запускать ИИ-агентов удаленно в управляемой JetBrains облачной среде, предоставляя им изолированное рабочее пространство без нагрузки на ваш локальный компьютер.

Вот как это выглядит на практике. В этом видео я запускаю задачу в IntelliJ IDEA, слежу за её выполнением через браузер и с телефона, а затем проверяю изменения, внесенные агентом по завершении.

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

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

Почему ИИ-агентам нужна песочница

Песочница для ИИ-агента — это практика запуска агента внутри изолированной и строго контролируемой среды, которая ограничивает доступ к ресурсам и разрешенные действия. Вместо предоставления неограниченного доступа к хост-системе, сети или конфиденциальным данным песочница устанавливает предопределенные границы для файлов, API и внешних сервисов, применяя при этом права с наименьшими привилегиями, лимиты ресурсов, механизмы аудита и трассировки.

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

Пять способов запуска ИИ-агентов и их компромиссы в области безопасности

Можно выделить пять основных сценариев запуска агентов, которые делятся на две широкие категории: локальные и удаленные.

Пять способов запустить агента

Локальные настройки используют вашу машину. Удаленные настройки переносят агента в другое место и изолируют его по умолчанию.

Режим

Изоляция от вашей машины по умолчанию

Кто настраивает

Локальный

Локальное рабочее пространствоРаботает в вашей собственной рабочей копии

Изолировано по умолчаниюНет — агент может выйти за пределы рабочей директории

Кто настраиваетНичего настраивать не нужно; клиент должен принудительно применять любые ограничения

Рабочее дерево GitРаботает в отдельной копии на вашей машине

Изолировано по умолчаниюЧастично — изменения файлов остаются отдельно от ваших, но агент все еще может выйти за пределы директории

Кто настраиваетКлиент создает рабочее дерево

Удаленный

SSHРаботает на предоставленной вами машине по протоколу SSH

Изолировано по умолчаниюДа

Кто настраиваетВы, вручную

DockerРаботает в новом контейнере для каждой задачи, локально или на удаленном хосте. В Docker Sandboxes используется одна микроВМ на агента.

Изолировано по умолчаниюДа

Кто настраиваетКлиент или администраторы организации через Docker Sandboxes

ОблачныйРаботает в новой ВМ, микроВМ или контейнере для каждой задачи. Air использует контейнер внутри ВМ.

Изолировано по умолчаниюДа

Кто настраиваетАвтоматически, на основе настроек, заданных вашей командой или администратором организации

По умолчанию в локальных сценариях агент может легко выйти за пределы своей текущей рабочей директории — как случайно, так и из-за инъекций промптов. Доступ к файловой системе и сети можно ограничить с помощью инструментов изоляции на уровне ОС (landrun в Linux, sandbox-exec в macOS и Sandboxie в Windows). Однако в таком случае на клиента (программу, которую пользователь использует для взаимодействия с агентом или интерфейсом командной строки вроде Claude Code или Codex) ложится задача обернуть запущенный агент и обеспечить соблюдение необходимых политик.

Удаленное выполнение по умолчанию предоставляет лучшие гарантии: среда агента изолирована от среды разработчика. Доступ агента к ресурсам можно ограничить с помощью средств контроля файловой системы и сети, уменьшая зону поражения.

Основное различие между подходами заключается главным образом в объеме требуемой ручной настройки. Хост SSH требует предоставленной пользователем машины и ручной настройки. Docker может быть настроен либо клиентом, либо администраторами организации. Docker Sandboxes идут дальше и запускают каждого агента в собственной микроВМ. Облачные решения должны обрабатывать настройку сред автоматически на основе параметров, определенных вашей командой или администратором организации.

Как работает песочница для облачных агентов в Air

Агентное ядро, обеспечивающее работу облачных агентов в Air, следует подходу, используемому в Docker Sandboxes. Каждая задача запускает ВМ в облаке (микроВМ появятся в ближайшее время), а агент работает в Docker-контейнере внутри этой ВМ. ВМ считается ненадежной: она не используется повторно между задачами и ей разрешен доступ только к ограниченным внутренним ресурсам. В ВМ настраивается прокси-сервер, поэтому все соединения из контейнера агента маршрутизируются через него.

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

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

Где работает агент, так же важно, как и то, что он может делать

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

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

Разработчики, работающие в организациях, уже могут опробовать облачных агентов в Air в средах разработки JetBrains и Air Teams в браузере.

Есть вопрос или отзыв? Отметьте нас в X по адресу @getsome_air — Деннис и команда Air читают упоминания и отвечают.

Узнать больше

О чём эта статья

Ещё в разделе «Разработка ПО»

Все →

Ещё от JetBrains