Лучшие практики безопасности Claude Code для команд в 2026 году

Последнее обновление: June 28, 2026

ИИ-агент для кодирования, который может читать ваш репозиторий, выполнять команды оболочки и вызывать внешние сервисы, полезен именно потому, что у него большой доступ. Этот же доступ — это риск. Неправильно прочитанный промпт, небрежный allowlist или один недоверенный сервер MCP могут утечь токен или стереть ветку. Это руководство для разработчика или руководителя платформы, который хочет использовать Claude Code в ежедневной работе и в CI, не давая ему ключи к production.

Краткий ответ: как командам обеспечить безопасность Claude Code?

Запускайте агента с минимальными привилегиями и проверяйте, что он делает. На практике это означает пять вещей:

• Начинайте в режиме с ограниченными разрешениями и предоставляйте инструменты через узкий список разрешенных (allowlist), а не через общее «всегда разрешено».
• Держите секреты вне контекста модели: никаких вставленных ключей и правило deny для файлов .env и путей с секретами.
• Проверяйте каждый сервер MCP перед подключением, поскольку недоверенный сервер может читать данные и действовать от вашего имени.
• Обращайтесь с полученным веб-контентом как с недоверенным вводом, который может содержать инструкции по внедрению промптов (prompt-injection).
• В CI предоставляйте агенту токен с ограниченным сроком действия и только для чтения, и никогда не раскрывайте учетные данные продакшена.

Остальная часть статьи превращает каждый из этих пунктов в конкретные настройки, включая таблицу рисков, справочник разрешений и сценарий CI, который вы можете скопировать.

Как на самом деле работают режимы разрешений и списки разрешенных (allowlists)?

Claude Code запрашивает разрешение перед первым использованием инструмента. Вы решаете, будет ли это решение запомнено, ограничено областью действия или пропущено. Режим разрешений задает базовые параметры:

• default запрашивает разрешение при первом использовании каждого инструмента или команды.
• plan — только для чтения: агент может читать файлы и предлагать план, но не может редактировать или выполнять команды. Используйте его для проверки.
• acceptEdits автоматически принимает изменения в файлах, но по-прежнему запрашивает разрешение на командную оболочку (shell commands).
• bypassPermissions пропускает все запросы. Относитесь к нему как только к песочнице (sandbox-only).

Постоянные настройки находятся в .claude/settings.json в разделе permissions, с правилами allow, ask и deny. Правила ограничены инструментом и шаблоном, поэтому вы предоставляете только то, что требуется задаче:

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

Правило deny всегда имеет приоритет над allow, поэтому секретные пути выше остаются недоступными, даже если существует широкое правило Read. Anthropic документирует полный синтаксис правил и порядок их выполнения в документации Claude Code identity and access management docs.

Избегайте использования --dangerously-skip-permissions за пределами одноразового контейнера. Это устраняет единственную человеческую проверку, которая может поймать ошибочный rm или неожиданный сетевой вызов. Если вам нужна скорость без этого риска, предпочтите строгий список разрешенных действий (allowlist), чтобы рутинные команды выполнялись в фоновом режиме, а всё новое требовало вашего подтверждения.

Справочник рисков и их митигации

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

Изложение основано на OWASP Top 10 for LLM Applications, которое выделяет инъекцию промптов, небезопасную обработку вывода и чрезмерное агентское вмешательство как основные риски агентов.

Справочник разрешений и области действия

Эта таблица — шпаргалка, которую я передаю новым членам команды. В ней описаны настройки, которые изменяют радиус действия одного запуска.

Проверка серверов MCP перед подключением

Серверы MCP расширяют возможности агента новыми инструментами: клиентом базы данных, интеграцией тикетов и браузером. Каждый добавленный вами инструмент — это код, который может читать контекст и выполнять действия. Недоверенный сервер — самый быстрый способ превратить полезного агента в путь для эксфильтрации данных, поэтому критерии подключения такого сервера должны быть такими же, как и те, что вы применяете к любой зависимости с сетевым доступом.

Прежде чем добавлять сервер, ответьте на пять вопросов:

1. Кто его публикует и является ли источник общедоступным и поддерживаемым?
2. Какие области (scopes) он запрашивает: только чтение или запись и сетевой доступ?
3. Какие данные он может видеть после подключения: только это репозиторий или всю вашу машину?
4. Являются ли учетные данные ограниченными по области действия и с коротким сроком жизни, или это долгоживущий административный токен?
5. Можете ли вы зафиксировать версию, чтобы автоматическое обновление не могло незаметно расширить его доступ?

Подключайте серверы с минимально необходимыми областями действия, которые выполняют задачу, и держите серверы с возможностью записи или предназначенные для продакшена подальше от общих конфигураций или CI. Для механики настройки и более глубокого руководства см. нашу Claude Code MCP integration guide. В статье Claude Code productivity tips описывается, как сохранить небольшой след без замедления работы.

Как уберечь секреты от модели

Самый чистый секрет — тот, который модель никогда не увидит. Не вставляйте API ключи в промпт и не просите агента «прочитать ключ из конфига и использовать его». Пусть учетные данные хранятся в окружении (environment) и ссылаются на них по имени, чтобы значение оставалось вне транскрипта.

Три привычки покрывают большую часть рисков:

• Добавьте правило deny для .env, *.pem и любой директории secrets/, чтобы агент не смог прочитать их даже случайно.
• Используйте сканер секретов pre-commit (например, gitleaks или git secrets), чтобы утечка ключа приводила к сбою коммита, а не аудита.
• Немедленно ротируйте всё, что было раскрыто; затем проверьте логи и историю. Ротация — это единственное исправление, которое действительно закрывает окно уязвимости.

Если ключ уже попал в транскрипт или коммит, считайте его скомпрометированным и ротируйте его. Поиск в истории git с помощью git log -S поможет вам найти место, куда он попал.

Сценарий: включение Claude Code в CI без учетных данных продакшена

Команда хочет, чтобы Claude Code просматривал pull request в GitHub Actions. Цель — автоматические комментарии по обзору, без возможности развертывания, записи в ветку main или доступа к производственной базе данных.

Вот настройка, которая делает задачу полезной, но ограниченной:

• Запуск в режиме без головы (headless) с использованием claude -p в режиме plan, чтобы агент читал diff и писал комментарий, но никогда не редактировал файлы или не запускал команды сборки.
• Предоставить рабочему процессу только права contents: read и pull-requests: write. Никаких задач развертывания, никакого доступа к инфраструктуре.
• Использовать краткосрочный GITHUB_TOKEN задачи, а не личный токен, и никогда не помещать ключи базы данных или облака продакшена в окружение этой задачи.
• Добавить список запретов (deny) для путей секретов и исходящих запросов curl, чтобы попытка внедрения промпта внутри diff PR не могла ничего эксфильтровать.
• Закрепить версию действия (action) и Claude Code, а любой шаг развертывания защитить отдельной средой, одобренной человеком.

permissions:
  contents: read
  pull-requests: write
steps:
  - run: claude -p "Review the diff for security issues" --permission-mode plan
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Задача обзора видит код и публикует обратную связь. Она не может получить доступ к продакшену, потому что учетные данные продакшена никогда не находятся в области видимости (scope). Обзор безопасности Claude Code от Anthropic описывает эту позицию наименьших привилегий для автоматизированных и headless запусков.

Что никогда нельзя вставлять в агента для кодирования с помощью ИИ?

Некоторые входные данные совершенно не подходят для транскрипта, потому что всё, что находится в контекстном окне, может быть эхом возвращено, записано или использовано:

• Активные API-ключи, URL баз данных с паролями или корневые учетные данные облака.
• Персональные идентификационные данные (PII) клиентов или регулируемые данные, которые вы бы не указали в тикете поддержки.
• Приватные ключи подписи, сертификаты или файлы .pem.
• Полные строки подключения к продакшену, когда достаточно реплики для чтения или локального фикстуры.

Когда агенту нужен доступ, предоставьте ему путь к ограниченным учетным данным через окружение (environment), а не сам секрет. Результат тот же, но радиус поражения намного меньше.

Аудит, хуки и постоянная проверка

Принцип наименьших привилегий задает основу; обзор поддерживает этот уровень. Читайте план агента, прежде чем одобрять рискованный шаг, и читайте diff, прежде чем коммитить. Для более крупных изменений здесь применяется та же дисциплина, которая делает AI-assisted refactoring безопасным: маленькие шаги, поддающиеся обзору, лучше одного гигантского незамеченного запуска.

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

Краткий повторяющийся список проверок для команды:

• Проверять списки разрешенных и запрещенных действий в .claude/settings.json по расписанию, а не только при первоначальной настройке.
• Повторно проверять серверы MCP после крупных обновлений версии.
• Подтверждать, что задания CI все еще выполняются в режиме plan и не содержат производственных секретов.
• Ротировать токены периодически и после любого предполагаемого нарушения безопасности.
• Сохранять файл CLAUDE.md, где указаны не подлежащие обсуждению правила: запрещено force-push в main, прямой доступ к продакшн DB запрещен, секреты в промптах запрещены.

Для более широкого рабочего процесса вокруг всего этого Claude Code ultimate guide проходит через конфигурацию от начала до конца.

Главный вывод

Безопасность для AI coding agents — это то же мышление наименьших привилегий, которое вы уже применяете к учетным записям сервисов и записываете в виде правил разрешений. Начните с ограничений, расширяйте возможности узким списком разрешенных (allowlist), запрещайте доступ к секретным путям, проверяйте MCP servers как зависимости, относитесь к полученному контенту как к недостоверному и не допускайте учетные данные продакшена в любые задачи, к которым может получить доступ агент. Сделайте это, и Claude Code останется быстрыми руками, а не открытой дверью.