TL;DR: две новости об изоляции агентов:

  • anthropic выпустил документацию по настройке auto mode: классификатор проверяет вызовы инструментов, которые не разобрали обычные правила разрешений, запретов и подтверждений, а блок autoMode помогает его настроить — через него описывают окружение и добавляют свои правила поверх встроенных.
  • docker выпустил sbx — изолированные микро-виртуалки, в которых у агента своё ядро и свой демон docker, а исходящий трафик идёт через хостовый прокси со списком разрешённых доменов.

Классификатор понимает намерение, песочница не даёт дотянуться. Ставить стоит оба.

Классификатор внутри процесса

Auto mode убирает рутинные подтверждения: вместо вопроса на каждую команду классификатор сам проверяет вызовы, которые не разобрали обычные правила разрешений, запретов и подтверждений. Он блокирует необратимые и разрушительные действия, а также обращения за пределы доверенного окружения. Граница доверия по умолчанию — рабочий каталог и настроенные remote текущего репозитория. Всё остальное классификатор считает возможным адресатом утечки, пока вы не назовёте его явно. Хотя срабатывает это не всегда ¯\_(ツ)_/¯

Настройка — четыре массива правил, текстом, а не регулярками и масками:

  • environment — описание окружения: на каком хосте лежат репозитории, какие домены и бакеты свои, какие сервисы внутренние, что считать чувствительным
  • allow — исключения из правил soft_deny
  • soft_deny — разрушительные действия, которые перебиваются явным намерением
  • hard_deny — безусловный запрет, его не перебивает ничто

Встроенных правил в soft_deny много, и внешними адресатами они не ограничены. Там удаление по непроверенному пути, force push, деплой в production, отключение проверки tls, запись секрета в файл, merge без ревью, одобрение собственного pr, удаление серверов, правка собственных разрешений агента, действия через chrome-mcp. За пересечение границы доверия отвечает единственное правило hard_deny: оно запрещает утечку данных наружу.

Порядок приоритетов: hard_deny → soft_deny → allow → прямое намерение пользователя. Намерение засчитывается, только если сообщение описывает именно это действие: «почисти репозиторий» не разрешает force push, «сделай force-push этой ветки» разрешает.

Ещё несколько деталей, которые в документации замечаешь не сразу:

  • литерал "$defaults". Он вставляет встроенный список на своё место, и без него ваш массив заменяет встроенные правила целиком. Задали soft_deny без "$defaults" — потеряли весь встроенный список
  • autoMode читается только из пользовательских и управляемых настроек. Из .claude/settings.json и .claude/settings.local.json — нет: оба лежат в каталоге репозитория, то есть репозиторий мог бы подсунуть себе разрешения
  • узкие правила вида Bash(npm test) срабатывают до классификатора, поэтому префикс может пропустить непредусмотренный аргумент. Лечится флагом classifyAllShell: true — он на время auto mode отключает все разрешающие правила Bash и PowerShell, поэтому классификатор проверяет каждую команду
  • правила из всех областей складываются: разработчик может расширить любой список, но не убрать управляемую запись. При этом его собственный allow гасит организационный soft_deny. Жёсткая граница — только permissions.deny в управляемых настройках, она отрабатывает раньше классификатора

С 14 августа 2026 года auto mode становится режимом по умолчанию для новых сессий в тарифах Pro, Max и Team.

Микро-вм песочница

docker решает ту же проблему, но гипервизором. Каждая песочница — отдельная микро-виртуалка: поднимается за секунды и живёт, пока её не удалят. docker desktop не нужен, сам sbx бесплатен — платное только централизованное управление.

Изоляция собрана из пяти слоёв.

  • Гипервизор. Своё ядро на песочницу, общей памяти и общих процессов с хостом нет.
  • Сеть. Весь http и https идёт через прокси на хосте. По умолчанию запрещено всё, кроме списка доменов, причём фильтр стоит и на dns: для имени не из списка адрес просто не вернётся. Сырой tcp обрывается не на подключении, а на данных: connect проходит, дальше не идёт ничего. udp и icmp закрыты, localhost хоста недоступен.
  • Docker. Внутри свой демон и свой кеш образов, слои между песочницами не переиспользуются.
  • Рабочий каталог. Монтируется по тому же абсолютному пути, что и на хосте, так что пути в логах сборки выглядят как обычно. Флаг --clone отдаёт репозиторий только на чтение, а агент работает с приватной копией.
  • Учётные данные. Ключи api внутрь не попадают: заголовок Authorization подставляет прокси на хосте. Запрос из песочницы с подставным токеном получает 200 там, где тот же запрос с хоста получает 401.

Что чем закрывается

Слои независимы, и разница видна по тому, что каждый пропускает.

Классификатор работает с намерением. Он понимает, что отправить содержимое репозитория в сторонний api — это риск утечки, даже если технически это обычный curl. Но он живёт в том же процессе, что и агент, его правила — это инструкции, которые интерпретирует модель. Защита более простая и гибкая, но недетерминированная и обходимая.

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

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