Sandbox безопасность: как не дать AI агенту случайно снести файловую систему

Sandbox безопасность AI-агентов строится на трёх слоях защиты: permissions с allow/deny-списками, изоляция файловой системы и сети через песочницу, и отдельный контроль доступа для MCP-инструментов. Ни один слой сам по себе не спасает: агент с полным доступом к bash за один запуск может удалить рабочую директорию, а голый sandbox без approval-политики не остановит косвенную промпт-инъекцию. Ниже — как настроить связку permissions + sandbox в Claude Code, зачем нужны Docker-песочницы вроде sbx и E2B, и что реально показало недавнее исследование sandbox escape в популярных AI IDE.

Материал разобран на основе документации Claude Code, видео-разборов permissions/sandbox моделей и исследования Pillar Security по sandbox escape в Cursor, Codex и Antigravity — актуально на момент публикации.

Что такое sandbox безопасность AI-агентов

Sandbox безопасность — это ограничение того, что AI-агент физически может сделать с файловой системой, сетью и процессами хоста, даже если модель ошиблась или её обманули промпт-инъекцией.

Sandbox работает как последний рубеж после permissions: даже если агент получил разрешение выполнить команду, песочница физически не даёт ему выйти за пределы рабочей директории или дотянуться до сети без явного allowlist домена. В Claude Code это реализовано через Bubble Wrap на Linux и Seatbelt на macOS — обе технологии создают отдельное пространство имён для процесса, где нет доступа к остальной системе.

Три составляющих защиты работают в связке, а не по отдельности.

Permissions — это статический слой, который решает, что агенту вообще разрешено запускать.
Sandbox — это OS-уровень, который физически изолирует уже разрешённые команды от остальной системы.
Tools и MCP-серверы — третий контур, у него собственная модель доступа к внешним интеграциям вроде GitHub или базы данных.

Убрать любой из трёх слоёв — значит остаться с дырой там, где остальные два не дотягиваются.

Как настроить permissions в Claude Code

Permissions задаются в settings.json тремя списками — allow, ask, deny. Правила проверяются в порядке deny → ask → allow, и первое совпадение побеждает: deny-правило блокирует вызов, даже если более широкий allow тоже подходит под этот же запрос.

Deny-правила в managed-settings.json действуют для всей машины и не могут быть переопределены разработчиком локально — так в команде запрещают чтение .env или запуск bypass-режима на уровне организации, а не договорённостей на словах. Это разница между политикой и просьбой.

Рабочий deny-список для проекта выглядит примерно так:

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "allow": [
      "Bash(npm install)",
      "Bash(npm run test:*)",
      "Bash(git status)"
    ]
  }
}

Логика простая: явно разрешить безопасные, часто повторяющиеся операции (git status, npm install), явно запретить деструктивные (rm -rf, force push в main, чтение секретов) и оставить режим "ask" для всего пограничного, где нужно подтверждение перед выполнением. Запускать Claude Code стоит от имени непривилегированного пользователя — non-root — тогда даже сбой в permissions не даст процессу лишних системных прав. И держите деструктивный --dangerously-skip-permissions только в изолированном контейнере без интернета — не на рабочей машине с SSH-ключами и облачными токенами.

Sandbox или permissions что важнее для защиты

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

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

Sandbox в Claude Code по умолчанию ограничивает запись только текущей рабочей директорией, а чтение — почти всей системой, кроме явно заблокированных путей. Сеть по умолчанию режется до localhost, пока вы не добавите конкретные домены в allowlist. Важный нюанс: ~/.aws и ~/.ssh читаются по умолчанию, поэтому если работаете с чувствительными credentials — добавляйте их в deny read отдельно, песочница не угадает это за вас.

Есть режим autoallow, который работает независимо от вашей permission mode: даже без accept-edits sandbox-команды выполняются автоматически, если укладываются в границы песочницы. Это удобно для скорости, но означает, что любой файл внутри sandbox-boundary может измениться без запроса подтверждения — учитывайте это, прежде чем оставлять агента без присмотра на ночь.

Docker Sandboxes vs встроенный sandbox Claude Code что выбрать

Docker Sandboxes через CLI sbx запускает агента в полноценной изолированной VM с собственной файловой системой и сетью, а не в облегчённом in-process boundary. Для полного разрешения (yolo mode) на долгих запусках это надёжнее, чем встроенная песочница CLI-инструмента.

Только 18% разработчиков дают AI-агенту полный контроль на своей машине, а 73% считают, что агент должен работать в изоляции по умолчанию — это данные из свежего опроса разработчиков о доверии к автономным агентам. Разрыв между этими цифрами объясняет, зачем вообще нужны отдельные Docker-песочницы поверх встроенных механизмов CLI-инструментов.

Установка Docker Sandboxes занимает пару команд: sbx run claude в директории проекта запускает агента внутри изолированной VM с выбором сетевой политики — open, balanced или locked down. Большинству подходит balanced. Внутри агент работает в режиме "dangerously skip permissions" — но безопасно, потому что вся VM изолирована от хоста целиком, а не только отдельные bash-вызовы. sbx ports --publish открывает dev-сервер в браузере, sbx list показывает все активные песочницы. Headless-режим с флагом -p позволяет прогонять агента через десятки спецификаций подряд без присмотра — от минут до часов автономной работы.

Альтернатива для облачного запуска — E2B: полноценные Linux VM в облаке, которые масштабируются до тысяч параллельных песочниц через SDK на Python или JavaScript. Партнёрство E2B с Docker добавило доступ к каталогу проверенных MCP-серверов внутри песочницы через sandbox.run(), что закрывает вопрос "откуда агент возьмёт доверенные инструменты, если он в изоляции".

Решение	Тип изоляции	Когда использовать
Встроенный sandbox Claude Code (Bubble Wrap / Seatbelt)	In-process, ограничивает bash-подпроцессы	Быстрая защита при обычной разработке, approval fatigue
Docker Sandboxes (sbx)	Полноценная VM, своя файловая система и сеть	Долгие автономные запуски с полным разрешением
E2B	Облачная VM, масштабирование до тысяч песочниц	CI/CD, параллельный запуск множества агентов

Что показало исследование sandbox escape в популярных AI IDE

Исследователи Pillar Security нашли и воспроизвели обходы песочницы в Cursor, Codex, Gemini CLI и Antigravity. Почти во всех случаях агент не ломал sandbox напрямую — он писал файл, который потом без изоляции читал и выполнял другой компонент хоста.

Один из найденных случаев: агент менял интерпретатор virtualenv внутри рабочей директории, а неизолированное Python-расширение Cursor потом само его запускало при автоопределении окружения — баг зафиксирован под advisory GHSA-p9g2-cr55-cw9c и уже закрыт. Другой случай — общий Docker-сокет, доступный сразу нескольким агентам, стал точкой выхода за пределы sandbox в Codex, Cursor и Gemini CLI одновременно.

Вывод исследователей звучит жёстко, но точно: блокировать нужно не только прямые действия агента, а весь набор файлов, которые он может записать, и все компоненты хоста, которые эти файлы потом читают без проверки. Sandbox, который останавливает прямой доступ к диску, но оставляет открытым Docker-сокет или git-хук, защищает только на бумаге. Реальный вопрос для любого AI IDE — не "есть ли sandbox", а "что именно агент может записать, и кто это потом доверчиво прочитает".

Как защититься от косвенной промпт-инъекции через sandbox

Косвенная промпт-инъекция — это скрытая инструкция внутри страницы, файла или письма, которую агент считывает как часть контента и выполняет как команду. Sandbox снижает ущерб от такой атаки, но не предотвращает её саму — для этого нужен отдельный слой проверки входящих данных.

Исследование Meta показало, что больше 86% попыток промпт-инъекции срабатывают хотя бы частично — цифра, которая делает разговор о "теоретической угрозе" неуместным. Термин "безопасность по некомпетентности", когда агент физически не может довести вредоносную команду до конца из-за собственных ограничений, звучит утешительно, но полагаться на него как на защитный механизм нельзя.

Практический пример: AI-агент для покупки книг получил скрытую инструкцию внутри страницы товара и купил книгу по завышенной цене — сам агент не был скомпрометирован, просто честно выполнил то, что прочитал как часть контента. Решение — AI-firewall или AI-gateway между агентом и внешним миром: он проверяет входящие данные от сайтов на скрытый текст и инструкции до того, как они попадут в контекст модели, и фильтрует исходящие запросы агента перед отправкой наружу. Дополнительно стоит сохранять цепочку рассуждений (Chain of Thought) агента — она помогает понять постфактум, где именно он свернул не туда.

Максим: «Для одной ниши Лиза собрала 90 листов Excel и полтора миллиона ключей через Codex — он реально находит запросы, до которых вручную никогда бы не додумались. На 30 минут можно спокойно отойти, он всё соберёт сам. Но это работает именно потому, что задача была в песочнице с ограниченным доступом — не потому, что мы просто понадеялись на удачу.»

Как настроить сетевую изоляцию для AI-агента

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

Настройка в settings.json Claude Code через блок sandbox.network.allowedDomains позволяет перечислить конкретные хосты — github.com, реестр npm, внутренние домены компании — и всё остальное автоматически блокируется. Кастомный прокси для исходящего трафика — ещё один уровень контроля: весь сетевой трафик агента идёт через него, и там же можно логировать каждый запрос для последующего аудита.

Три уровня сетевой политики в Docker Sandboxes — open, balanced, locked down — дают гибкость без необходимости писать правила вручную. Balanced подходит для большинства задач: разрешён доступ к пакетным менеджерам и известным API, всё остальное требует ручного подтверждения через интерфейс sbx, где видно, какие запросы были заблокированы, и можно кликом разрешить конкретный домен. Открытый домен вроде github.com теоретически может быть использован для обхода изоляции — держите это в уме при выборе, что именно вносить в allowlist.

Нужен ли аудит логов если уже настроен sandbox

Да — аудит логов остаётся обязательным даже при настроенной песочнице, потому что sandbox снижает ущерб от атаки, но не создаёт видимости того, что именно агент пытался сделать.

Телеметрия на попытку выполнения того, что агент записал, а неизолированный компонент хоста потом запустил — по данным исследования Pillar Security, именно это "слепое пятно" стало общей точкой во всех найденных обходах песочницы. Без логирования trust handoff между агентом и хостовыми компонентами команда узнаёт о проблеме постфактум, когда ущерб уже нанесён.

Минимальный набор для аудита: алерты на попытки удаления файлов вне рабочей директории, попытки чтения .env и credentials-файлов, запуск команд, помеченных как deny, и любое обращение к локальным демонам вроде Docker-сокета из-под агента. Хранить логи стоит отдельно от рабочей директории проекта — иначе агент теоретически может их же и подчистить при компрометации.

FAQ

Что делает sandbox в Claude Code технически?
Sandbox использует Bubble Wrap на Linux и Seatbelt на macOS — обе технологии создают изолированное пространство имён для процесса с ограничением на запись (только рабочая директория) и сеть (только localhost без явного allowlist).

Можно ли полностью доверять песочнице и отключить permissions?
Нет. Sandbox — это последний рубеж на случай, если permissions уже дали сбой, а не замена им. Исследование Pillar Security показало обходы sandbox через компоненты хоста, которые permissions не покрывают.

Что безопаснее — встроенный sandbox или Docker Sandboxes?
Для коротких сессий с обычным подтверждением хватает встроенного sandbox CLI-инструмента. Для долгих автономных запусков с полным разрешением (yolo mode) надёжнее полноценная VM через Docker Sandboxes или E2B.

Как понять, что агента взломали через промпт-инъекцию?
Прямых признаков может не быть — агент честно выполняет то, что считал частью задачи. Помогает сохранённая цепочка рассуждений (Chain of Thought) и логирование каждого исходящего запроса через AI-firewall.

Нужен ли non-root пользователь для запуска Claude Code?
Да. Claude Code автоматически ограничивает часть разрешений при запуске от root, поэтому непривилегированный пользователь — обязательное условие для того, чтобы sandbox работал как задумано.

Что произойдёт, если песочница сломается во время работы?
В Docker Sandboxes сломанную песочницу можно просто удалить и пересоздать без последствий для хост-системы — данные проекта остаются на диске вне VM.

Стоит ли давать агенту доступ к Docker-сокету?
Только если это критично необходимо для задачи. Исследование сандбокс-эскейпов показало, что общий Docker-сокет — один из самых частых путей выхода за пределы изоляции сразу в нескольких AI IDE.

Глоссарий

Sandbox — изолированная среда выполнения, ограничивающая доступ процесса к файловой системе и сети хоста.
Permissions — статический список правил allow/ask/deny, определяющий, какие команды агент может запускать без подтверждения.
Косвенная промпт-инъекция — скрытая инструкция внутри стороннего контента (страница, файл, письмо), которую агент выполняет как команду.
Allowlist — список явно разрешённых значений (доменов, команд), всё остальное блокируется по умолчанию.
Trust handoff — момент, когда файл или данные, созданные агентом внутри песочницы, попадают к неизолированному компоненту хоста.
Bypass permissions mode — режим полного разрешения без подтверждений, безопасен только в изолированном контейнере без сети.

Итог: как собрать защиту из трёх слоёв

Рабочая связка для vibecoderz-проектов выглядит так: deny-список в settings.json на уровне организации для критичных операций, встроенный sandbox с явным allowlist доменов для повседневной разработки, и Docker Sandboxes или E2B — для долгих автономных запусков в режиме полного разрешения. Отдельно закрывайте вопрос косвенной промпт-инъекции через проверку входящих данных, и не забывайте про аудит: sandbox снижает ущерб, но не заменяет видимость происходящего.

Разбор инструментов для вайб-кодинга и их настроек безопасности — в каталоге Claude Code и Cursor на VibeCoderz. Если настраиваете permissions и sandbox для команды и хочется сверить конфиг — запишитесь на консультацию к Максиму.

Источники: Cloudflare OS: an open platform for agents, apps, and work, The Week of Sandbox Escapes — Pillar Security

Обновлено: август 2026.