Що сталося

У блозі Docker Шріні Секаран і Олег Селаєв розбирають, чому «пісочниця» — не контейнер з агентом усередині. Контейнер ізолює застосунок: простори імен дають свій вид файлів і мережі, групи контролю відміряють процесор, пам’ять і диск. Старт швидкий, щільність висока, спільний примітив для Compose, Kubernetes і майже будь-якої збірки. Якщо треба підняти сервіс, виконати уривок коду чи прогнати оцінку і зникнути, контейнер лишається нормальним вибором.

Агент поводиться як людина за ноутбуком, а не як процес із відомим набором залежностей. Він клонує репозиторій, ставить пакети, піднімає PostgreSQL, ганяє міграції, збирає образи, читає журнали і пробує знову годинами. Кожен крок спирається на те, що лишив попередній. Контейнер розрахований на збірку з образу і кількох явних томів: усе, що агент створив повз них, зникає при перестворенні.

Друга різниця — звідки беруться команди. Рішення, що запустити, ймовірнісне. Інструкції приходять із файлів, завдань, сторінок, опису пакетів і відповідей інструментів. Частину цього входу ніхто не перевіряв. У тексті згадують уже бачений випадок, коли агент видалив бойову базу, хибно прочитавши завдання. У режимі, де підтвердження вимкнені, ловити це нікому.

Пісочниця запускається однією командою sbx run claude. Її можна зупинити і продовжити: поставлене агентом лишається, поки пісочницю не видалять. Усередині в агента є права суперкористувача і свій Docker, без сокета демона на хості.

Чому це важливо

Втеча з контейнера впирається в спільне ядро. Далі — ядро машини, сусідні процеси і змонтовані секрети. На macOS і Windows контейнери і так сидять у віртуальній машині Docker Desktop, але одне з одним вони все одно ділять одне ядро цієї машини. МікроВМ ставить гіпервізор між агентом і вашим ядром: вийшов із контейнера — опинився в одноразовій гостьовій системі, хост зовні. Два агенти на одній машині не бачать пісочниць один одного. Доступне лише те, що ви самі віддали: робочий каталог, дозволені адреси, сервери MCP і навички.

Окрема дірка — сокет /var/run/docker.sock. Його монтують у Compose, у збірках і в засобах спостереження, і він віддає контейнеру керування демоном хоста. Агенту не потрібен новий експлойт: він оглядає середовище, бо робота в цьому і полягає. У демонстрації з доповіді агент так дістався файлу з секретами на хості. У пісочниці демон свій, усередині гостя. Сокет хоста зовні.

Правила, які агент може прочитати, він може обійти. Вихідний трафік у цій схемі йде через проксі на хості зі списком заборони за замовчуванням. Для частини HTTP-сервісів ключ підставляє той самий проксі, і сире значення у віртуальну машину не потрапляє. Каталог проєкту за замовчуванням змонтований на запис: агент може правити і видаляти файли. Режим клону дає йому приватну копію всередині машини, вихідний репозиторій при цьому лишається читабельним.

На практиці

Docker називає п’ять приводів почати з пісочниці: агент працює без нагляду або підтвердження вмикаються самі; йому треба збирати образи, Compose або Testcontainers; він читає завдання, сторінки, метадані пакетів або вивід MCP, які писали не ви; ключі не повинні опинитися всередині середовища; сесія довша за одне завдання.

Залізо важче, ніж у ще одного контейнера. Потрібен гіпервізор: Apple silicon і macOS 14 або новіша, Windows Hypervisor Platform, або KVM на підтримуваних збірках Ubuntu. Усередині іншої віртуальної машини потрібна вкладена віртуалізація. Хмарний варіант крутить ту саму ізоляцію на машинах Docker, секрети і мережеві правила в локальної та хмарної копії роздільні. Набори інструментів і файл sbxenv.yaml Docker позначає як ранній доступ і експеримент: колега може підняти ту саму пісочницю однією командою, але формат ще змінюється.

Підсумок

Контейнер ізолює застосунок, який поводиться так, як його зібрали. Агенту потрібна межа, яку модель не переписує, і стан, який живе довше за один процес. Застосунок і далі пакуйте в контейнер. Агента, якщо він ходить у мережу і ставить пакети сам, садіть у мікроВМ.