Кейс: песочница агента с изолированным репо и ключом подписи — micahflee

Свой агент пишет код, запускает команды и делает коммиты в GitHub. Но если он работает на вашей машине с полным доступом к SSH-ключам, файловой системе и всем репозиториям — одна промпт-инъекция превращает его в вектор атаки. Micah Lee (The Intercept, автор Python-инструментов) показал конкретное решение: Docker Sandboxes (sbx), изолированный SSH-агент с единственным ключом подписи, GitHub PAT с доступом к одному репо и пометка «(agent)» в имени автора. Разбор его схемы с командами, скриншотами и уроками.

Зачем изолировать агента

В конце августа 2026 года три события сложились в одну цепочку:

1. Johann Rehberger (embracethered.com, 26.08) показал атаку на Claude Code auto mode с 60–80% успеха: ZIP-архив с JavaScript-шadowing модулем struct.py, и агент сам запускает вредоносный код, потому что отказывается от подозрительного бинарника и пишет свой декодер.

2. Simon Willison (simonwillison.net, 27.08) прокомментировал:

«The only safe way to run agents if there’s any risk of attracting the attention of an adversarial attack is with a sandbox. Run unattended coding agents in a container, VM or OS sandbox. Restrict network egress. Monitor your agents.»

Единственный безопасный способ запускать агентов, если есть риск привлечь внимание атакующего — песочница. Запускайте агентов без присмотра в контейнере, VM или песочнице ОС. Ограничьте сетевые исходящие соединения. Следите за агентами.

1. Micah Lee (micahflee.com, 28.08) опубликовал не теорию, а рабочую схему: пошаговую инструкцию настройки изолированной среды для кодинг-агента с подписью коммитов и ограничением доступа.

Для Rehberger и Willison песочница — единственный ответ на атаку. Micah показал, как эту песочницу реально настроить.

Что такое Docker Sandboxes (sbx)

Docker Sandboxes — это не Docker Desktop и не обычные контейнеры. Это microVM: виртуальная машина со своим Docker-демоном, файловой системой и сетью. Агент внутри не может повлиять на хост — изоляция идёт на уровне виртуализации, а не на уровне namespaces.

Docker Sandboxes run AI coding agents in isolated microVM sandboxes. Each sandbox gets its own Docker daemon, filesystem, and network — the agent can build containers, install packages, and modify files without touching your host system.

Docker Sandboxes запускают ИИ-агентов в изолированных microVM-песочницах. Каждая песочница получает собственный Docker-демон, файловую систему и сеть — агент может собирать контейнеры, устанавливать пакеты и изменять файлы, не затрагивая хост-систему.

— Документация Docker Sandboxes

Ключевые отличия от контейнеров:

• Каждая песочница — отдельная microVM, не namespace в общей ОС.
• Свой Docker-демон внутри: агент может запускать docker build, не ломая хост.
• CLI — sbx, бесплатный для коммерческого использования.
• Поддерживаются несколько агентов: Claude Code, Codex, Gemini CLI и другие.

Схема Micah: три слоя защиты

Micah построил три уровня изоляции, каждый из которых решает свою задачу:

Слой 1. Docker Sandbox (microVM)

Агент работает внутри sbx create. Файлы хост-системы, SSH-ключи, облака и credentials — за стенкой microVM. Агент имеет доступ только к той директории, которая явно смонтирована в песочницу.

Слой 2. Изолированный SSH-агент

Главная проблема Docker Sandboxes: чтобы агент мог подписывать коммиты, ему нужен SSH-агент. По умолчанию sbx daemon start пробрасывает хостовый SSH-агент — со всеми вашими ключами.

Micah написал скрипт start-isolated-ssh.sh, который:

1. Создаёт новый SSH-агент (не хостовый).
2. Загружает в него только ~/.ssh/agent-signing-key — ключ, который используется исключительно для подписи коммитов.
3. Перезапускает sbx daemon с этим изолированным агентом.

# Ключевые строки из start-isolated-ssh.sh (упрощённо)
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/agent-signing-key    # только один ключ!
sbx daemon stop
sbx daemon start -d                 # sbx подхватит новый SSH-агент

После этого ssh-add -L внутри песочницы показывает только один ключ — agent signing key. Личные ключи, ключи от других аккаунтов — недоступны.

Слой 3. GitHub PAT с ограничением по репо

GitHub Fine-grained Personal Access Token (PAT) создаётся с явным ограничением:

• Repository access: Only select repositories — только один конкретный репозиторий.
• Permissions: Contents (read/write), Issues (read/write), Pull requests (read/write), Actions (read-only), Commit statuses (read-only), Metadata (read-only).

Токен передаётся в песочницу через sbx secret set github --sandbox sandbox-name. Флаг --sandbox критичен: без него токен станет глобальным для всех песочниц.

Подпись коммитов: agent-only ключ и пометка в имени

Micah убеждён, что авторство LLM нужно показывать явно. Его схема: каждый коммит агента подписывается отдельным SSH-ключом и содержит пометку в имени автора.

Шаг 1. Генерация ключа

ssh-keygen -t ed25519 -f ~/.ssh/agent-signing-key

Публичный ключ добавляется в GitHub Settings → SSH keys как signing key (не authentication key!). Если сделать его authentication key — агент получит доступ ко всем вашим репозиториям через SSH-clone.

Шаг 2. git config внутри песочницы

git config --global user.name "Micah Lee (agent)"
git config --global user.email micah@micahflee.com
git config --global gpg.format ssh
git config --global user.signingkey "key::$(ssh-add -L | head -n 1)"
git config --global commit.gpgsign true

Итоговый коммит выглядит так:

Author: Micah Lee (agent) <micah@micahflee.com>

Если вы видите «Micah Lee (agent)» — это коммит агента, а не человека. GitHub показывает его как Verified, потому что он подписан агентным ключом.

Зачем это нужно

1. Прозрачность: коллеги видят, что коммит сделан LLM, а не человеком. Это влияет на код-ревью: авто-сгенерированный код стоит проверять тщательнее.
2. Аудит: в git-логе легко найти все коммиты агента по подписи ключа.
3. Ограничение вреда: если агента скомпрометируют, атакующий сможет подписать коммиты только этим ключом — а не получить доступ ко всему GitHub-аккаунту.

Пошаговый разбор настройки

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

git clone https://github.com/micahflee/sandbox-test.git sandbox-test-1
git clone https://github.com/micahflee/sandbox-test.git sandbox-test-2

Создание песочниц:

sbx create --name sandbox-test-1 --no-share-skills claude ~/code/sandbox-test-1
sbx create --name sandbox-test-2 --no-share-skills claude ~/code/sandbox-test-2

Параметр --no-share-skills запрещает агенту использовать глобальные навыки из хоста — ещё один слой изоляции.

Настройка GitHub-credentials для каждой песочницы:

sbx secret set github --sandbox sandbox-test-1
# ввести GitHub PAT
sbx secret set github --sandbox sandbox-test-2
# ввести тот же PAT

Запуск изолированного SSH-агента и перезапуск sbx-демона:

source ~/.local/bin/start-isolated-ssh.sh
# ввести passphrase от agent-signing-key

Верификация внутри песочницы:

# Проверка GitHub-аутентификации
gh auth status
# Должно показать: Logged in to github.com account micahflee (GH_TOKEN)

# Проверка SSH-ключа
ssh-add -L
# Должен показать только agent-signing-key

Проверка: коммит и PR

Micah попросил агента сделать коммит и открыть PR:

«sup, Claude? you’re running in a sandbox. I want to make sure everything works right. add something clever to the readme, and then create a new commit in its own branch and create a PR for it.»

Через 30 секунд агент создал подписанный коммит и открыл PR без каких-либо запросов прав. Коммит подписан агентным ключом (Verified), автор — «Micah Lee (agent)», в Co-Author указан Claude Opus 5.

DEF CON AI Village и HalCTF

Micah упоминает, что перед настройкой песочницы посетил DEF CON, где играл в HalCTF (Hostile Autonomous Layer CTF) в AI Village.

HalCTF — это CTF-соревнование, где участники не атакуют цели напрямую, а создают автономных агентов, которые атакуют изолированные цели самостоятельно. Участники загружают Docker-контейнеры со своими агентами, а модели выбираются из списка малых моделей (Qwen 3.5-4B, Llama 3.2-3B и другие).

Контекст HalCTF важен: Micah увидел, как малые модели в изолированных контейнерах находят эксплойты. Это подкрепило его подход: агенты — полезные инструменты, но они должны работать в условиях, где их компрометация не выходит за пределы песочницы.

Совет Micah: сервер вместо ноутбука

В конце поста Micah даёт practical tip:

«Another cool trick: If you can, do this all on a server instead of your laptop (SSHed in and in a tmux session). If you’re doing anything sensitive, do it on a home server instead of a cloud server.»

Если вы запускаете несколько агентов параллельно — сервер в tmux с закрытой крышкой ноутбука. Агенты работают, вы возвращаетесь к готовым PR. Домашний сервер надёжнее облачного для конфиденциальных задач.

Ограничения схемы

1. Docker Sandboxes — не бесплатен для всех. CLI бесплатен, но organization governance требует подписки. В РФ — через VPN, как и Docker в целом.

2. Настройка — не тривиальна. Скрипт изолированного SSH-агента, несколько песочниц, токены с правильными scope — на первый проект уйдёт час. Потом конфигурация копируется.

3. Один агент — одна песочница. Если нужно 10 параллельных задач — 10 песочниц, 10 клонов репозитория. Масштабирование — через автоматизацию (скрипты, CI), не через «одну большую среду».

4. Файлы хоста не доступны. Если агенту нужен доступ к другому репозиторию или локальным конфигам — их нужно копировать в песочницу вручную.

5. Агент не «замечает» ограничений. Он не знает, что работает в песочнице, пока вы не скажете. Micah явно говорит агенту в промпте: «you’re running in a sandbox» — это помогает, но не гарантирует, что агент не попробует выйти за границы (модель может попытаться использовать инструменты, которых нет в песочнице).

Реалии для российских разработчиков

Docker Sandboxes (sbx): Docker Inc. — американская компания. Docker Hub блокируется регулярно, Docker Desktop — платный для организаций (для ИП и физлиц — бесплатно, но требует регистрацию). Docker Sandboxes как продукт появился в 2026 году, в рунете практически не освещён — ни Habr, ни vc.ru, ни Tproger не публиковали обзоров. Установка через sbx CLI возможна через VPN. Оплата подписки — зарубежными картами (USDT/крипта через посредников) или через организацию с международным аккаунтом.

GitHub: доступен без VPN. Fine-grained PAT доступен всем пользователям. Оплата Pro/Team — через зарубежную карту, крипту или прокси-сервисы (например, onepanel, vpay). Оплата российскими картами (Mir) не поддерживается GitHub напрямую.

Живые ссылки на русскоязычное освещение: тема песочниц для ИИ-агентов в рунете практически не освещена на момент публикации. Docker Sandboxes как продукт — новинка, даже англоязычные обзоры свежие (август 2026). Ближайшие материалы — общие статьи про контейнеризацию для разработки, но без привязки к кодинг-агентам.

Что даёт схема Micah

Угроза	Что блокирует
Агент читает файлы хоста	Sandbox: файловая система изолирована
Агент крадёт личные SSH-ключи	Изолированный SSH-агент: только signing key
Агент доступен ко всем репозиториям	GitHub PAT: доступ к одному репо
Коммиты неразличимы от human	Подпись agent-only ключом + «(agent)» в имени
Агент запускает вредонос на хосте	microVM: полная изоляция от хост-ОС

Если атакующий внедрит промпт-инъекцию (как Rehberger показал для auto mode) — агент в песочнице сможет выполнить вредоносный код, но только внутри microVM. Утечка данных за пределы песочницы потребует дополнительных векторов атаки на Docker-демон или microVM-гипервизор, что существенно сложнее.

С чего начать

1. Установите sbx CLI и создайте первую песочницу: sbx run claude — это минимальный старт.
2. Сгенерируйте agent-only SSH-ключ: ssh-keygen -t ed25519 -f ~/.ssh/agent-signing-key и добавьте его в GitHub как signing key (не authentication).
3. Создайте Fine-grained PAT с доступом к одному репозиторию и ограничьте permissions только тем, что нужно (Contents, Issues, Pull requests).
4. Напишите скрипт изолированного SSH-агента по образцу Micah и перезапустите sbx daemon с ним.
5. Настройте git config внутри песочницы: user.name = "Ваше Имя (agent)", gpg.format = ssh, commit.gpgsign = true.

Ссылки на статьи недели: Песочницы для ИИ-агентов: запускаем код изолированно (общая теория), Промпт-инъекции в кодинг-агентах (почему это важно), Взлом Claude Code auto mode — разбор атаки Rehberger (конкретная атака, которую решает песочница), Что такое агентный кодинг (введение в тему).

Источники

• Micah Lee, «Sandboxing coding agents» (28.08.2026) — micahflee.com
• Docker Sandboxes — документация — docs.docker.com/ai/sandboxes
• Johann Rehberger, «Breaking Claude Code Opus 5 Auto Mode» (26.08.2026) — embracethered.com
• Simon Willison, комментарий к атаке Rehberger (27.08.2026) — simonwillison.net
• AI Village, «HalCTF: Hostile Autonomous Layer CTF at DEFCON 34» — aivillage.org
• GitHub Fine-grained PAT — docs.github.com