КиберЩит
Claude Code в компании: разрешения и хуки для защиты репозиториев
📋 Кратко
Claude Code ускоряет разработку, но текстовых правил в CLAUDE.md недостаточно для защиты репозитория. Агент может ошибиться, выполнить опасную команду, раскрыть секрет или изменить конфигурацию. Разрешения, хуки, изоляция, защита веток и обязательная проверка изменений создают несколько независимых барьеров. В статье показано, как собрать такую модель в компании.
🔍 Почему агенту нельзя доверять правила из текста
Claude Code читает CLAUDE.md в начале каждой сессии. После сжатия диалога он перечитывает этот файл. Но текстовое правило не становится техническим запретом.
Известен случай из issue #46779. Агент несколько раз удалял данные сверх запроса. Запрет был прямо записан в CLAUDE.md. Значит, файл с инструкциями помогает задать намерение, но не блокирует каждое действие.
Причина не всегда связана с непониманием текста. В длинном диалоге модель может помнить правило, но перестать применять его. В бенчмарке StateTrack-Bench 88,6% сбоев в длинных диалогах связали с таким дрейфом поведения.
CLAUDE.md остаётся полезным уровнем политики. Он объясняет структуру проекта, запреты и порядок работы. Но критичные ограничения нужно дублировать разрешениями, хуками и проверками в системе контроля версий.
Практический совет: составьте список действий, где ошибка затрагивает деньги, данные или доступ. Для каждого пункта назначьте отдельный технический барьер.
⚠️ Какие угрозы создаёт работа Claude Code
ИИ-агент работает с файлами, командами и настройками проекта. Ошибка в любой зоне меняет состояние репозитория. Риск появляется даже без злого умысла.
Агент может изменить файл сверх задачи. Он может запустить удаление данных. Он может прочитать секрет из .env и вывести его в транскрипт. Он также способен использовать недоверенный код или изменить конфигурацию проекта.
В issue #44868 описан сценарий с чтением содержимого .env через grep -n. Запрет был указан в CLAUDE.md. Этот пример показывает слабость текстовой политики при работе с секретами.
Отдельная проблема связана с доступом к внешним сервисам. Ошибочная команда может отправить данные наружу. Опасность растёт, если агент работает в фоне или получает длительную сессию.
Разделяйте действия по цене ошибки. Чтение обычного файла и удаление базы не должны иметь одинаковый режим подтверждения. Чем выше ущерб, тем строже должен быть барьер.
Практический совет: выпишите команды и файлы, которые нельзя менять автоматически. Начните с секретов, баз данных, настроек сборки и защищённых веток.
📖 CLAUDE.md как политика проекта, а не замок
CLAUDE.md задаёт агенту контекст проекта. В нём удобно описывать структуру каталогов, правила тестирования и формат изменений. Файл также фиксирует ошибки, которые уже повторялись.
Практика из опубликованных материалов предлагает добавлять правило после второго одинакового сбоя. Первый случай может быть разовым. Повтор показывает, что проекту нужна явная инструкция.
Файл нельзя превращать в длинный архив всех проблем. Рекомендация Anthropic — держать его короче 200 строк. У файла должен быть владелец. Его изменения нужно проверять так же, как изменения кода.
Устаревшее правило способно вредить сильнее, чем его отсутствие. Оно перегружает контекст и создаёт ложное чувство контроля. Поэтому CLAUDE.md нужно регулярно пересматривать.
В нём стоит описывать не только запреты. Добавляйте безопасный порядок действий. Например, сначала агент запускает тесты, затем показывает изменение, и только потом готовит фиксацию.
Но критичный запрет нельзя оставлять только в этом файле. Текст может не сработать в длинной сессии. Техническая проверка должна остановить операцию независимо от формулировки.
Практический совет: назначьте владельца CLAUDE.md и внесите в него только проверяемые правила. После этого вынесите опасные ограничения в разрешения и хуки.
🔐 Разрешения и принцип наименьших привилегий
Разрешения ограничивают действия агента. В компании их нужно разделять по типу операции. Доступ на чтение не должен автоматически означать доступ на изменение.
Отдельно контролируйте чтение файлов, запись файлов, запуск команд, сетевые обращения и работу с внешними сервисами. Такое разделение помогает понять, где именно возникает риск.
Например, агент может читать исходный код, но не получать доступ к .env. Он может запускать локальные тесты, но не выполнять удаление данных. Он может подготовить изменение, но не отправлять его в защищённую ветку.
Проблема возникает, когда команда считает permissions.deny единственным барьером. В описании issue #24846 указано, что правило для шаблонов .env* не предотвращало чтение .env.local. Поэтому запрет нужно проверять на реальном сценарии.
Автоматическое подтверждение опасных операций нужно запретить. Нельзя превращать автономность в постоянное разрешение на любые действия. Особенно рискован такой режим для репозиториев с рабочими базами и клиентскими данными.
Разрешения должны различаться для локальной разработки, тестового конвейера и производственной инфраструктуры. Одинаковая политика для всех сред либо мешает работе, либо оставляет опасный пробел.
Практический совет: создайте матрицу действий. Для каждой операции укажите режим «разрешено», «нужно подтверждение» или «запрещено».
🛠️ Хуки как автоматические точки проверки
Хук запускает проверку в определённый момент работы агента. Он может остановить опасную команду до выполнения. Также он может проверить результат после изменения файла.
В практических настройках хуки применяют для блокировки git push -f, DROP TABLE, rm -rf и установки пакетов. Такие проверки переносят важное правило из текста в исполняемый контроль.
До запуска команды хук может проверить её содержание. После изменения он может проверить формат кода и состояние файлов. Перед фиксацией можно искать секреты и запрещённые изменения.
Хук полезен только при правильной настройке. Ошибка в проверке создаёт пропуск. Слишком широкое правило мешает работе. Слишком узкое правило пропускает опасную вариацию команды.
Хуки не являются полноценной границей безопасности. Пользователь с достаточными правами может изменить их конфигурацию. Сам хук тоже может содержать ошибку.
Конфигурацию хуков нужно хранить рядом с кодом, если она относится к конкретному компоненту. В описании внедрения отмечено, что .claude может содержать хуки, правила и settings.json. Без такой конфигурации часть защиты теряется.
Общие правила можно распространять через плагины. Это упрощает обновление и версионирование общей политики. Но компонентоспецифичные правила должны учитывать особенности конкретного репозитория.
Практический совет: начните с трёх блокировок. Запретите принудительную отправку, опасное удаление и раскрытие секретов перед фиксацией.
🚫 Почему автономный режим повышает цену ошибки
Claude Code получает режимы, которые позволяют работать дольше без постоянного подтверждения. В описании автономной работы упоминаются auto-mode, /loop, /schedule и фоновые сессии через claude --bg.
Раньше агент останавливался перед каждой записью и ждал подтверждения. Это замедляло работу, но человек видел больше опасных действий. Автономный режим убирает часть таких остановок.
В auto-mode отдельный классификатор решает, разрешать ли действие. Такая схема ускоряет работу, но не заменяет политику компании. Ошибка классификатора может запустить цепочку изменений.
Сценарий с PocketOS показывает цену слабого контроля. В апреле 2026 года разработчик оставил Cursor с Claude Opus 4.6 в режиме --dangerously-skip-permissions на ночь. За девять секунд одним вызовом Railway API была удалена рабочая база вместе с резервными копиями на уровне томов.
Это не доказывает, что любой запуск Claude Code приводит к такому результату. Но пример показывает риск длительной сессии без подтверждений и изоляции. Фоновая работа должна иметь более узкие права, чем обычная задача разработчика.
Автономную сессию нужно запускать только в изолированной среде. Доступ к сети ограничивают. Токены выдают отдельно. Все действия записывают и проверяют после завершения.
Практический совет: перед запуском /loop, /schedule или фоновой сессии отключите доступ к производственным данным и проверьте список разрешённых команд.
🏢 Как хранить конфигурацию в корпоративном проекте
Для Claude Code репозиторий компонента является естественным местом конфигурации. В нём могут находиться claude.md, папка .claude, навыки, агенты, хуки, правила и settings.json.
Такая схема даёт версионирование. Команда видит изменения политики рядом с изменениями кода. Рецензент может проверить, не ослабил ли кто-то защиту.
Есть и обратная сторона. Если конфигурация не хранится в репозитории, Claude Code не получает компонентоспецифичные правила. Тогда агенту приходится искать сведения во внешнем источнике.
Общие правила можно распространять через плагины. Это подходит для базовых ограничений компании. Но один общий набор не учитывает особенности всех компонентов.
Для информации о компонентах можно использовать внутренний портал. В описании корпоративного внедрения приведены варианты MCP для Backstage или Confluence. Общий навык объясняет агенту, где искать сведения и как их получать.
Конфигурация не должна содержать реальные секреты. Она может описывать переменные и правила доступа. Значения токенов должны находиться в отдельном защищённом хранилище.
Права на изменение .claude и settings.json нужно ограничить. Иначе пользователь сможет ослабить защиту перед опасной операцией. Это особенно важно для репозиториев с производственными сценариями.
Практический совет: храните правила компонента в репозитории, общие правила распространяйте отдельно, а доступ к конфигурации проверяйте через обязательное рецензирование.
🧪 Безопасный сценарий работы с изменением
Сначала разработчик выбирает тестовую ветку. Агент получает доступ только к нужному компоненту. Секреты и производственные адреса не попадают в окружение сессии.
Задача описывает границы изменения. Агент читает код, но не меняет файлы вне списка. Команды запускаются по разрешённому перечню. Опасные действия требуют отдельного подтверждения.
Перед изменением хук проверяет путь файла. Он блокирует доступ к .env и другим чувствительным данным. Другой хук отклоняет опасную команду или установку неизвестного пакета.
После изменения запускаются тесты и проверка формата. Затем проверка ищет секреты в новых строках. Если найдено нарушение, агент не готовит фиксацию.
Git защищает основную ветку. Отправка с принудительной перезаписью запрещена. Слияние требует рецензирования другого разработчика.
В конвейере сборки повторяются важные проверки. Это необходимо, потому что локальный хук можно изменить. Конвейер должен доверять только своей версии правил.
После завершения сохраняется журнал. В нём нужны команда, время, решение, подтверждение или отказ. Такой след помогает разобрать спорное изменение.
Практический совет: проведите одну задачу по этой цепочке вручную. Проверьте, где агент останавливается, а где защиту нужно усилить.
💣 Сценарий отказа от опасной операции
Представим задачу «почистить старые данные». Формулировка слишком широкая. Агент не должен сам выбирать базу, таблицы и глубину удаления.
Сначала разрешение блокирует доступ к производственной базе. Затем хук проверяет команду и находит DROP TABLE. Операция останавливается до запуска.
Агент сообщает причину отказа. Он просит уточнить среду и список объектов. Для тестовой базы команда может получить отдельное подтверждение.
Если задача требует очистки, разработчик формирует ограниченный сценарий. В нём указаны конкретная база, таблица и условие. Агент работает только в изолированной среде.
Другой пример связан с секретом. Агент пытается прочитать .env.local, но правило чтения запрещает путь. Хук дополнительно проверяет вывод команд, чтобы секрет не попал в транскрипт.
Если запрет не сработал, срабатывает следующий уровень. Сетевой доступ отсутствует. Токен имеет минимальные права. Ротация токена ограничивает последствия возможной утечки.
Отказ не должен быть молчаливым. Система фиксирует команду, правило и причину блокировки. Такой журнал помогает исправить ошибку политики, а не просто повторить попытку.
Практический совет: протестируйте отказ на безвредной копии репозитория. Проверьте удаление, чтение .env, принудительную отправку и установку пакета.
📊 Разные уровни защиты для разных сред
Локальный проект без клиентов и денег имеет один уровень риска. Репозиторий сервиса с платежами и персональными данными требует другого режима.
Для локальной разработки допустим широкий доступ к тестовым файлам. Но даже здесь секреты не должны лежать рядом с исходным кодом. Опасные команды всё равно требуют проверки.
Среда разработчика должна отделяться от производственной инфраструктуры. Агент не получает рабочие токены по умолчанию. Доступ к удалённым сервисам проходит через отдельные учётные записи.
В конвейере сборки права ещё уже. Агент не должен самостоятельно менять настройки публикации. Любое изменение проходит проверку и рецензирование.
Производственная инфраструктура требует максимального разделения. Агент готовит код, но не управляет рабочей базой напрямую. Операции выполняют отдельные процессы с собственным журналом.
Для опасных сред важна сетевая изоляция. В описании безопасной настройки отдельно выделяется /sandbox с сетевой изоляцией. Такая среда уменьшает риск отправки данных наружу.
У каждой среды должны быть свои токены и сроки их действия. После подозрительной операции токен нужно заменить. Ротация не исправляет ошибку, но сокращает время возможного доступа.
Практический совет: разделите репозитории на зоны риска. Для каждой зоны задайте свои права, сетевые ограничения и требования к рецензированию.
✅ Чек-лист внедрения Claude Code в компании
Начните с инвентаризации. Укажите репозитории, среды, секреты, внешние сервисы и команды с высокой ценой ошибки. Без такой карты разрешения будут случайными.
- Назначьте владельца CLAUDE.md и поддерживайте файл короче 200 строк.
- Опишите в CLAUDE.md правила проекта и безопасный порядок работы.
- Запретите чтение .env и других файлов с секретами.
- Разделите права на чтение, запись, запуск команд и сетевой доступ.
- Отключите автоматическое подтверждение опасных операций.
- Добавьте хуки для опасного удаления, DROP TABLE и git push -f.
- Проверяйте секреты и формат кода перед фиксацией.
- Храните компонентоспецифичную конфигурацию рядом с кодом.
- Распространяйте общие правила через версионируемый механизм.
- Защитите основную ветку и включите обязательное рецензирование.
- Запускайте автономные сессии только в изолированной среде.
- Используйте отдельные учётные записи и токены с минимальными правами.
- Контролируйте сеть и запрещайте доступ к производственным данным.
- Журналируйте действия, подтверждения, отказы и изменения правил.
- Проверяйте защиту в локальном запуске и в конвейере.
Чек-лист не заменяет тестирование. Защитный механизм может работать в одном сценарии и пропускать другой. Особенно внимательно проверяйте варианты записи через команды, скрипты и внешние интерфейсы.
После внедрения пересматривайте правила по итогам инцидентов и повторяющихся ошибок. Первую проблему фиксируйте в журнале. Вторую проблему превращайте в правило или проверку.
Практический совет: внедряйте защиту по этапам. Сначала закройте секреты и опасные команды, затем добавьте изоляцию, рецензирование и аудит.
🔒 Ограничения модели защиты
Разрешения и хуки не делают Claude Code полностью безопасным. Разрешение может быть слишком широким. Хук может не распознать новую форму опасной команды.
Пользователь с достаточными правами способен изменить settings.json или сам хук. Поэтому локальная конфигурация не должна быть единственным источником доверия.
CLAUDE.md может содержать правильное правило, но агент всё равно нарушит его. Длинная сессия усиливает риск дрейфа поведения. Перечитывание файла после сжатия диалога не гарантирует соблюдение запрета.
Изоляция тоже имеет границы. Она снижает последствия ошибки, но не отменяет необходимости проверять изменения. Если агент работает с копией, плохой код всё равно может попасть в репозиторий.
Защита веток не предотвращает ошибку в рабочей ветке. Рецензирование не заменяет автоматические тесты. Журналирование помогает расследовать событие, но не отменяет ущерб.
Поэтому модель должна быть многослойной. Текст задаёт контекст. Разрешения ограничивают действия. Хуки проверяют операции. Конвейер, защита веток и изоляция снижают остаточный риск.
Практический совет: раз в квартал проводите проверку всех правил, хуков и разрешений. Удаляйте устаревшие запреты и добавляйте контроль после каждого повторного сбоя.
📚 Читайте также
- Claude нашёл 16 проблем в SAML: расследуем сбои федерации
- Фаззинг ИИ-агентов: почему автоматический поиск находит уязвимости
- Киберзащита ЦОД промышленного предприятия против кинетических атак
- Фальшивое приложение: проверки перед публикацией и выпуска сборки
- Как выявлять автоматизированные атаки по сигналам в браузере и сети
📖 Термины
Devsecops · Git · IAM (Identity and Access Management) · Безопасность ИИ · Искусственный интеллект