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