Руководство по безопасности Claude Code: разрешения, MCP, песочница

Традиционные чат-боты работают за API, так что максимум, что они могут сделать, — это «галлюцинировать». Но ИИ-агент для кодирования попадает в ваш репозиторий, ваш терминал и (часто) к вашим облачным учетным данным, то есть намного ближе к привилегированным средам разработчика, чем все, что мы раньше называли чат-ботом.

Вопрос в том, как безопасно использовать Claude Code, не замедляя работу. Правильно настроенные разрешения, контроль MCP и песочницы помогут вам добиться этого.

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

Если вы только знакомитесь с Claude и Claude Code, запишитесь на наш бесплатный курс Claude Code 101 — освоите базу за один день.

Как устроена модель безопасности Claude Code

Прежде чем настраивать правила, важно понять, чем именно управляет Claude Code.

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

Система разрешений

Система разрешений — это статический слой.

Вы задаёте, что может делать Claude, в settings.json с помощью трёх списков: allow, ask и deny. Правила применяются в порядке: deny, затем ask, затем allow, и срабатывает первое совпадение. Правило deny блокирует вызов, даже если более широкое правило allow тоже бы его позволило.

Если ни одно правило не подошло, Claude использует defaultMode текущей сессии (о режимах — в следующем разделе).

Контроль доступа к инструментам

Разрешения привязаны к инструментам, а не к агенту целиком.

В Claude Code есть собственные встроенные инструменты: например, Bash для команд оболочки, Read, Edit и Write для работы с файлами, WebFetch для HTTPS-запросов, WebSearch для поиска и другие. В каждом правиле указывается инструмент и (опционально) спецификатор в скобках, например Bash(git commit:*) или Read(./.env).

Именно это обеспечивает принцип наименьших привилегий. Вы можете разрешить Bash(npm run:*) для тестов, не давая Claude полного доступа к оболочке.

Разрешения MCP

Серверы MCP расширяют Claude Code инструментами, с которыми он изначально не был рассчитан работать.

Каждый сервер привносит свой набор инструментов (сервер GitHub добавляет инструменты для pull request, сервер базы данных — инструменты запросов и т. д.). Система разрешений покрывает их тоже, но с другой записью: правила используют формат mcp__servername__toolname вместо спецификатора в скобках.

Важно помнить, что MCP фактически удваивает задачу: вы решаете не только, что Claude может делать в вашей оболочке, но и что он может делать во всех внешних системах, к которым вы его подключили.

Песочница

Песочница — это защита на уровне ОС под инструментом Bash.

Правила разрешений говорят Claude, что ему следует делать. Песочница ограничивает то, что он может сделать на уровне операционной системы, ограничивая доступ к файловой системе и исходящий трафик. На macOS она работает «из коробки» через Seatbelt. На Linux и WSL2 нужно предварительно установить bubblewrap и socat.

Оба слоя похожи, но покрывают разные сценарии. Разрешения не дают Claude пытаться, а песочница не даст попытке увенчаться успехом, даже если инъекция подсказки всё же убедит Claude попробовать.

Аудит

Последний элемент — возможность увидеть, что произошло.

Команда /permissions показывает все активные правила и файлы настроек, из которых они взяты, чтобы ответить на вопрос «почему Claude это запустил?». Хуки (PreToolUse, PostToolUse и др.) позволяют логировать каждый вызов инструмента в вашей системе. Для команд экспортеры OpenTelemetry отправляют данные об использовании и вызовах инструментов в вашу существующую систему наблюдаемости.

Разрешения и контроль доступа в Claude Code

Основная безопасность обеспечивается настройками разрешений, поэтому именно здесь вы будете больше всего настраивать параметры.

Доступ к файлам

По умолчанию Claude может читать и редактировать файлы в каталоге, из которого вы его запустили.

Чтение контролирует инструмент Read, редактирование — Edit и Write. Каждый принимает шаблон пути в скобках с синтаксисом в стиле gitignore: например, Read(**/.env) совпадает со всеми .env на любой глубине, а Edit(src/**) — со всем под src/.

Запрет на Read распространяется на файловые инструменты Claude Code (Read, Grep, Glob, LS), но это лишь «лучшее усилие». Скрипт на Python или Node, запущенный через Bash, всё равно может открыть файл, потому что чтение происходит через оболочку, а не через инструмент Read. Если секреты важны, сочетайте запрет Read с запретом Bash на cat, head и tail по этим путям.

Чтобы расширить доступ за пределы рабочего каталога, используйте additionalDirectories в settings.json. Так можно дать Claude доступ к общей библиотеке вне вашего репозитория или к конфигурационному файлу в домашнем каталоге, не снимая при этом границу рабочего каталога полностью.

Выполнение команд

Инструмент Bash — тот, который нужно ограничивать особенно тщательно.

Правило с голым Bash разрешает все команды. Ограниченное правило, например Bash(npm run:*), разрешает только соответствующие вызовы. Здесь нужно использовать шаблон с двоеточием и звёздочкой, и Claude Code понимает операторы оболочки, так что правило Bash(safe-cmd:*) не совпадёт с safe-cmd && rm -rf /.

Некоторые команды выполняются без запроса в любом режиме, так как считаются по умолчанию «только для чтения». В список входят ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd и формы git только для чтения. Уменьшить этот список вручную нельзя, но вы можете добавить правило ask или deny для любой из этих команд, чтобы переопределить поведение по умолчанию.

Для всего, что не предодобрено, Claude запрашивает разрешение в режиме по умолчанию. Запрос показывает точную команду и позволяет одобрить её один раз, одобрить все будущие вызовы по шаблону или отклонить.

Режимы разрешений

Правила разрешений статичны, но режимы разрешений меняют поведение для неподходящих под правила вызовов.

Их пять:

• default: запрашивает при первом использовании каждого инструмента.

• acceptEdits: автоматически одобряет правки файлов в рабочем каталоге, но по-прежнему контролирует команды оболочки. Полезно, если вы доверяете правкам, но не оболочке.

• plan: Claude читает и анализирует, но не может редактировать файлы или выполнять команды. Подходит для ревью кода или планирования.

• dontAsk: автоматически отклоняет всё, что не указано явно в allow.

• bypassPermissions: пропускает все запросы на подтверждение. Безопасен только в полностью изолированных средах — контейнер или ВМ.

Можно переключать три основных режима в ходе сессии с помощью Shift+Tab или выбрать один как значение по умолчанию в settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

В командах управляемые настройки дают слой, который пользователь не может переопределить. Файл в том же формате JSON хранится в системном пути:

• /Library/Application Support/ClaudeCode/managed-settings.json в macOS

• /etc/claude-code/managed-settings.json в Linux

• C:\ProgramData\ClaudeCode\managed-settings.json в Windows

Правила deny в управляемых настройках действуют во всех проектах на машине — так можно внедрить «никто не читает .env» или «никто не включает bypassPermissions» на уровне всей организации.

Принцип, лежащий в основе всего этого, — наименьшие привилегии, тот же, что вы применяете к сервисным аккаунтам. 

Начинайте с минимального набора разрешений, достаточного для работы, и расширяйте его только при необходимости. Рекомендации Anthropic те же — проверяйте изменения, которые вносит Claude, проводите аудит правил с помощью /permissions и держите проектные настройки в системе контроля версий, чтобы команда была согласна, над чем Claude может работать.

Песочницы в Claude Code

Чем больше автономности вы даёте Claude, тем уместнее становится песочница.

Инструмент Bash имеет наибольшее воздействие, поскольку команды оболочки могут читать любые доступные вам файлы и менять всё, где есть права записи. Песочница навязывает границы ОС каждой команде Bash и её дочерним процессам, чтобы Claude мог свободнее работать внутри границ без вашего подтверждения каждого вызова. Anthropic встроила это специально для более безопасных автономных запусков.

Важно: песочница покрывает только Bash и его дочерние процессы. Она не ограничивает инструменты Read, Edit или Write — они по-прежнему идут через систему разрешений.

Нативная песочница

Нативная песочница встроена в Claude Code и включается командой /sandbox.

На macOS используется встроенный Seatbelt — установка не нужна. На Linux и WSL2 установите bubblewrap для изоляции ФС и socat для сетевого прокси. Нативная Windows не поддерживается — запускайте Claude Code внутри дистрибутива WSL2.

Граница файловой системы проста: чтение доступно везде, кроме запрещённых путей, а запись — только в рабочем каталоге и явно разрешённых путях. Если попытаться записать в ~/.bashrc из песочницы, вы получите «Operation not permitted» ещё до того, как Claude узнает о неудаче.

Сетевая граница устроена иначе. Исходящий трафик проходит через прокси-сервер вне песочницы, который проверяет каждый запрос по списку allowedDomains. Новые домены вызывают запрос на разрешение, так что вы видите, куда именно обращается Claude.

Рабочая конфигурация выглядит так:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

По внутренним данным Anthropic, песочница сокращает количество запросов разрешений на 84%.

Контейнеры для разработки

Dev-контейнеры — следующий уровень изоляции.

Anthropic предлагает эталонный devcontainer для Claude Code: разворачивает Ubuntu, монтирует ваш репозиторий и даёт агенту оболочку для работы. Преимущество перед нативной песочницей — воспроизводимость: вся команда получает одинаковую среду с теми же инструментами и настройками.

Минус — накладные расходы. 

С контейнерами добавляются сборка образа, монтирование файлов и (иногда) более медленная обратная связь. Для одного разработчика обычно хватает нативной песочницы. Для команды или CI такой подход оправдан.

Изоляция на базе Docker

Для долгих автономных сессий агента Docker может ещё сильнее расширить границы песочницы.

Обычно это выглядит так:

• Минимальный базовый образ: удалите менеджеры пакетов и сетевые утилиты, не нужные для задачи.
• Пользователь без прав root: Claude никогда не запускается от root, значит не сможет менять системные файлы или ставить глобальные пакеты.
• Корневая ФС только для чтения: примонтируйте корень контейнера read-only, оставив на запись только конкретные каталоги вывода.
• Egress-прокси: гоните исходящий трафик через прокси, который разрешает реестр пакетов (npm, PyPI) и блокирует остальное, чтобы npm install работал, а произвольный curl — нет.
• Лимиты ресурсов: ограничьте CPU, память и I/O, чтобы процесс не «уронил» хост.

Docker Sandboxes дают каждой песочнице собственную microVM с приватным демоном Docker. Хостовой демон даже не видит песочницы в docker ps. Граница ближе к ВМ, чем к контейнеру, что закрывает большинство путей побега из контейнера, о которых переживают разработчики.

Стратегии песочниц для предприятий

Для организаций вопрос не «нужно ли использовать песочницы», а «как их наслаивать».

Обычно подход такой:

• Правила разрешений — в managed-settings.json и их нельзя переопределить локально.

• Под слоем разрешений работает нативная песочница.

• Ещё ниже — dev-контейнеры или Docker.

• В сценариях с наивысшим доверием (продакшен-доступ, работа с секретами) последним слоем становится выделенная ВМ без монтирования ФС хоста.

Claude Code в вебе — управляемая версия той же идеи. Каждая сессия запускается в ВМ под управлением Anthropic, чувствительные учётные данные, такие как git-токены, находятся вне песочницы в прокси, а границы обеспечиваются инфраструктурой.

Безопасность MCP в Claude Code

MCP — часть Claude Code, которая развивается быстрее всего.

Каждый подключённый сервер MCP кратно увеличивает возможности Claude, но также увеличивает поверхность, доступную для инъекций подсказок или скомпрометированных зависимостей. 

Например:

• Сервер MCP GitHub даёт Claude доступ к pull request.
• Сервер MCP базы данных предоставляет схему и запросы.
• Сервер Slack даёт доступ к каналам.

В этом нет проблемы, но MCP требует собственного управления. Контент, полученный через инструмент MCP (веб-страница или ответ API), может содержать внедрённые инструкции, которые Claude выполнит так, как если бы вы их ввели. Кроме того, каждый сервер добавляет свой набор учётных данных и путь аутентификации, которые нужно отдельно администрировать.

Разрешения инструментов

Инструменты MCP используют другую схему имен, чем встроенные инструменты.

Формат правила — mcp__servername__toolname, без спецификатора в скобках. Например, mcp__github__create_pull_request позволяет Claude вызывать именно этот инструмент, а запрет на mcp__github__delete_repo блокирует опасный инструмент. Списки allow, ask и deny работают так же, как для Bash или Read.

Действуют те же приоритеты — сначала deny, затем ask, потом allow. Запрет в управляемых настройках на mcp__github__delete_* применим во всех проектах на машине.

Разрешения ресурсов

Серверы MCP могут предоставлять ресурсы вместе с инструментами.

Ресурс — это данные, которые сервер делает доступными для чтения Claude (файл в сервере управления проектами или строка в сервере БД). Доступ к ресурсам проходит через тот же проверочный контур доверия, что и вызовы инструментов, а первое подключение к серверу MCP запускает проверку доверия до того, как его инструменты или ресурсы станут доступны.

Правильный подход — рассматривать ресурсы как ещё один инструмент. Если вы не выдали бы учётные данные, не выдавайте и доступ к ресурсу.

Одобренные серверы MCP

В каталоге Anthropic перечислены коннекторы, которые Anthropic проверила по своим критериям листинга.

Для организаций хорошая практика — внутренний список разрешённых. Есть два параметра, которые дают контроль:

• allowedMcpServers: шаблон серверов, которые разработчики могут добавлять в проекты (например, company-*, чтобы разрешить только внутренние серверы).

• deniedMcpServers: шаблон серверов, которые нельзя добавить, даже если разработчик попробует.

Для обязательных серверов, которые должны присутствовать в каждой сессии, используйте файл managed-mcp.json в управляемых настройках. Разработчики не могут удалять или менять эти записи.

Настройка, которую стоит избегать в общих репозиториях, — enableAllProjectMcpServers, автоматически одобряющая каждый сервер MCP из .mcp.json. Для сольной работы это удобно, но для репозитория — опасно: вредоносный PR может добавить новый сервер в .mcp.json, и он запустится без запроса.

Доступ к инструментам по принципу наименьших привилегий

Тот же принцип, что и для Bash, только применённый к MCP.

Начинайте с вопроса, какие учётные данные у каждого сервера. Сервер MCP для БД должен подключаться к read-replica с доступом только на чтение, а не к primary с правами записи. MCP-сервер API должен использовать токен с минимумом необходимых прав, а не персональный токен с полным доступом к организации. И так далее.

Субагенты — ещё один способ ограничить доступ MCP. Определение субагента в .claude/agents/ может объявить, к каким именно инструментам у него есть доступ (синтаксис mcp:<server>:<tool>), так что «deploy-agent» получает сервер инфраструктуры, а «review-agent» — только Read, Grep и Glob. Агент не может вызвать инструменты, которые ему не выдали.

Управление MCP

Для команды или организации, использующей Claude Code в масштабе, MCP требует такого же управления, как и любая продакшен-интеграция.

Это значит: реестр одобренных серверов с назначенными владельцами, сквозные журналы вызовов инструментов (какие инструменты MCP вызывались, кем и с какими параметрами) и периодический пересмотр списка одобрений. Экспортеры OpenTelemetry в Claude Code дают данные аудита в формате, который вписывается в вашу текущую систему наблюдаемости.

Для крупных организаций самый чистый вариант — централизованный MCP-шлюз. 

Разработчики подключаются к шлюзу вместо регистрации отдельных серверов. Шлюз обрабатывает аутентификацию, применяет ролевой доступ на уровне инструментов и формирует единый журнал аудита. Он также решает проблему расползания учётных данных: один набор на шлюзе заменяет копии каждого API-ключа у каждого разработчика.

Управление секретами и конфиденциальными данными

Claude Code может читать всё, что можете читать вы, — это делает секреты достижимыми.

По умолчанию Claude Code может читать каждый файл, доступный вашей учётной записи. Это включает .env в проекте, AWS-данные в ~/.aws/, приватные SSH-ключи в ~/.ssh/, токены GitHub в вашем shell rc и переменные окружения в любых подпроцессах, которые создаёт Claude. Это нормально и ожидаемо по дизайну.

Держите секреты вне рабочего пространства

Первый шаг — убедиться, что секретов нет в каталоге, который читает Claude.

.env — самые распространённые: они лежат в корне проекта, подхватываются всеми dev-инструментами и содержат именно то, что не хочется видеть в контексте Claude (URL баз данных и API-ключи). 

Вот несколько рабочих вариантов:

• Переместите секреты в каталог вне дерева проекта, например ~/.config/myapp/secrets.env, и загружайте их через менеджер окружения или direnv, указывающий на внешний файл.

• Для контейнеров держите папку .secrets/ вне bind-монта, чтобы файл был невидим из контейнера.

• Добавьте Read(**/.env) и Read(**/.env.*) в permissions.deny и дополняйте их запретами Bash(cat:*/.env), чтобы скрипт оболочки не мог прочитать то, что запрещено инструменту Read.

Используйте менеджер секретов

Для всего, что выходит за рамки демо-проектов, верное место для секретов — менеджер секретов.

Шаблон одинаков у разных вендоров (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Секреты хранятся в менеджере. Ваша оболочка или рантайм получают их по запросу и выставляют только процессу, которому они нужны. Claude никогда не видит фактическое значение.

Специально для Claude Code это значит: установите CLAUDE_CODE_SUBPROCESS_ENV_SCRUB, чтобы вычищать из подпроцессов учётные данные Anthropic и облачных провайдеров, или используйте sandbox.credentials для сброса конкретных переменных при выполнении команд в песочнице. Первое не даст Claude передать ваш ANTHROPIC_API_KEY в build-скрипт, второе покрывает общий случай, когда любая чувствительная переменная окружения может попасть в команду оболочки.

Ограничьте доступ к репозиториям

Третий вариант — на уровне репозитория.

Если разработчику не нужен доступ на запись к конфигурации только для продакшена, то и сессии Claude Code он не нужен. Это очевидно, но у многих команд по умолчанию у разработчиков доступ шире, чем требуется рутинно, и Claude наследует его полностью.

Два шага, которые можно предпринять:

• Вынесите продакшен-конфигурацию в отдельный репозиторий с более строгим доступом, чтобы в среде разработки, где работает Claude, не было продакшен-секретов.

• Используйте токены с областью действия для каждого сервиса, с которым взаимодействует Claude. Например, токен GitHub для ревью кода не нуждается в repo:delete.

Безопасность Claude Code для команд

Один разработчик может менять settings.json как угодно. Команда — нет, потому что общая безопасность равна безопасности самой слабой конфигурации на самой слабой машине. Для командных и организационных внедрений в Claude Code есть отдельный слой контролей, который администратор распространяет сверху, и отдельные пользователи не могут его переопределить.

Управляемые настройки

Управляемые настройки — фундамент.

Файл расположен в системном пути, для записи в который нужны права администратора:

• /Library/Application Support/ClaudeCode/managed-settings.json в macOS

• /etc/claude-code/managed-settings.json в Linux

• C:\ProgramData\ClaudeCode\managed-settings.json в Windows

Настройки в этом файле имеют приоритет над пользовательскими и проектными. Запрет, заданный здесь, действует во всех проектах на машине, и разработчик не сможет его снять, изменив свой settings.json. Большинство организаций распространяют файл через MDM (Mobile Device Management) или тот же канал конфигурации, что и для других инструментов разработчика.

Вот некоторые важные параметры на управляемом уровне:

• permissions.deny для чувствительных путей и опасных команд

• defaultMode — default или plan (никогда bypassPermissions)

• allowManagedPermissionRulesOnly: true для «заморозки» набора разрешений

• enableAllProjectMcpServers: false для явного одобрения MCP

• Конфигурация экспортера OpenTelemetry для логирования

Общие политики разрешений

Команда, договорившаяся о том, что можно Claude, должна хранить это в системе контроля версий.

Проектные настройки лежат в .claude/settings.json в корне репозитория. Всё, что закоммичено сюда, применяется ко всем, кто запускает Claude в этом репо. Это правильное место для проектных allow/deny.

Важно понимать разделение между управляемыми и проектными настройками:

• Управляемые настройки — политика организации (никто не включает bypassPermissions, никто не читает .env).

• Проектные — рабочие соглашения (тесты запускаются npm test; скрипт деплоя запрещён).

Командное управление

Для командного внедрения у слоя политики должен быть владелец.

Большинство команд, использующих Claude Code на масштабе, формируют небольшую группу (обычно безопасность и платформа), которая отвечает за управляемые настройки, список разрешённых MCP, хук-скрипты и конвейер OpenTelemetry. Эта же группа рассматривает исключения и корректирует политику по мере появления новых сценариев.

Стоит зафиксировать письменно:

• Какие репозитории в охвате, какие нет, и режимы по уровню риска (репозиторий с регуляторными данными — режим plan, маркетинговый сайт — acceptEdits).
• Кто может давать исключения и как их учитывать.
• Периодичность пересмотра (часто — раз в квартал) для правил разрешений, серверов MCP и инцидентов.

Аудит-логирование

Claude Code отправляет события OpenTelemetry для каждого решения по инструменту, подключения к серверу MCP, смены режима разрешений и API-запроса. Пока администратор не настроит OTLP-эндпоинт в управляемых настройках, данные не отправляются.

Минимальный блок управляемых настроек для телеметрии:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

По умолчанию содержимое подсказок и параметры инструментов в экспорт не включены, так что собираемые события — это метаданные, а не вся переписка. Чтобы включить текст подсказок, задайте OTEL_LOG_USER_PROMPTS=1. Чтобы включить аргументы инструментов (что обычно и нужно для аудита), задайте OTEL_LOG_TOOL_DETAILS=1. У обоих решений есть последствия для приватности, поэтому большинство команд оформляют их как отдельные политики и настраивают бэкенд телеметрии на фильтрацию или редактирование перед хранением.

Мониторинг использования

Тот же поток OpenTelemetry, что используется для аудита, лежит и в основе мониторинга использования.

Claude Code экспортирует метрики по использованию токенов, стоимости запроса, числу сессий и долям решений по инструментам. В агрегате они показывают, какие команды получают наибольшую пользу, какие процессы дают больше всего отклонений и какие модели формируют стоимость. Бэкенды вроде Datadog, Honeycomb, SigNoz, Elastic и Splunk принимают стандартный формат OTLP.

Всплеск событий permission_decision с decision=deny может означать, что Claude «пытается слишком много», но может также говорить о чрезмерно жёстких allow-правилах у команды.

Частые ошибки безопасности в Claude Code

Небольшой набор неправильных настроек встречается в большинстве инцидентов с Claude Code. Ниже — что это за ошибки и как их исправлять.

Слишком широкие разрешения

Самый быстрый способ обесценить систему разрешений — позволить слишком много.

Подтверждения по командам создают трение, и простой «фикс» — широкое Bash(*) или defaultMode: bypassPermissions. Оба варианта сводят на нет большую часть пользы от разрешений.

Ограничивайте allow до конкретных инструментов и команд, которые вы реально используете (например, Bash(npm test:*) и Bash(git status)), а остальное пусть вызывает запрос. Сначала запросов будет больше, но за пару сессий вы отлистите привычные команды, и запросы почти исчезнут.

Неограниченный доступ MCP

Вторая ошибка — подключение серверов MCP без проверки их учётных данных и зон доступа.

Обычно это происходит, когда кто-то включает enableAllProjectMcpServers, подключает несколько серверов из публичного каталога MCP и не возвращается к ревизии. Когда сервер со слабыми учётными данными что-то утечёт, с момента подключения прошло достаточно времени, чтобы никто уже не помнил, кто это одобрил.

Исправление то же, что и для разрешений: явный allowlist через allowedMcpServers, внутренний managed-mcp.json для серверов, нужных всем, и регулярный пересмотр списка.

Отсутствие песочницы

Если песочница выключена, между Claude и вашей ФС остаётся только система разрешений.

Для коротких интерактивных сессий, где вы и так подтверждаете каждую команду, это приемлемо. Для автономных запусков, сессий с расширенными allow или любой работы с внешним кодом — уже нет.

/sandbox включает её. Если зависимости не установлены, меню покажет, какие поставить для вашей платформы. После включения число запросов падает, а ОС ловит случаи, не покрытые allow-правилами.

Слепое принятие изменений

acceptEdits одновременно удобен и опасен.

Когда Claude переписывает функцию, а вы следите — авто-принятие нормально. Когда Claude час вносит правки в 30 файлов, вы перестаёте читать диффы и начинаете доверять агенту. Именно тут возможны проблемы.

Две полезные привычки:

• Всегда делайте коммит перед автономным запуском Claude, чтобы откат был в один git reset.

• Просматривайте дифф перед каждым коммитом, созданным Claude, а не общий дифф в конце сессии.

Игнорирование журналов аудита

Команда, использующая Claude Code без телеметрии, не может ответить на вопрос «какая сессия это сделала?». События копятся локально на каждой машине и там же остаются. Первый раз, когда вам нужен аудит-след, — худший момент, чтобы обнаружить, что он не настроен.

Минимально полезный базис — экспорт событий tool_decision, permission_decision и api_request в вашу существующую систему наблюдаемости. Дальше вы строите дашборды и алерты по мере появления задач.

Заключение

Худшее для чат-бота — неверный ответ. А для кодирующего агента — команда оболочки, запущенная против продакшена с вашими учётными данными.

Поэтому важны три столпа:

• Разрешения определяют, что Claude можно делать
• Контроли MCP определяют, к каким внешним системам он может обращаться
• Песочница определяет, что произойдёт, когда первых двух недостаточно

Каждый слой покрывает сбой, который не покрывают другие. Вместе они определяют реальные границы, внутри которых работает Claude.

Если вы хотите получить сертификат по генеративному ИИ, здесь собраны сравнения, лучшие курсы, советы по подготовке и ответы на вопросы для лучших сертификатов по генеративному ИИ в 2026 году.