Permission rules отвечают на вопрос, что агенту в принципе разрешено, но отвечают статически: правило смотрит на форму действия, а не на его содержание. Как только политика становится сложнее списка "это можно, это спрашивать", появляется потребность в проверке, которая читает конкретную команду, принимает решение по коду и оставляет след. Наивный ход - вписать эту логику словами в промпт или rule: "никогда не запускай деструктивные команды". Он кажется достаточным ровно до первого случая, когда важно, чтобы запрет сработал наверняка.

Ломается такой запрет на том, что инструкция в промпте - это просьба к модели, а не гарантия. Она зависит от того, как агент понял формулировку, и не оставляет доказуемого следа. Для настоящей политики нужен механизм, который выполняется детерминированно, не зависит от толкования и виден в логе. В Devin это hooks - проверяемая политика вокруг вызовов инструментов, живущая в файле .devin/hooks.v1.json, где объект hooks и есть всё содержимое файла, без обёртки.

Hook привязывается к событию жизненного цикла, и событий восемь. PreToolUse срабатывает до выполнения инструмента, PostToolUse - после; PermissionRequest - в момент, когда нужно решение о праве; UserPromptSubmit - когда пользователь отправил сообщение; Stop - когда агент собирается остановиться; PostCompaction - после успешного сжатия контекста; SessionStart и SessionEnd - на границах сессии. Разные события отвечают на разные вопросы: PreToolUse - "пропустить ли это действие", SessionStart - "что подготовить заранее", Stop - "можно ли считать работу законченной".

Внутри события правило устроено единообразно: поле matcher - это регулярное выражение, которое сверяется с именем инструмента (tool_name), а массив hooks перечисляет, что запустить при совпадении. Каждый элемент имеет тип - command для внешнего скрипта или prompt для инструкции модели - и необязательный timeout. Пример этой главы вешает на exec скрипт validate-agent-command.sh с лимитом в десять секунд: он получит управление до того, как команда выполнится.

Контракт command-hook стоит понимать точно, потому что именно он делает политику проверяемой. Скрипт получает данные события как JSON на stdin и возвращает решение через stdout и код выхода. Код 0 - успех, действие идёт дальше; код 2 - блокировка; любой другой код трактуется как ошибка, которая логируется, но не останавливает действие. В stdout можно вернуть поле decision со значением approve или block и пояснением reason, а через hookSpecificOutput - дописать контекст или переписать вход инструмента. Это и есть три возможности хука: разрешить, изменить или заблокировать, оставив след.