Sandbox легко спутать с ещё одним пунктом в промпте - вежливой просьбой к агенту "не выходить за рамки". Это принципиальная ошибка. Sandbox - не инструкция, которой модель может послушаться или нет, а системная граница уровня ОС: что процесс вправе записать и куда обратиться по сети, решает операционная система, а не текст задачи.
Наивный ход - надеяться на послушание. Написать в rules "не трогай ничего вне src, не ходи в сеть" и считать, что этого достаточно, потому что агент обычно слушается. Ожидание: хорошая инструкция эквивалентна ограничению. На спокойной задаче так и выглядит - до первого случая, когда модель истолкует рамку иначе.
Ломается это на природе инструкции: она вероятностна, а граница должна быть детерминирована. Промпт можно обойти ошибкой рассуждения, неудачной формулировкой или инъекцией из данных; sandbox обойти рассуждением нельзя - он вне процесса агента. Writable-пути выводятся из выданных Write-scope плюс каталог workspace, всё остальное - только на чтение; а пути, попавшие в Read deny, вообще скрыты от sandboxed-команд. Это не то, что агент обещает соблюдать, - это то, чего он физически не может нарушить.
Из системной природы следует важное поведение на отказе. Если sandbox не удаётся поднять - например, средств изоляции нет на платформе, - CLI должен fail closed: отказаться стартовать, а не тихо продолжить без изоляции. Это правильная сторона для ошибки: лучше не запуститься, чем запуститься беззащитным. На Windows OS-level sandbox не поддержан, и сессия с ним жёстко падает; на Linux нужны bubblewrap (bwrap) и socat. Граница честно говорит "не могу", вместо того чтобы притвориться, что она есть.
Сеть sandbox фильтрует по доменам, и у паттернов своя точность. example.com - только точное совпадение; *.example.com - поддомены без самого apex; **.example.com - и apex, и все поддомены. Deny имеет приоритет над allow. И сразу датированная оговорка: документация помечает сетевую фильтрацию как нестабильную, поэтому сроки и детали уточняют у Cognition и по актуальной странице, а не по этому тексту. Строить на ней жёсткую политику безопасности пока рано. До стабилизации сетевую фильтрацию разумнее считать удобством, а не рубежом обороны: то, что нельзя выпускать наружу совсем, надёжнее не пускать в контекст, чем полагаться на список доменов.
Как это связано с permission mode. Autonomous-режим доступен только с sandbox и работает как Accept Edits с добавленной способностью запускать любую shell-команду, но внутри OS-границы. То есть смелость shell здесь оплачена не доверием, а изоляцией: команда выполнится автоматически, но в клетке, где ей доступны лишь writable-пути и разрешённые домены.
И тут же намеренная граница, которую важно не проглядеть. В Autonomous shell и fetch идут автоматически внутри sandbox, а вот инструменты edit и write работают в процессе самого агента и всё равно поднимают запрос. Это не недоработка, а замысел: правка файла - прямое изменение вашего рабочего дерева, и его оставляют под подтверждением даже там, где shell уже отпущен. Автономия отдана исполнению в клетке, но не прямой записи мимо неё.
Почему нужны обе вещи - и permission rules, и sandbox, - а не одна. Они закрывают разные классы отказа. Permission rules - это политика намерения: что агенту вообще положено просить и делать. Sandbox - это физическая страховка на случай, когда намерение подвело: ошибка, обход, инъекция. Правила говорят "не проси лишнего", клетка добавляет "а если попросишь и проскочит - всё равно не сможешь". Один слой без другого оставляет либо непроверяемое обещание, либо запрет без страховки.
Проверять sandbox надо системно, а не по словам агента. Убедитесь, что запись вне writable-путей действительно не проходит, а не просто "агент так и не попробовал". Проверьте, что путь из Read deny невидим sandboxed-команде. Если платформа не тянет изоляцию, ждите честного отказа старта, а не молчаливой работы, - и если увидели работу без sandbox там, где он обязателен, это сигнал разбираться, а не продолжать.
Типичные провалы - о доверии к инструкции вместо границы. "Агент вышел за рамки, хотя я запретил в rules" - rules это просьба, а не sandbox. "Думал, sandbox защищает сеть" - фильтрация помечена нестабильной, полагаться на неё рано. "Autonomous, а запросил правку" - edit намеренно вне авто-исполнения. "Запустилось без изоляции" - значит, sandbox не был обязателен или обошли fail-closed. Признак один: безопасность агента объясняют тем, что ему сказали, а не тем, что ему системно доступно. Разделите просьбу и границу - и картина рисков станет честной.