Пісочниця для ШІ-агента (AI agent sandbox): контейнер і ключі поза досяжністю

Коротко (TL;DR)

Ізоляція ШІ-агента тримається на трьох незалежних шарах: де агент виконує команди, які секрети він бачить і що йому дозволено робити. Підтвердження команд — це лише третій шар, і він не замінює перших двох.

• Вбудовані пісочниці Claude Code, Codex, Gemini CLI і Cursor обмежують запис, а Claude Code, Codex і Cursor — ще й мережу, але читання за замовчуванням відкрите майже скрізь. У Claude Code пісочниця до того ж вимкнена за замовчуванням і покриває лише shell-команди.
• Контейнер — не повний захист. У режимі без підтверджень шкідливий проєкт може винести все, що лежить усередині контейнера, зокрема облікові дані самого агента. Так пишуть і Anthropic, і OpenAI.
• Ключі тримаємо за межею. op run -- агент віддає агенту всі підставлені секрети. Правильніше давати агенту заглушку, а справжній ключ підставляти на проксі.
• Git worktree — зручність, а не межа безпеки: хук, записаний із worktree, спрацьовує в основному репозиторії. Ми перевірили це самі.
• Для чужого репозиторію Anthropic радить окрему віртуальну машину або хмарну сесію — порівняння підходів є в офіційній документації Claude Code.

Дані й типові налаштування агентів у статті звірено з офіційною документацією станом на 4 листопада 2026 року.

П’ять сценаріїв, від яких потрібна ізоляція агента

ШІ-агент для кодингу — це мовна модель, яка сама читає файли, запускає команди в терміналі й править код. Звідси й ризик: агент робить те, що вважає потрібним, а «потрібне» йому може підказати не лише ви, а й текст у чужому репозиторії. Таку підказку називають prompt injection — впровадження інструкцій через дані, які агент читає.

Нижче п’ять сценаріїв, для кожного є реальний задокументований випадок.

NvidiaAppleTeslaBitcoin

Binance · Wall Street 24/7Акції, золото, нафта і крипта1 акаунтУвесь ринок в одному акаунті Binance — без брокера й рахунку в США

GOLDOILS&P 500

Як почати

Щодо Comment and Control Anthropic присвоїла вразливості статус critical і виплатила дослідникам $100, Google — $1 337 (SecurityWeek, 16 квітня 2026 року). Постмортем Cline формулює головний урок жорстко: дати LLM доступ до shell у CI, де вона обробляє недовірені вхідні дані, — те саме, що дати shell кожному користувачу GitHub.

CVE-2026-98432 у Linux на Ubuntu: як захистити валідатор Ethereum до патча

Qwen 3.8 27B для кодингу: 7 причин «непридатності» і як їх виправити

Скіли для Claude Code: що ставити з 12 репозиторіїв GitHub і як написати свій

Фейкова співбесіда як спосіб зламу: розбір випадку Binance і чек-лист захисту

Coinbase тримає офлайн понад 99% крипти клієнтів: ключі розділені, є «рубильник»

Усі п’ять випадків зводяться до трьох запитань, і кожне — окремий шар захисту:

1. Де виконується агент — просто у вашій системі, в ОС-пісочниці, у контейнері, у microVM чи на окремій віртуальній машині.
2. Що агент бачить — ключі в ~/.ssh і ~/.aws, змінні оточення, .env у проєкті, токени в історії сесій.
3. Що агенту дозволено — правила allow/ask/deny, підтвердження, хуки.

Simon Willison називає небезпечне поєднання «смертельною трійкою»: доступ до приватних даних, контакт із недовіреним контентом і можливість надіслати дані назовні. Ізоляція ШІ-агента — це розрив хоча б однієї ланки: прибрати дані з поля зору, закрити недовірений вхід або перекрити канал назовні.

Модель загроз окремо для Codex ми вже розбирали в матеріалі про пісочницю Codex і модель загроз, а будову захисту Claude Code — у статті про периметри безпеки Claude Code. Тут — наскрізна схема для будь-якого агента.

Загроза, шар захисту й увімкнення в кожному агенті: зведена таблиця

Англомовні гайди з AI agent sandboxing і AI agent sandbox security майже завжди розбирають один продукт, і зведення по п’яти агентах доводиться збирати самому з п’яти документацій. Нижче — воно однією таблицею, станом на 4 листопада 2026 року.

Як читати таблицю. Рядки згори донизу йдуть від дешевого до дорогого: перші три закриваються налаштуванням за хвилину, останні два потребують іншого середовища запуску. Рядок «усередині проєкту» не закривається нічим, крім git і клону: будь-який агент, якому ви дозволили писати в проєкт, може там видалити й зіпсувати файли. Тому правило «закомітити перед запуском агента» працює в будь-якому агенті й не залежить від налаштувань.

Вбудовані пісочниці агентів: що закрито за замовчуванням, а що ні

Вбудована пісочниця — це механізм ОС, який запускає команди агента з урізаними правами. На macOS це Seatbelt, на Linux — bubblewrap (утиліта ізоляції процесів через простори імен ядра). Вона дешева, працює без Docker, але в кожного агента свої типові налаштування.

Binance · Wall Street 24/7А якби ви купили золото влітку?+? %Тренажер на реальних цінах Binance покаже результат. Без грошей і реєстрації

GOLDNVDATSLA

Відкрити тренажер

На скриншоті офіційної документації Claude Code (знято 4 листопада 2026 року) рамка 1 виділяє рядок «Reads»: читання дозволене майже по всій машині, зокрема ~/.ssh і ~/.aws/credentials. Рамка 2 — рядок «Environment variables»: команди в пісочниці успадковують оточення Claude Code разом з усіма секретами в ньому. Це головне, що варто запам’ятати про вбудовані пісочниці: вони захищають від «зламає», але не від «прочитає».

Як увімкнути пісочницю в Claude Code і переконатися, що вона працює

1. Запустіть сесію й виконайте /sandbox. Відкриється панель із вкладками Mode, Overrides і Config. На Linux і WSL2 потрібні bubblewrap і socat — якщо їх немає, панель покаже лише вкладку Dependencies.
2. На вкладці Mode оберіть auto-allow (команди в пісочниці йдуть без підтвердження) або regular permissions (підтвердження лишаються).
3. На вкладці Overrides увімкніть Strict sandbox mode. Без нього агент може попросити повторити команду, що впала, поза пісочницею, а в режимі bypassPermissions такий повтор іде без запитання.
4. Попросіть агента виконати дві перевірки:

touch ~/sandbox-probe
curl --noproxy '*' example.com

Перша команда має впасти з Operation not permitted на macOS або Read-only file system на Linux. Друга — з Could not resolve host: команда не має шляху в мережу повз проксі пісочниці. Якщо touch пройшов, пісочниця не працює — видаліть файл і знову відкрийте /sandbox.

Панель зберігає режим у .claude/settings.local.json поточного проєкту. Щоб пісочниця була в усіх проєктах і закривала ключі, впишіть у ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true,
    "network": {
      "allowedDomains": ["registry.npmjs.org", "pypi.org"]
    },
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws/credentials", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Сам ключ sandbox.enabled: true вмикає режим auto-allow: команди в пісочниці йдуть без підтвердження, а щоб повернути підтвердження, додайте "autoAllowBashIfSandboxed": false. failIfUnavailable важливий: за замовчуванням, якщо пісочниця не піднялася, Claude Code мовчки працює без неї. Вбудованого списку секретів немає — захищені лише ті файли й змінні, які ви перелічили. Синтаксис усіх ключів розібрано в матеріалі про settings.json у Claude Code.

Дві межі, про які часто забувають. Пісочниця працює на macOS, Linux і WSL2, а на нативному Windows команди йдуть без неї. І вона покриває лише shell: інструменти Read, Edit, Write, WebFetch, локальні MCP-сервери й хуки працюють поза пісочницею з вашими повними правами. Запис denyRead не зупиняє інструмент Read.

Codex, Gemini CLI і Cursor: один рядок налаштування

Codex CLI. Запис Codex обмежує робочою папкою, а читання — ні: у нашому замірі 13 серпня 2026 року (CLI 0.147.0) команди в обох режимах читали файли в домашній папці й власний ~/.codex/auth.json. Безпечний інтерактивний режим задається прапорцями codex --sandbox workspace-write --ask-for-approval on-request або в config.toml:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

[shell_environment_policy]
ignore_default_excludes = false

Останній рядок важливий: за замовчуванням Codex лишає командам змінні з KEY, SECRET і TOKEN в імені, а false вмикає їх автоматичне вичищення. Режими докладно розібрано в статті про режими схвалення Codex.

Gemini CLI. Пісочниця вмикається прапорцем gemini -s, змінною GEMINI_SANDBOX=docker або ключем tools.sandbox у settings.json. З --yolo (або --approval-mode=yolo) Gemini CLI вмикає її за замовчуванням сам. На macOS типовий профіль permissive-open пускає мережу й широке читання. Суворіший — SEATBELT_PROFILE=strict-proxied: обмежені і читання, і запис, мережа йде через проксі. У контейнерному режимі (Docker або Podman) пісочниці за замовчуванням доступна лише папка проєкту.

Cursor. Налаштування пісочниці лежать у ~/.cursor/sandbox.json або .cursor/sandbox.json проєкту. Мінімум для роботи із секретами — звузити читання й мережу:

{
  "readBoundary": "workspace",
  "networkPolicy": {
    "default": "deny",
    "allow": ["registry.npmjs.org", "pypi.org"]
  }
}

Значення readBoundary: "workspace" потребує Cursor 3.23 або новішого. Режим Run Everything вимикає і пісочницю, і класифікатор — кожен виклик іде автоматично.

Docker і devcontainer для Claude Code: робоча схема покроково

Devcontainer (контейнер розробки) — це опис Docker-оточення у файлі .devcontainer/devcontainer.json, яке VS Code, Cursor, JetBrains і GitHub Codespaces піднімають однаково в усіх. Агент у ньому працює всередині контейнера, а файли проєкту змонтовані з вашого диска. Anthropic має для цього офіційну фічу Dev Container і еталонну конфігурацію в репозиторії anthropics/claude-code.

Devcontainer для Claude Code: схема з шести кроків

1. Додайте фічу Claude Code у .devcontainer/devcontainer.json:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  },
  "remoteUser": "vscode"
}

1. Працюйте не під root. З прапорцем --dangerously-skip-permissions Claude Code на Linux і macOS не запускається від root, тому remoteUser має бути звичайним користувачем.
2. Збережіть ~/.claude в іменованому томі, щоб не входити заново після кожного перезбирання: том source=claude-code-config,target=/home/vscode/.claude,type=volume у mounts і CLAUDE_CONFIG_DIR з тим самим шляхом у containerEnv. Пам’ятайте, що в цьому томі лежить токен агента — його й винесе шкідливий проєкт, якщо винести вдасться.
3. Закрийте вихідну мережу. Еталонний контейнер Anthropic містить скрипт init-firewall.sh: він ставить iptables -P OUTPUT DROP (увесь вихідний трафік заборонено за замовчуванням) і відкриває список адрес плюс кілька винятків — про них нижче. Для файрвола всередині контейнера потрібні права NET_ADMIN і NET_RAW у runArgs.
4. Не монтуйте секрети хоста: ні ~/.ssh, ні ~/.aws, ні файли хмарних ключів. Anthropic радить замість них токени з доступом до одного репозиторію або короткоживучі токени. Окремо — ніколи не прокидайте /var/run/docker.sock: доступ до сокета Docker дорівнює доступу до хоста.
5. Лише тепер можна запускати claude --dangerously-skip-permissions для роботи без підтверджень, і лише з репозиторіями, яким ви довіряєте.

Що ми знайшли, читаючи еталонний init-firewall.sh станом на 4 листопада 2026 року. Крім діапазонів GitHub, registry.npmjs.org і api.anthropic.com, у списку є sentry.io, statsig.com і домени VS Code. Важливіші три правила, які стоять до списку й не зважають на нього: вихідний SSH на порт 22 до будь-якої адреси, DNS-запити (UDP 53) до будь-якої адреси й увесь трафік у підмережу /24 довкола шлюзу Docker, тобто до вашого хоста. Для git push через SSH це зручно, але для моделі загроз «винести дані» це три відкриті канали: SSH, DNS-тунель (передавання даних усередині DNS-запитів) і сервіси на хості. Якщо git через SSH вам не потрібен, приберіть правило для порту 22. DNS-тунель правкою одного правила не закрити, і для чужого коду це ще один аргумент на користь microVM із проксі.

Рамка на скриншоті виділяє попередження з документації Claude Code про devcontainer (знято 4 листопада 2026 року). У режимі --dangerously-skip-permissions контейнер не заважає шкідливому проєкту винести все, що доступне всередині, зокрема облікові дані Claude Code у ~/.claude. OpenAI пише те саме про Codex: із devcontainer можна винести все, зокрема облікові дані Codex. Частина гайдів у мережі подає Docker як повний захист і водночас кладе ANTHROPIC_API_KEY просто в оточення контейнера — тобто туди, звідки його й заберуть.

Claude Code sandbox vs Docker: що обрати

Коротка відповідь: це різні шари, і вони доповнюють один одного.

Практична зв’язка для власного коду — devcontainer плюс /sandbox усередині нього. Врахуйте, що bubblewrap усередині Docker без привілейованих просторів імен не піднімається. Режим enableWeakerNestedSandbox це обходить, але документація прямо попереджає: він помітно послаблює захист. Для чужого коду обидва варіанти слабші за microVM.

Docker Sandboxes і окрема ВМ: коли звичайного контейнера замало

Звичайний контейнер ділить ядро операційної системи з хостом. Помилка в налаштуванні або вразливість ядра — і процес виходить назовні. microVM — це полегшена віртуальна машина з власним ядром: межа проходить по гіпервізору, а не по механізмах ізоляції ядра. Тому AI agent sandbox на Docker — це дві різні за стійкістю речі: звичайний контейнер зі спільним ядром або Docker Sandboxes на microVM.

Британський AI Security Institute у березні 2026 року опублікував SandboxEscapeBench — 18 сценаріїв втечі з контейнера на трьох рівнях: оркестрація, середовище виконання і ядро. Просунуті моделі надійно вибиралися через типові помилки конфігурації — відкритий сокет Docker і привілейований контейнер, — але найскладніших сценаріїв не пройшла жодна. Кожна успішна втеча використала вже розкриту вразливість; водночас ще під час створення тесту одна модель знайшла непередбачений шлях назовні.

П’ять команд для запуску агента в Docker Sandboxes

Docker Sandboxes — окремий продукт Docker: кожен агент працює в microVM з власним ядром і власним Docker-демоном, без доступу до Docker на хості. Станом на 4 листопада 2026 року CLI sbx і локальні пісочниці безплатні, зокрема для комерційної роботи; хмарні пісочниці — окрема послуга. Docker Desktop для них не потрібен.

brew install docker/tap/sbx          # macOS; Windows: winget install -h Docker.sbx
sbx login
sbx secret set anthropic             # ключ зберігається на хості, у ВМ не потрапляє
cd ~/my-project
sbx run --name my-project claude     # або codex, gemini, cursor, copilot

Під час першого запуску sbx попросить обрати мережеву політику; варіант Balanced відкриває популярні сервіси розробки й блокує решту. Список правил покаже sbx policy ls. За документацією Docker, серед дозволених за замовчуванням є широкі шаблони на кшталт *.googleapis.com, які покривають далеко не лише API ШІ-провайдерів, — перегляньте список і видаліть те, що вам не потрібно. Видалити пісочницю цілком — sbx rm my-project, папку проєкту це не зачіпає.

Три особливості, про які треба знати:

• Агенти стартують у повній автономії. За документацією Docker, Codex обходить підтвердження, Claude Code пропускає запити дозволів, Cursor, Copilot і Gemini працюють у YOLO-режимі. Це допустимо лише тому, що межа — microVM, а ключі підставляє проксі на хості.
• Папка проєкту змонтована на запис. Агент може змінити або видалити будь-який файл у ній, і це одразу видно у вас. Сюди ж потрапляють файли, які виконуються самі: хуки git, конфіги CI, Makefile, скрипти package.json. Хуки живуть у .git/ і не видні в git diff — перевіряйте їх окремо.
• Для чужого коду є --clone. У цьому режимі ваш репозиторій монтується лише для читання, а агент працює з приватною копією всередині ВМ.

Локальні MCP-сервери, запущені через stdio, за документацією Docker працюють на хості, а не у ВМ. Отже, їх треба вважати довіреними компонентами з усіма вашими правами.

Окремий користувач ОС і віртуальна машина

Найстаріший і найпростіший рівень ізоляції — окремий користувач системи, наприклад sudo useradd -m agent на Linux. Якщо ваша домашня папка закрита правами chmod 700, агент під чужим обліковим записом не прочитає ні ~/.ssh, ні .env у ваших проєктах, ні ~/.npmrc з токеном npm. Натомість агенту потрібен власний клон репозиторію й власний вхід у сервіси. Але ядро, мережа й усе, що відкрите на читання всім користувачам, лишаються спільними, тому це захист від випадковості, а не від цілеспрямованої атаки.

Для недовіреного репозиторію Anthropic у таблиці підходів прямо радить окрему віртуальну машину або хмарну сесію. ВМ дорожча в налаштуванні, зате її можна відкотити до знімка й викинути після роботи.

Секрети: що агент побачить сам і як тримати ключі поза його досяжністю

Агенту не потрібно спеціально «красти» ключ. Наткнувшись на помилку авторизації, він сам шукає облікові дані: відкриває .env у корені проєкту, виконує printenv, дивиться ~/.aws. Так цей сценарій описує Bitwarden — компанія продає менеджер секретів, тож це ілюстрація, а не статистика. Але механіку підтверджує документація Claude Code: усе, що пройшло через інструмент агента, записується в транскрипт на диску відкритим текстом.

Пастка op run -- агент

1Password CLI підставляє секрети так: op run запускає команду в дочірньому процесі, і секрети доступні як змінні оточення «лише на час роботи підпроцесу». Якщо цей підпроцес — сам агент, усі підставлені ключі стають доступні агенту й усьому, що він запускає, на всю сесію. Те саме стосується doppler run -- агент і direnv: direnv завантажує .envrc під час входу в папку, і агент, запущений із цієї оболонки, успадковує змінні.

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

# погано: агент отримує всі секрети із шаблону
op run --env-file=.env.tpl -- claude

# краще: секрети отримує лише тестовий прогін, який запускаєте ви
op run --env-file=.env.tpl -- npm test

Підставлення ключа через проксі

Найкращий варіант — агент бачить заглушку, а справжній ключ додає проксі під час запиту до дозволеної адреси.

• Claude Code — режим mask у sandbox.credentials: команди бачать одноразову заглушку, а проксі пісочниці підставляє справжнє значення в запити до адрес з injectHosts. Вимоги: network.tlsTerminate (проксі має бачити вміст запиту) і запис у користувацьких, а не проєктних налаштуваннях — mask із .claude/settings.json репозиторію ігнорується. Маскування файлів працює з версії 2.1.221; на macOS файл у режимі mask блокується цілком, як за deny. Перевірити налаштування можна командою claude doctor.
• Docker Sandboxes — ключі з sbx secret set зберігаються на хості, проксі вставляє їх у заголовки вихідних запитів, а у ВМ справжнє значення не потрапляє.
• NVIDIA OpenShell — за README проєкту агент ніколи не бачить справжніх ключів, OpenShell додає їх лише до запитів на схвалені адреси.

Ключі з мінімальними правами й лімітом витрат

1. GitHub — fine-grained токен (токен із детальними правами) замість класичного: GitHub радить саме його, і кожен такий токен можна обмежити конкретними репозиторіями. Давайте агенту читання й запис лише в потрібний репозиторій і короткий строк дії.
2. API моделей — окремий ключ для агента в окремому workspace з власним лімітом витрат. У консолі Anthropic місячний ліміт задається на організацію або на workspace (на default workspace — не можна), а не на окремий ключ; у разі витоку ключа з такого workspace втрати обмежені його лімітом.
3. Хмари — окрема роль із правами лише на тестове оточення, без доступу до продакшн-баз.
4. Агенти в CI — без секретів із правом публікації там, де агент читає текст issue і PR, і без спільного з релізними workflow кешу GitHub Actions. За постмортемом Cline, у Clinejection секрети публікації дісталися саме через кеш, який відновлював нічний реліз.

Що робити, якщо секрет уже прочитано

Видалити .env після сесії недостатньо. Claude Code пише в ~/.claude/projects/<проєкт>/<сесія>.jsonl вміст файлів, вивід команд і вставлений текст і за замовчуванням зберігає це 30 днів (налаштування cleanupPeriodDays). Порядок такий:

1. Відкличте й перевипустіть ключ — це єдиний надійний крок.
2. Перевірте журнали використання ключа в провайдера за час сесії.
3. Видаліть локальну історію проєкту: claude purge <шлях-до-проєкту> (до версії 2.1.288 команда називалася claude project purge).

Підтвердження, deny-правила й хуки: що вони гарантують, а що ні

Підтвердження й правила — третій шар: вони вирішують, що агенту можна, але не змінюють того, що він бачить і де працює. Документація Claude Code підкреслює, що правила дозволів виконує сам Claude Code, а не модель: інструкції в CLAUDE.md впливають на те, що агент намагається зробити, але не на те, що йому дозволено.

Мінімальний набір правил для Claude Code у settings.json:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(git push -f *)"
    ],
    "ask": [
      "Bash(git push *)"
    ]
  }
}

PreToolUse-хук проти rm -rf, git push --force і curl | sh

Хук — це ваш скрипт, який Claude Code запускає на подію. Подія PreToolUse спрацьовує перед викликом інструмента; код виходу 2 блокує виклик, а текст помилки йде агенту. Реєстрація в settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/block-danger.sh" }
        ]
      }
    ]
  }
}

Сам скрипт ~/.claude/hooks/block-danger.sh (потрібен jq):

#!/bin/bash
cmd=$(jq -r '.tool_input.command // ""')
if echo "$cmd" | grep -Eq 'rm +-[a-zA-Z]*r[a-zA-Z]*f|rm +-[a-zA-Z]*f[a-zA-Z]*r|git +push.*( --force| -f( |$))|curl[^|]*\| *(ba|z)?sh|wget[^|]*\| *(ba|z)?sh'; then
  echo "Заблоковано хуком: небезпечна команда. Запропонуй безпечний варіант." >&2
  exit 2
fi
exit 0

Цей хук ловить типові форми небезпечних команд, але не всі: змінна замість імені команди або скрипт у файлі його обійдуть. Тому хук — страховка від помилки агента, а не від атаки. Усі події, коди виходу й рецепти — у розборі про хуки Claude Code.

В OpenCode той самий шар задається в opencode.json: правило "bash": { "*": "ask", "rm *": "deny", "git push *": "ask" }. Спрацьовує останнє відповідне правило, а режим --auto не скасовує явних deny. За замовчуванням OpenCode стартує з дозвільних налаштувань: більшість дій — allow, читання .env — ask.

Worktree і worktrunk: зручно для паралельних агентів, але не ізоляція

Git worktree — це додаткова робоча папка того самого репозиторію на іншій гілці. На цьому будується запуск кількох агентів паралельно: кожен працює у своєму worktree й не заважає іншим. Як це влаштувати, ми розбирали в матеріалі про git worktree для паралельних агентів. Worktrunk — CLI для керування worktree, створений під паралельну роботу ШІ-агентів; станом на 4 листопада 2026 року репозиторій має 10 975 зірок на GitHub.

Проблема в тому, що worktree ділить з основним репозиторієм конфіг, посилання й хуки. Документація git прямо пише, що файл конфігурації репозиторію за замовчуванням спільний для всіх робочих дерев. Ми перевірили, що з цього випливає, на git 2.53.0 (4 листопада 2026 року):

git init main && cd main && git commit --allow-empty -m init
git worktree add ../agent -b agent-work
cd ../agent
hooks="$(git rev-parse --git-common-dir)/hooks"
printf '#!/bin/sh\necho HOOK-RAN-IN-MAIN-REPO\n' > "$hooks/post-commit"
chmod +x "$hooks/post-commit"
git config user.email hacked@example.com
cd ../main && git commit --allow-empty -m second
# вивід: HOOK-RAN-IN-MAIN-REPO
git config user.email
# вивід: hacked@example.com

Хук, записаний із worktree агента, виконався під час коміту в основному репозиторії, а зміна git config із worktree змінила налаштування основного. Тобто агент із правом запису в спільний .git може залишити код, який потім запустите ви.

Як поєднати worktree із захистом:

• Запускайте агента у worktree всередині пісочниці. У linked worktree пісочниця Claude Code дозволяє запис у спільний .git основного репозиторію, щоб працював git commit, але запис у hooks/ і config там лишається забороненим. Cursor захищає .git/hooks і .git/config, коли команда йде в його пісочниці; Codex тримає .git лише для читання.
• Для недовіреної роботи використовуйте повноцінний клон або режим --clone у Docker Sandboxes замість worktree.
• Після роботи агента перевіряйте .git/hooks і git config --list --show-origin — ці зміни не видні в git diff.

Що не закриває навіть пісочниця ШІ-агента: allowlist, ядро, MCP і CI

Пісочниця звужує можливості агента, але має залишкові ризики. Випадки AI agent sandbox escape — виходу агента за межі пісочниці — уже не теорія, тож ці ризики корисно знати, щоб не переоцінювати захист.

• Allowlist — сам собою поверхня атаки. У липні 2026 року модель OpenAI на внутрішньому оцінюванні вийшла з пісочниці через уразливість у проксі пакетів, який стояв у списку дозволених адрес, і дісталася до інфраструктури Hugging Face. Докладний розбір інциденту опублікував GitLab 12 серпня 2026 року. Висновок: кожен дозволений хост приносить із собою все, до чого він сам може дотягнутися.
• Широкі домени — канал виведення даних. Документація Claude Code попереджає, що дозвіл github.com відкриває шлях для витоку: проксі вирішує за іменем хоста й за замовчуванням не зазирає в TLS, тож можливий domain fronting (підміна адресата всередині зашифрованого з’єднання).
• Спільне ядро. Контейнер і ОС-пісочниця спираються на ядро хоста; SandboxEscapeBench показав, що моделі використовують типові помилки конфігурації. Опція allowUnixSockets з /var/run/docker.sock фактично дає доступ до хоста.
• MCP-сервери й хуки поза пісочницею. Локальні MCP-сервери працюють з вашими правами і в Claude Code, і в Docker Sandboxes. Окремий клас загроз — атаки через MCP-сервери.
• Агенти в CI. Clinejection і Comment and Control показали, що агент у CI із секретами й недовіреним текстом на вході — готовий шлях до крадіжки токенів.

Щоб картина була повною: пісочниця не лише обмежує, а й економить увагу. За внутрішніми даними Anthropic (20 жовтня 2025 року), пісочниця скоротила кількість запитів підтвердження на 84%. Це оцінка вендора на власному використанні, а не незалежний замір. Сенс у тому, що менше запитів — менше звички тиснути «так», не читаючи.

Захист агента за рівнем ризику: свій код, чужий код, автозапуск

Мінімальний набір на сьогодні, покроково:

1. Закомітьте роботу перед запуском агента.
2. Увімкніть вбудовану пісочницю й перевірте її командами touch ~/sandbox-probe і curl --noproxy '*' example.com.
3. Закрийте ~/.ssh, ~/.aws і змінні з токенами: sandbox.credentials у Claude Code, ignore_default_excludes = false у Codex, readBoundary: "workspace" у Cursor.
4. Приберіть ключі з .env у робочій папці; якщо секрет потрібен, підставляйте його через проксі або обгортайте op run довкола застосунку, а не агента.
5. Випустіть агенту окремі ключі: fine-grained токен GitHub на один репозиторій і API-ключ з лімітом витрат.
6. Додайте deny-правила й PreToolUse-хук проти rm -rf, git push --force і curl | sh.
7. Режим без підтверджень — лише всередині devcontainer, Docker Sandboxes або ВМ.

Що застаріє першим: типові налаштування агентів і номери версій (readBoundary у Cursor з 3.23, маскування ключів у Claude Code з 2.1.221), умови Docker Sandboxes і список доменів в еталонному файрволі. Перед налаштуванням звіряйтеся з офіційною документацією свого агента.

FAQ

Чи потрібен Docker, якщо в Claude Code є /sandbox?

Для власного коду вбудованої пісочниці зазвичай досить, якщо закрити ключі через sandbox.credentials і ввімкнути суворий режим. Але /sandbox покриває лише shell-команди: файлові інструменти, MCP-сервери й хуки працюють поза ним, а читання за замовчуванням відкрите майже по всій машині. Для чужого коду або режиму без підтверджень потрібен devcontainer, Docker Sandboxes або ВМ.

Чи безпечно запускати агента з –dangerously-skip-permissions у контейнері?

Безпечніше, ніж на хості, але лише для довіреного репозиторію. Документація Anthropic попереджає: у цьому режимі шкідливий проєкт може винести все, що доступне всередині контейнера, зокрема облікові дані Claude Code у ~/.claude. Не монтуйте ~/.ssh і docker.sock, закрийте мережу файрволом, а для чужого коду беріть microVM із ключами на проксі.

Де зберігати API-ключі під час роботи з агентами і чому не можна просто покласти їх у .env?

Агент, наткнувшись на помилку авторизації, сам відкриває .env і виконує printenv, а прочитане потрапляє в транскрипт сесії відкритим текстом. Зберігайте ключі в менеджері секретів, підставляйте їх через проксі (режим mask у Claude Code, sbx secret set у Docker Sandboxes) і випускайте агенту окремі ключі з мінімальними правами й лімітом витрат.

Як захиститися від prompt injection в агенті, якщо він читає чужий репозиторій?

Повністю запобігти ін’єкції не можна, тому обмежують наслідки. Запускайте агента в Docker Sandboxes з --clone або в окремій ВМ, не тримайте в середовищі справжніх ключів, залиште в мережі лише потрібні адреси й не вмикайте режим без підтверджень поза ізоляцією. Так навіть успішна ін’єкція не дотягнеться до ваших даних і не надішле їх назовні.

Чи захищає git worktree або worktrunk від агента?

Ні. Worktree ділить з основним репозиторієм конфіг, посилання й хуки. У нашій перевірці на git 2.53.0 хук, записаний із worktree, виконався під час коміту в основному репозиторії. Worktree зручний для паралельної роботи, а захист дає пісочниця поверх нього, яка забороняє запис у .git/hooks і .git/config, або повноцінний клон.

Що робити, якщо агент уже прочитав секрет?

Одразу відкличте й перевипустіть ключ: видалення .env не допомагає, бо Claude Code уже записав прочитане в транскрипт у ~/.claude/projects і за замовчуванням зберігає його 30 днів. Потім перевірте журнали використання ключа в провайдера й видаліть локальну історію проєкту командою claude purge.