Контрольный список границ изоляции песочницы AI-агента для проверок безопасности

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

Почему важны проверки изоляции AI-агентов

Традиционные проверки песочниц часто начинаются с одного вопроса: может ли эта система выполнять непроверенный код, не подвергая хост опасности? Проверки AI-агентов требуют этого вопроса, но также нуждаются в более широком контрольном списке, потому что агенты делают больше, чем просто выполняют один скрипт. Они могут клонировать репозитории, устанавливать пакеты, просматривать сайты, записывать файлы, вызывать API, открывать GUI-сессии, повторять неудачные команды и превращать вывод модели в действия в оболочке.

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

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

Безопасность границы выполнения

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

Проверьте:

• Какой уровень изоляции используется: контейнер, микроВМ, полная ВМ, посредничество системных вызовов типа gVisor, песочница Kubernetes или другая модель?
• Получает ли каждая песочница собственную границу ядра или она разделяет ядро хоста?
• Разделены ли ЦП, память, файловая система, таблица процессов, сетевой стек и доступ к устройствам от других нагрузок?
• Может ли песочница получить доступ к сокетам среды выполнения контейнеров, пространствам имен процессов хоста, путям хоста, службам метаданных облака или привилегированным устройствам?
• Как браузерные сессии, GUI-десктопы, VNC-потоки и интерпретаторы кода размещаются внутри одной и той же границы?
• Каково задокументированное предположение об уходе с хоста: сдерживание, снижение риска или более сильная гарантия?

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

Безопасность файловой системы и монтирований

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

Проверьте:

• Является ли файловая система по умолчанию пустой, основанной на шаблоне или предварительно загруженной файлами проекта?
• Какие пути доступны для записи агенту, а какие только для чтения?
• Смонтированы ли каталоги хоста, репозитории, SSH-ключи, кеши пакетов, профили браузера или файлы конфигурации облака в песочницу?
• Может ли агент перемещаться по символическим ссылкам или точкам монтирования bind в непредусмотренные пути?
• Ограничен ли доступ к файлам на уровне песочницы, пользователя, проекта или организации?
• Удаляются ли загруженные файлы, сохраняются ли, делаются ли снимки или становятся ли доступными для последующих сессий?
• Можно ли просмотреть сгенерированные файлы и различия до того, как они покинут песочницу?

Для агентов-кодеров самый безопасный шаблон — это обычно узкое рабочее пространство проекта, явный экспорт артефактов и отсутствие фонового доступа к домашним каталогам разработчика или общим хранилищам учетных данных.

Контроль процессов и ресурсов

Агент может случайно создать fork-бомбу, зависнуть при сборке, заполнить диск, запустить фоновый сервер или повторять дорогостоящую команду. Контроль ресурсов превращает такие сбои в ограниченные сбои.

Проверьте:

• Применяются ли ограничения на ЦП, память, диск, файловые дескрипторы, количество процессов и время выполнения?
• Есть ли максимальная продолжительность по часам для команд и сессий?
• Могут ли фоновые процессы выжить после завершения команды?
• Убиваются ли дочерние процессы при остановке или сбросе песочницы?
• Может ли агент открывать прослушивающие порты, и если да, то доступны ли эти порты только через явный механизм предварительного просмотра?
• Обрезаются ли большие stdout/stderr логи, передаются ли они потоком или сохраняются?
• Видны ли сбои из-за превышения лимитов вызывающему объекту, а не молча повторяются?

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

Сетевой контроль и контроль исходящего трафика

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

Проверьте:

• Включен ли исходящий доступ в интернет по умолчанию?
• Можно ли отключить сетевой доступ на уровне песочницы, шаблона или проекта?
• Доступны ли белые списки исходящего трафика для доменов, диапазонов IP, портов или протоколов?
• Заблокирован ли доступ к конечным точкам метаданных облака?
• Может ли песочница достичь частных VPC, внутренних сервисов, баз данных или систем развертывания?
• Управляются ли трафик браузера, трафик CLI, трафик менеджера пакетов и прямые сокетные соединения одной и той же политикой?
• Регистрируются ли исходящие запросы с отметкой времени, назначением, контекстом процесса или команды и статусом ответа?

Относитесь к исходящему трафику агента как к исходящему трафику системы сборки. Если агент может устанавливать пакеты, загружать артефакты, вызывать вебхуки или просматривать произвольные сайты, проверка должна охватывать как вредоносный код, так и поведение, вызванное инъекцией промптов.

Риски DNS и доступа к пакетам

DNS и менеджеры пакетов легко упустить из виду, потому что они кажутся инфраструктурными деталями. Для агентов они являются частью поверхности выполнения. Сгенерированный скрипт может закодировать данные в DNS-запросах, загрузить опечаточный пакет или извлечь скрипт из URL, который никогда не проверялся.

Проверьте:

• Следует ли DNS-трафик той же политике исходящего трафика, что и HTTP и HTTPS?
• Регистрируются ли DNS-запросы, фильтруются ли или направляются ли через контролируемые резолверы?
• Могут ли менеджеры пакетов по умолчанию обращаться к публичным реестрам?
• Есть ли белый список реестров пакетов, проксируются ли они, кешируются или закрепляются?
• Фиксируются ли имена установленных пакетов, версии, URL, хеши и изменения lockfile?
• Может ли агент запускать скрипты установки, хуки после установки или произвольные шаги сборки пакетов?
• Есть ли шлюз проверки перед тем, как новые зависимости будут сохранены в шаблоне или производственном рабочем процессе?

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

Обработка секретов

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

Проверьте:

• Внедряются ли секреты только тогда, когда задача явно в них нуждается?
• Ограничены ли секреты песочницей, задачей, репозиторием, окружением и временем жизни?
• Можно ли прочитать секреты из переменных окружения, файлов, истории команд, списков процессов, логов, скриншотов или хранилища браузера?
• Редактируются ли логи и артефакты перед хранением или экспортом?
• Используются ли короткоживущие токены вместо долгоживущих учетных данных?
• Может ли агент получить доступ к SSH-ключам на уровне пользователя, учетным данным Git, облачным учетным данным, куки браузера или API-ключам с хоста?
• Виден ли доступ к секретам в аудиторских логах?

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

Логи и аудиторские следы

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

Проверьте:

• Регистрируются ли вызовы команд с аргументами, рабочим каталогом, кодом выхода, временем начала и продолжительностью?
• Записываются ли чтения, записи, удаления, загрузки, скачивания и изменения прав доступа к файлам?
• Регистрируются ли установки пакетов и внешние извлечения?
• Фиксируются ли действия браузера, скриншоты, загрузки и отправки форм, где это уместно?
• Коррелируются ли вызовы API, вызовы инструментов и переходы от модели к инструменту с одной и той же сессией?
• Устойчивы ли логи к вмешательству изнутри песочницы?
• Каков период хранения и кто может получить доступ к логам?

Для регулируемых или корпоративных рабочих процессов аудиторский след должен поддерживать как отладку, так и восстановление после инцидента. Частичная стенограмма терминала обычно недостаточна.

Захват и проверка артефактов

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

Проверьте:

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

Цель — сохранить полезные доказательства, избегая при этом второго канала утечки данных через логи, скриншоты, архивы или сгенерированные пакеты.

Управление жизненным циклом и сбросом

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

Проверьте:

• Создается ли каждая песочница заново, возобновляется из состояния или клонируется из шаблона?
• Какие данные сохраняются при паузе, возобновлении, создании снимка, шаблона и удалении?
• Очищаются ли временные файлы, кеши пакетов, история команд, куки браузера и локальные базы данных при сбросе?
• Может ли скомпрометированная сессия отравить повторно используемый шаблон?
• Есть ли максимальное время жизни сессии?
• Действительно ли остановленные песочницы завершены, или фоновые задачи могут продолжаться?
• Можно ли воспроизвести ту же задачу из чистого окружения?

Сбрасываемость важна и для рабочих нагрузок оценки и обучения с подкреплением. Если каждое испытание начинается из немного разного состояния, результаты безопасности и поведение модели становятся менее надежными.

Контроль утверждения человеком

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

Проверьте:

• Какие действия могут выполняться автономно, а какие требуют утверждения?
• Достаточно ли конкретны подсказки для утверждения, чтобы показать команду, файлы, назначение, область действия учетных данных и ожидаемый эффект?
• Могут ли политики требовать утверждения для установки пакетов, внешнего сетевого доступа, записи в репозиторий, команд развертывания или доступа к секретам?
• Регистрируются ли утверждения с указанием пользователя, отметки времени, действия и результирующей команды?
• Могут ли утверждения быть ограничены по времени и привязаны к задаче, а не предоставлять широкое разрешение на будущее?
• Есть ли путь аварийного доступа, и аудируется ли он?

Используйте утверждение человеком для необратимых или высокорисковых действий: удаление файлов, запись в производственные ветки, вызов API развертывания, доступ к данным клиентов и изменение шаблонов песочниц.

Предположения о реагировании на инциденты

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

Проверьте:

• Кто отвечает за триаж, когда есть подозрение, что песочница утекла данные или запустила вредоносный код?
• Могут ли песочницы быть убиты, помещены в карантин или заблокированы на уровне проекта или организации?
• Можно ли быстро отключить исходящий сетевой трафик?
• Сохраняются ли логи и артефакты для расследования?
• Аннулируются ли затронутые шаблоны, кеши пакетов и снимки?
• Отзываются ли учетные данные автоматически или через задокументированную инструкцию?
• Есть ли четкое различие между проблемой сдерживания песочницы и проблемой политики агента?

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

Как вписывается Novita Agent Sandbox

Novita Agent Sandbox предназначен для AI-сгенерированного кода, браузерных рабочих процессов, использования компьютера, оценок, сред обучения с подкреплением и долгоживущих задач. На странице продукта описаны изолированные песочницы, запуск за доли секунды, постоянные сессии, просмотр живых сессий через VNC, ценообразование на основе использования, шаблоны и поддержка изолированной файловой системы. Краткое руководство по Novita Agent Sandbox показывает создание песочницы через SDK, выполнение команд, список файлов и остановку песочницы.

Эти возможности могут поддерживать многие рабочие процессы из этого контрольного списка, но критерии оценки и утверждения о продукте должны оставаться раздельными. Когда ваша команда проверяет Novita Agent Sandbox или любую другую среду выполнения агента, сопоставьте живую конфигурацию, которую вы планируете использовать, с указанными выше средствами контроля: граница, файлы, ограничения процессов, сеть, DNS, загрузка пакетов, секреты, логи, артефакты, жизненный цикл, утверждение и реагирование на инциденты.

Для инженерных команд, уже использующих API моделей Novita AI, объединение вывода модели с выполнением в песочнице может уменьшить разрозненность платформы для рабочих нагрузок агентов. Для конфиденциального с точки зрения безопасности производства все равно проводите проверку, специфичную для рабочей нагрузки, перед подключением песочницы к частным репозиториям, конфиденциальным наборам данных, внутренним сервисам или учетным данным для развертывания.

Заключение

Одобряйте песочницу AI-агента только после того, как проверка сможет четко ответить на три вопроса: что изолировано, что все еще может покинуть границу и какие доказательства останутся, если что-то пойдет не так. Если эти ответы расплывчаты, ограничьте песочницу нечувствительными рабочими нагрузками до тех пор, пока отсутствующие средства контроля не будут задокументированы и протестированы.

FAQ

Что должна в первую очередь проверить команда безопасности при проверке песочницы AI-агента?

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

Достаточно ли песочницы только на основе контейнера для автономных агентов-кодеров?

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

Почему DNS и доступ к пакетам следует проверять отдельно от общего исходящего трафика?

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

Рекомендуемые статьи:

• How Agent Sandboxes Power Secure, Scalable AI Innovation
• Building a Coding Agent with Novita’s Agent Sandbox
• Novita vs E2B: The Ultimate Agent Sandbox Comparison for Developers and Businesses