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