Как запретить AI-агенту опасные команды в 2026 году

Claude Code и Cursor умеют не только писать код, но и удалять файлы, выполнять bash-команды и коммитить в git без остановки. Claude code permissions и cursor permissions решают ровно одну задачу: агент делает то, что вы разрешили, и не трогает то, что вы запретили. Ниже, пошагово: как настроить allow и deny list, зачем нужны pre-tool-use хуки и почему CLAUDE.md сам по себе ничего не гарантирует.

Разберем allow/deny list в settings.json, pre-tool-use хуки на exit code 2 и разницу между Claude Code и Cursor в контроле опасных команд. В конце: готовая карта выбора и таблица команд для deny list.

Зачем вообще ограничивать AI-агента в кодинге?

Агент видит только файлы и команды, до которых ему хватает прав. Без ограничений один неверно понятый промпт может стереть рабочую директорию целиком.

Claude Code и Cursor работают по циклу think, act, observe: агент рассуждает, выполняет действие через инструмент, потом смотрит на результат. Проблема в фазе act: там агент может редактировать файлы, удалять их и запускать bash-команды. По разбору из обучающего видео про режимы безопасности Claude Code, именно на этом этапе разработчик теряет контроль, если заранее не выставил границы.

Ключевой факт из практики: 93% permission-запросов в Claude Code разработчики подтверждают не глядя. Это превращает систему подтверждений в фоновый шум, а не в защиту. Отсюда и вывод: полагаться на то, что вы прочитаете каждый запрос, не стоит. Механизм должен работать сам, без вас в моменте.

Ниже разберем два уровня защиты: permissions в settings.json (что агенту вообще можно) и хуки (что физически блокируется, даже если агент очень хочет).

Как работают claude code permissions в settings.json?

Claude Code проверяет каждое действие по трем спискам: allow, ask и deny. При конфликте всегда побеждает deny, даже если команда есть в allow.

Правило простое и его стоит запомнить дословно: если команда одновременно попадает и в allow, и в deny, деню отдается приоритет. Порядок оценки: deny → ask → allow → режим по умолчанию, если правило вообще не найдено.

Файл лежит в трех местах. ~/.claude/settings.json — общий для всех ваших проектов. .claude/settings.json — настройки проекта, их стоит коммитить в репозиторий, чтобы вся команда работала по одним правилам. .claude/settings.local.json— личные исключения, добавляете в .gitignore.

Базовый безопасный конфиг выглядит так:

{
  "permissions": {
    "allow": ["Bash(git status)", "Bash(git diff:*)", "Bash(npm run test:*)"],
    "ask": ["Edit", "Write", "Bash(git commit:*)", "Bash(git push:*)"],
    "deny": ["Bash(rm -rf:*)", "Bash(curl:*)", "Read(./.env*)"]
  }
}

Читать и проверять код разрешаем без вопросов, изменения кода и коммиты подтверждаем вручную, а необратимые команды блокируем полностью на уровне deny.

Какие режимы permissions есть у Claude Code кроме allow/deny?

Помимо списков, у Claude Code есть режимы работы всей сессии. Их четыре штуки, и разница между ними прямо влияет на риск.

Bypass физически не нужен ни на одном рабочем репозитории. Это тот самый режим, который дает агенту ключи от всего сразу, и разработчики в комментариях к обучающим видео прямо называют его вариантом, который стоит избегать.

Как настроить allow и deny list шаг за шагом?

Настройка занимает пять минут: команда /permissions показывает текущие правила, а settings.json редактируется как обычный JSON-файл.

Cоздайте .claude в корне проекта, если его еще нет, и добавьте туда settings.json с пустыми массивами permissions. Дальше заполняете по шагам.

Шаг 1. Разрешите безопасные команды. Чтение файлов, git status, git diff, запуск тестов и линтера — это обратимые операции, их можно смело класть в allow.

Шаг 2. Переведите операции с последствиями в ask. Edit, Write, git commit, git push, npm install — сюда же деплой. Агент попросит подтверждение, но хотя бы не сделает это молча.

Шаг 3. Заблокируйте необратимое через deny. rm -rf, чтение .env, прямой curl без разбора и любые команды, которые трогают продакшн-базу.

Шаг 4. Проверьте через /permissions внутри сессии. Команда покажет, какое правило откуда взялось: из проектного файла, пользовательского или локального.

Проверять стоит именно так, потому что правила из разных файлов не заменяют друг друга, а объединяются. Более строгое правило из проектного settings.json нельзя случайно ослабить локальным файлом.

Что такое pre-tool-use хуки и зачем они нужны?

PreToolUse хук запускается до выполнения инструмента и может физически остановить его через exit code 2. В отличие от промпта, хук сработает всегда, а не когда агент "вспомнит".

Разница между запретом в промпте и хуком принципиальная. Промпт вида "никогда не удаляй файлы" агент может проигнорировать, если контекст переполнен или формулировка задачи звучит убедительнее запрета. Хук такого шанса не оставляет: он детерминированный скрипт, который проверяет команду перед запуском.

Логика на exit code простая. Код 0 значит: продолжай, все хорошо. Код 2 блокирует конкретно PreToolUse и передает агенту текст ошибки из stderr, чтобы тот мог скорректироваться. Любой другой код — просто некритичная ошибка самого хука, выполнение продолжается.

Пример хука, который блокирует rm -rf в bash-командах:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -q 'rm -rf'; then echo 'Blocked: rm -rf запрещен' >&2; exit 2; fi"
          }
        ]
      }
    ]
  }
}

Похожим образом блокируют запись в .env: хук на Write/Edit проверяет путь файла через tool_input.file_path и выходит с кодом 2, если в пути встречается .env. Такой конфиг стоит держать в репозитории вместе с проектом, а пути к скриптам указывать через переменную $CLAUDE_PROJECT_DIR, чтобы они работали независимо от того, откуда запущена сессия.

Почему CLAUDE.md не защищает от опасных команд?

CLAUDE.md — это файл с контекстом и инструкциями для агента, а не система защиты. Claude читает его как часть промпта, и в этом главная проблема: правило из CLAUDE.md может быть проигнорировано или размыто, если модель посчитает задачу более приоритетной.

Максим: «Портал VibeCoderz мы с командой собрали за неделю, тремя скриптами, голосом, прямо в Claude Code. Там уже 6 200 материалов. Одна забытая команда rm -rf в такой момент и переделывать пришлось бы весь каталог заново.»

Правильное разделение обязанностей такое: в CLAUDE.md пишете контекст и стиль работы над проектом (какие файлы важны, какая архитектура, как называть переменные). В settings.json и хуках прописываете жесткие границы: что разрешено без вопросов, что требует подтверждения, что заблокировано физически. Дублировать запрет в CLAUDE.md можно, но полагаться только на него нельзя.

Cursor или Claude Code: чей denylist надежнее?

У Cursor denylist в auto-run режиме исторически обходился через обфускацию команд и переменные окружения. Claude Code с deny-first порядком правил и sandbox для bash-процессов держит границу строже, но тоже не абсолютную.

У Cursor есть похожий механизм: в режиме Auto Run командам разрешено выполняться без подтверждения, а denylist должен останавливать опасные. Разработчики из Backslash Security показали, что до исправления в релизе 1.3 обфусцированные команды проходили denylist незамеченными. Похожая история описана в CVE-2026-22708: агент Cursor в режиме Allowlist пропускал часть shell-встроенных команд, если атакующий через prompt injection менял переменные окружения.

В марте 2026 Cursor обновил модель до трехступенчатого Cursor Auto-review: allowlist пропускает доверенные вызовы мгновенно, sandbox изолирует что может, а классификатор-субагент решает по всем остальным. Настраивается через .cursor/permissions.json с полями allow_instructions и block_instructions. Сам разработчик прямо называет это best-effort механизмом, а не жесткой границей безопасности.

Для задач, где важна гарантия, а не удобство, связка settings.json плюс хуки в Claude Code выглядит надежнее. Cursor удобнее для скорости работы, но denylist там стоит держать вместе с allowlist, а не полагаться на него в одиночку.

Какие команды точно нужно заносить в deny list?

Список ниже стоит взять за основу и адаптировать под свой проект. Это не полный перечень, а минимальный набор, с которого стоит начинать в любом репозитории.

Гайд из аудита разрешений Claude Code рекомендует держать в deny именно необратимые операции, а обратимые вроде git commit переводить в ask. Логика простая: то, что можно откатить через git или checkpoint, спокойно уходит в подтверждение. То, что откатить нельзя, блокируется физически.

Какие ошибки чаще всего допускают при настройке permissions?

Три частые ошибки: включают bypass "на минутку", надеются на промпт вместо хука и не проверяют правила через /permissions после каждого изменения проекта.

Первая ошибка: bypass-режим ради скорости на "простой задаче". Простых задач для агента с полным доступом к shell не бывает: одна неверно понятая формулировка команды и откатывать нечего, если git не закоммичен.

Вторая: надежда на негативные формулировки в промпте вроде "не удаляй базу", "не делай ошибок". По разбору гайдлайнов для продакшн-агентов такие промпты работают нестабильно, особенно если задача звучит убедительно противоречиво. Ограничение прав доступа надежнее любой словесной просьбы.

Третья: настроили permissions один раз и забыли. Проект растет, появляются новые скрипты и новые пути к секретам, а deny list остается прежним. Проверять /permissions стоит после каждого крупного изменения структуры проекта, не только на старте.

Итог: какая связка нужна для безопасной работы с AI-агентом

Для большинства проектов на 2026 год оптимальна связка: allow на чтение и тесты, ask на изменения кода и git, deny на необратимые операции плюс PreToolUse хук как физический барьер поверх всего этого.

Если работаете с Claude Code или Cursor на постоянной основе, разбор permissions и хуков стоит внести в чеклист запуска нового проекта, а не оставлять на потом. Полный каталог IDE и агентов для вайбкодинга собран в каталоге AI-инструментов.

FAQ

Что произойдет, если команда есть и в allow, и в deny одновременно? Сработает deny. Правило приоритета в Claude Code строгое: запрет всегда перекрывает разрешение, независимо от того, в каком файле оно объявлено.

Можно ли просто написать в CLAUDE.md "никогда не удаляй файлы"? Можно, но это не гарантия. CLAUDE.md читается как часть промпта, а не как enforced-правило. Для гарантии нужен deny в settings.json или PreToolUse хук с exit code 2.

Чем отличается Accept edits от Bypass в Claude Code? Accept edits принимает правки файлов автоматически, но команды в bash все еще требуют подтверждения. Bypass отключает все проверки полностью, включая деструктивные команды.

Работает ли denylist в Cursor так же надежно, как deny в Claude Code? Не совсем. У Cursor были зафиксированы обходы denylist через обфускацию команд и через манипуляции переменными окружения (CVE-2026-22708). Рекомендуется комбинировать allowlist с sandbox-режимом, а не полагаться на denylist в одиночку.

Нужно ли настраивать permissions, если я работаю один и без продакшн-базы? Да. Даже локальный проект может содержать .env с ключами от API или платежных систем. Один неверно понятый промпт способен удалить недели работы, если нет git-коммитов и deny list.

Как проверить, какие правила сейчас активны в Claude Code? Команда /permissions внутри сессии показывает весь список: что разрешено, что запрещено, в каком режиме сейчас работает агент и из какого файла взялось каждое правило.

Хуки замедляют работу агента? Минимально. PreToolUse хук — это короткий скрипт, который выполняется за миллисекунды перед действием. Задержка ощутима только если хук делает что-то тяжелое, вроде сетевого запроса без таймаута.

Глоссарий

Settings.json — файл конфигурации Claude Code, где хранятся правила allow, ask и deny.

Deny list — список команд, которые агенту запрещено выполнять ни при каких условиях.

PreToolUse хук — скрипт, который запускается до выполнения инструмента и может заблокировать его через exit code 2.

CLAUDE.md — файл с контекстом проекта для агента, читается как часть промпта, не является механизмом защиты.

Bypass-режим — режим, отключающий все подтверждения; допустим только в изолированном sandbox.

Agentic loop — цикл think, act, observe, по которому работает AI-агент внутри Claude Code и Cursor.

Если настраиваете permissions под конкретный проект и не уверены, какую связку выбрать, можно обсудить это на консультации с Максимом.

Обновлено: июль 2026