Безопасное развертывание AI-агентов

Claude Code и Agent SDK — это мощные инструменты, которые могут выполнять код, получать доступ к файлам и взаимодействовать с внешними сервисами от вашего имени. Как и любой инструмент с такими возможностями, их продуманное развертывание гарантирует, что вы получите преимущества, сохраняя при этом надлежащий контроль. В отличие от традиционного программного обеспечения, которое следует предопределенным путям кода, эти инструменты динамически генерируют свои действия на основе контекста и целей. Эта гибкость делает их полезными, но это также означает, что их поведение может быть подвержено влиянию содержимого, которое они обрабатывают: файлов, веб-страниц или пользовательского ввода. Это иногда называют prompt injection. Например, если README репозитория содержит необычные инструкции, Claude Code может включить их в свои действия способами, которые оператор не предусмотрел. Это руководство охватывает практические способы снижения этого риска. Хорошая новость заключается в том, что защита развертывания агента не требует экзотической инфраструктуры. Те же принципы, которые применяются к запуску любого полудоверенного кода, применяются здесь: изоляция, принцип наименьших привилегий и защита в глубину. Claude Code включает несколько функций безопасности, которые помогают решить распространенные проблемы, и это руководство проходит через них вместе с дополнительными вариантами усиления для тех, кто в них нуждается. Не каждое развертывание требует максимальной безопасности. Разработчик, запускающий Claude Code на своем ноутбуке, имеет другие требования, чем компания, обрабатывающая данные клиентов в многопользовательской среде. Это руководство представляет варианты, начиная от встроенных функций безопасности Claude Code до усиленных архитектур производства, чтобы вы могли выбрать то, что подходит вашей ситуации.

Модель угроз

Агенты могут предпринимать непредусмотренные действия из-за prompt injection (инструкции, встроенные в содержимое, которое они обрабатывают) или ошибки модели. Модели Claude разработаны для сопротивления этому; см. обзор модели и карту системы для модели, которую вы развертываете, для получения деталей оценки. Защита в глубину все еще является хорошей практикой. Например, если агент обрабатывает вредоносный файл, который инструктирует его отправить данные клиентов на внешний сервер, сетевые элементы управления могут полностью заблокировать этот запрос.

Встроенные функции безопасности

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

Система разрешений: Каждый инструмент и команда bash можно настроить на разрешение, блокировку или запрос одобрения пользователя. Используйте glob-шаблоны для создания правил, таких как “разрешить все команды npm” или “заблокировать любую команду с sudo”. Организации могут устанавливать политики, которые применяются ко всем пользователям. См. разрешения.
Парсинг команд для разрешений: Перед выполнением команд bash Claude Code анализирует их в AST и сопоставляет результат с вашими правилами разрешений. Команды, которые не могут быть четко проанализированы или не соответствуют правилу разрешения, требуют явного одобрения. Небольшой набор конструкций, таких как eval, всегда требует одобрения независимо от правил разрешения. Это шлюз разрешений, а не sandbox; он не определяет, опасна ли команда, исходя из целевого пути или эффектов.
Суммирование результатов веб-поиска: Результаты поиска суммируются, а не передаются в контекст в виде необработанного содержимого, что снижает риск prompt injection из вредоносного веб-контента.
Режим sandbox: Команды Bash могут выполняться в изолированной среде, которая ограничивает доступ к файловой системе и сети. Подробности см. в документации по sandboxing.

Принципы безопасности

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

Границы безопасности

Граница безопасности разделяет компоненты с разными уровнями доверия. Для развертываний с высокой безопасностью вы можете разместить чувствительные ресурсы (такие как учетные данные) вне границы, содержащей агента. Если что-то пойдет не так в среде агента, ресурсы вне этой границы остаются защищенными. Например, вместо того чтобы давать агенту прямой доступ к ключу API, вы можете запустить прокси вне среды агента, который внедряет ключ в запросы. Агент может делать вызовы API, но он никогда не видит саму учетную данные. Этот паттерн полезен для многопользовательских развертываний или при обработке ненадежного содержимого.

Принцип наименьших привилегий

При необходимости вы можете ограничить агента только возможностями, необходимыми для его конкретной задачи:

Ресурс	Варианты ограничения
Файловая система	Монтируйте только необходимые каталоги, предпочитайте только для чтения
Сеть	Ограничьте определенными конечными точками через прокси
Учетные данные	Внедрите через прокси, а не раскрывайте напрямую
Возможности системы	Удалите возможности Linux в контейнерах

Защита в глубину

Для высокозащищенных сред наслоение нескольких элементов управления обеспечивает дополнительную защиту. Варианты включают:

Изоляция контейнеров
Ограничения сети
Элементы управления файловой системой
Валидация запросов на прокси

Правильная комбинация зависит от вашей модели угроз и операционных требований.

Технологии изоляции

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

Во всех этих конфигурациях Claude Code (или ваше приложение Agent SDK) работает внутри границы изоляции (sandbox, контейнер или VM). Элементы управления безопасностью, описанные ниже, ограничивают то, к чему агент может получить доступ из этой границы.

Технология	Сила изоляции	Накладные расходы производительности	Сложность
Sandbox runtime	Хорошая (безопасные значения по умолчанию)	Очень низкие	Низкая
Контейнеры (Docker)	Зависит от настройки	Низкие	Средняя
gVisor	Отличная (при правильной настройке)	Средняя/Высокая	Средняя
VMs (Firecracker, QEMU)	Отличная (при правильной настройке)	Высокие	Средняя/Высокая

Sandbox runtime

Для легкой изоляции без контейнеров sandbox-runtime обеспечивает ограничения файловой системы и сети на уровне ОС. Основное преимущество — простота: не требуется конфигурация Docker, образы контейнеров или настройка сети. Прокси и ограничения файловой системы встроены. Вы предоставляете файл настроек, указывающий разрешенные домены и пути. Как это работает:

Файловая система: Использует примитивы ОС (bubblewrap на Linux, sandbox-exec на macOS) для ограничения доступа на чтение/запись к настроенным путям
Сеть: Удаляет пространство имен сети (Linux) или использует профили Seatbelt (macOS) для маршрутизации сетевого трафика через встроенный прокси
Конфигурация: Списки разрешений на основе JSON для доменов и путей файловой системы

Настройка:

npm install @anthropic-ai/sandbox-runtime

Затем создайте файл конфигурации, указывающий разрешенные пути и домены. Соображения безопасности:

Ядро на одном хосте: В отличие от VMs, изолированные процессы используют ядро хоста. Уязвимость ядра теоретически может позволить выход. Для некоторых моделей угроз это приемлемо, но если вам нужна изоляция на уровне ядра, используйте gVisor или отдельную VM.
Без проверки TLS: Прокси создает список разрешений доменов на основе имени хоста, предоставленного клиентом, и не завершает и не проверяет зашифрованный трафик. Код, работающий внутри sandbox, потенциально может использовать domain fronting или аналогичные методы для доступа к хостам вне списка разрешений. Если ваша модель угроз требует более сильных гарантий, настройте прокси, завершающий TLS. Подробнее см. в ограничениях безопасности sandboxing. Отдельно, если агент имеет разрешающие учетные данные для разрешенного домена, убедитесь, что он не может использовать этот домен для запуска других сетевых запросов или для утечки данных.

Для многих случаев использования одного разработчика и CI/CD sandbox-runtime значительно повышает планку с минимальной настройкой. Разделы ниже охватывают контейнеры и VMs для развертываний, требующих более сильной изоляции.

Контейнеры

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

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

Вот что делает каждый параметр:

Параметр	Назначение
`--cap-drop ALL`	Удаляет возможности Linux, такие как `NET_ADMIN` и `SYS_ADMIN`, которые могут позволить повышение привилегий
`--security-opt no-new-privileges`	Предотвращает получение процессами привилегий через двоичные файлы setuid
`--security-opt seccomp=...`	Ограничивает доступные системные вызовы; значение по умолчанию Docker блокирует ~44, пользовательские профили могут блокировать больше
`--read-only`	Делает корневую файловую систему контейнера неизменяемой, предотвращая сохранение изменений агентом
`--tmpfs /tmp:...`	Предоставляет записываемый временный каталог, который очищается при остановке контейнера
`--network none`	Удаляет все сетевые интерфейсы; агент взаимодействует через смонтированный Unix-сокет ниже
`--memory 2g`	Ограничивает использование памяти, чтобы предотвратить истощение ресурсов
`--pids-limit 100`	Ограничивает количество процессов, чтобы предотвратить fork bombs
`--user 1000:1000`	Запускается от непривилегированного пользователя
`-v ...:/workspace:ro`	Монтирует код только для чтения, чтобы агент мог анализировать, но не изменять его. Избегайте монтирования чувствительных каталогов хоста, таких как `~/.ssh`, `~/.aws` или `~/.config`
`-v .../proxy.sock:...`	Монтирует Unix-сокет, подключенный к прокси, работающему вне контейнера (см. ниже)

Архитектура Unix-сокета: С --network none контейнер вообще не имеет сетевых интерфейсов. Единственный способ для агента достичь внешнего мира — через смонтированный Unix-сокет, который подключается к прокси, работающему на хосте. Этот прокси может обеспечивать списки разрешений доменов, внедрять учетные данные и регистрировать весь трафик. Это та же архитектура, используемая sandbox-runtime. Даже если агент скомпрометирован через prompt injection, он не может утечь данные на произвольные серверы. Он может взаимодействовать только через прокси, который контролирует, какие домены доступны. Для получения дополнительной информации см. блог Claude Code sandboxing. Дополнительные варианты усиления:

Параметр	Назначение
`--userns-remap`	Отображает корень контейнера на непривилегированного пользователя хоста; требует конфигурации демона, но ограничивает ущерб от выхода контейнера
`--ipc private`	Изолирует межпроцессное взаимодействие, чтобы предотвратить атаки между контейнерами

gVisor

Стандартные контейнеры используют ядро хоста: когда код внутри контейнера делает системный вызов, он идет непосредственно к тому же ядру, которое запускает хост. Это означает, что уязвимость ядра может позволить выход контейнера. gVisor решает эту проблему, перехватывая системные вызовы в пользовательском пространстве перед тем, как они достигнут ядра хоста, реализуя свой собственный уровень совместимости, который обрабатывает большинство системных вызовов без участия реального ядра. Если агент запускает вредоносный код (возможно, из-за prompt injection), этот код работает в контейнере и может попытаться использовать уязвимости ядра. С gVisor поверхность атаки намного меньше: вредоносный код должен сначала использовать реализацию gVisor в пользовательском пространстве и будет иметь ограниченный доступ к реальному ядру. Чтобы использовать gVisor с Docker, установите runtime runsc и настройте демон:

// /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

Затем запустите контейнеры с:

docker run --runtime=runsc agent-image

Соображения производительности:

Рабочая нагрузка	Накладные расходы
Вычисления, связанные с CPU	~0% (без перехвата системных вызовов)
Простые системные вызовы	~2× медленнее
Интенсивный ввод-вывод файлов	До 10-200× медленнее для тяжелых паттернов открытия/закрытия

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

Виртуальные машины

VMs обеспечивают изоляцию на уровне оборудования через расширения виртуализации CPU. Каждая VM запускает свое собственное ядро, создавая сильную границу. Уязвимость в ядре гостя не напрямую компрометирует хост. Однако VMs не автоматически “более безопасны” чем альтернативы, такие как gVisor. Безопасность VM сильно зависит от гипервизора и кода эмуляции устройств. Firecracker разработан для легкой изоляции microVM. Он может загружать VMs менее чем за 125 мс с накладными расходами памяти менее 5 МиБ, убирая ненужную эмуляцию устройств, чтобы уменьшить поверхность атаки. При таком подходе VM агента не имеет внешнего сетевого интерфейса. Вместо этого она взаимодействует через vsock (виртуальные сокеты). Весь трафик маршрутизируется через vsock к прокси на хосте, который обеспечивает списки разрешений и внедряет учетные данные перед пересылкой запросов.

Облачные развертывания

Для облачных развертываний вы можете комбинировать любую из вышеуказанных технологий изоляции с облачными сетевыми элементами управления:

Запустите контейнеры агента в приватной подсети без интернет-шлюза
Настройте правила облачного брандмауэра (AWS Security Groups, GCP VPC firewall) для блокировки всего исходящего трафика, кроме как к вашему прокси
Запустите прокси (такой как Envoy с его фильтром credential_injector), который проверяет запросы, обеспечивает списки разрешений доменов, внедряет учетные данные и пересылает на внешние API
Назначьте минимальные разрешения IAM учетной записи сервиса агента, маршрутизируя чувствительный доступ через прокси, где это возможно
Регистрируйте весь трафик на прокси в целях аудита

Управление учетными данными

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

Паттерн прокси

Рекомендуемый подход — запустить прокси вне границы безопасности агента, который внедряет учетные данные в исходящие запросы. Агент отправляет запросы без учетных данных, прокси добавляет их и пересылает запрос к его месту назначения. Этот паттерн имеет несколько преимуществ:

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

Настройка Claude Code для использования прокси

Claude Code поддерживает два метода маршрутизации запросов выборки через прокси: Вариант 1: ANTHROPIC_BASE_URL (простой, но только для запросов API выборки)

export ANTHROPIC_BASE_URL="http://localhost:8080"

Это говорит Claude Code и Agent SDK отправлять запросы выборки на ваш прокси вместо прямого обращения к Claude API. Ваш прокси получает открытые HTTP-запросы, может проверять и изменять их (включая внедрение учетных данных), затем пересылает на реальный API. Вариант 2: HTTP_PROXY / HTTPS_PROXY (системный уровень)

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude Code и Agent SDK соблюдают эти стандартные переменные окружения, маршрутизируя весь HTTP-трафик через прокси. Для HTTPS прокси создает зашифрованный туннель CONNECT: он не может видеть или изменять содержимое запроса без перехвата TLS.

Реализация прокси

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

Envoy Proxy: прокси производственного уровня с фильтром credential_injector для добавления заголовков аутентификации
mitmproxy: прокси, завершающий TLS, для проверки и изменения HTTPS-трафика
Squid: кэширующий прокси со списками контроля доступа
LiteLLM: шлюз LLM с внедрением учетных данных и ограничением скорости

Учетные данные для других сервисов

Помимо выборки из Claude API, агентам часто нужен аутентифицированный доступ к другим сервисам, таким как git-репозитории, базы данных и внутренние API. Есть два основных подхода:

Пользовательские инструменты

Предоставьте доступ через MCP-сервер или пользовательский инструмент, который маршрутизирует запросы к сервису, работающему вне границы безопасности агента. Агент вызывает инструмент, но фактический аутентифицированный запрос происходит снаружи. Вызовы инструмента идут к прокси, который внедряет учетные данные. Например, MCP-сервер git может принимать команды от агента, но пересылать их на git-прокси, работающий на хосте, который добавляет аутентификацию перед контактом с удаленным репозиторием. Агент никогда не видит учетные данные. Преимущества:

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

Пересылка трафика

Для вызовов Claude API ANTHROPIC_BASE_URL позволяет маршрутизировать запросы к прокси, который может проверять и изменять их в открытом виде. Но для других HTTPS-сервисов (GitHub, npm-реестры, внутренние API) трафик часто зашифрован от конца до конца. Даже если вы маршрутизируете его через прокси через HTTP_PROXY, прокси видит только непрозрачный TLS-туннель и не может внедрять учетные данные. Чтобы изменить HTTPS-трафик к произвольным сервисам без использования пользовательского инструмента, вам нужен прокси, завершающий TLS, который расшифровывает трафик, проверяет или изменяет его, затем повторно шифрует перед пересылкой. Это требует:

Запуска прокси вне контейнера агента
Установки сертификата CA прокси в хранилище доверия агента (чтобы агент доверял сертификатам прокси)
Настройки HTTP_PROXY/HTTPS_PROXY для маршрутизации трафика через прокси

Этот подход обрабатывает любой HTTP-сервис без написания пользовательских инструментов, но добавляет сложность вокруг управления сертификатами. Обратите внимание, что не все программы соблюдают HTTP_PROXY/HTTPS_PROXY. Большинство инструментов (curl, pip, npm, git) соблюдают, но некоторые могут обойти эти переменные и подключиться напрямую. Например, Node.js fetch() по умолчанию игнорирует эти переменные; в Node 24+ вы можете установить NODE_USE_ENV_PROXY=1 для включения поддержки. Для полного охвата вы можете использовать proxychains для перехвата сетевых вызовов или настроить iptables для перенаправления исходящего трафика на прозрачный прокси.

Прозрачный прокси перехватывает трафик на сетевом уровне, поэтому клиент не нужно настраивать для его использования. Обычные прокси требуют, чтобы клиенты явно подключались и говорили HTTP CONNECT или SOCKS. Прозрачные прокси (такие как Squid или mitmproxy в прозрачном режиме) могут обрабатывать необработанные перенаправленные TCP-соединения.

Оба подхода все еще требуют прокси, завершающего TLS, и доверенного сертификата CA. Они просто гарантируют, что трафик действительно достигает прокси.

Конфигурация файловой системы

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

Монтирование кода только для чтения

Когда агенту нужно анализировать код, но не изменять его, смонтируйте каталог только для чтения:

docker run -v /path/to/code:/workspace:ro agent-image

Даже доступ только для чтения к каталогу кода может раскрыть учетные данные. Распространенные файлы для исключения или санитизации перед монтированием:

Файл	Риск
`.env`, `.env.local`	Ключи API, пароли базы данных, секреты
`~/.git-credentials`	Пароли/токены Git в открытом виде
`~/.aws/credentials`	Ключи доступа AWS
`~/.config/gcloud/application_default_credentials.json`	Токены Google Cloud ADC
`~/.azure/`	Учетные данные Azure CLI
`~/.docker/config.json`	Токены аутентификации реестра Docker
`~/.kube/config`	Учетные данные кластера Kubernetes
`.npmrc`, `.pypirc`	Токены реестра пакетов
`*-service-account.json`	Ключи учетной записи сервиса GCP
`.pem`, `.key`	Приватные ключи

Рассмотрите возможность копирования только необходимых исходных файлов или использования фильтрации в стиле .dockerignore.

Записываемые местоположения

Если агенту нужно писать файлы, у вас есть несколько вариантов в зависимости от того, хотите ли вы, чтобы изменения сохранялись: Для эфемерных рабочих пространств в контейнерах используйте монтирования tmpfs, которые существуют только в памяти и очищаются при остановке контейнера:

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

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

Agent SDK

Основные концепции

Ввод и вывод

Расширить с помощью инструментов

Настройка поведения

Управление и наблюдаемость

Развертывание

Справочные материалы SDK

Безопасное развертывание AI-агентов

Модель угроз

Встроенные функции безопасности

Принципы безопасности

Границы безопасности

Принцип наименьших привилегий

Защита в глубину

Технологии изоляции

Sandbox runtime

Контейнеры

gVisor

Виртуальные машины

Облачные развертывания

Управление учетными данными

Паттерн прокси

Настройка Claude Code для использования прокси

Реализация прокси

Учетные данные для других сервисов

Пользовательские инструменты

Пересылка трафика

Конфигурация файловой системы

Монтирование кода только для чтения

Записываемые местоположения

Дополнительное чтение

​Модель угроз

​Встроенные функции безопасности

​Принципы безопасности

​Границы безопасности

​Принцип наименьших привилегий

​Защита в глубину

​Технологии изоляции

​Sandbox runtime

​Контейнеры

​gVisor

​Виртуальные машины

​Облачные развертывания

​Управление учетными данными

​Паттерн прокси

​Настройка Claude Code для использования прокси

​Реализация прокси

​Учетные данные для других сервисов

​Пользовательские инструменты

​Пересылка трафика

​Конфигурация файловой системы

​Монтирование кода только для чтения

​Записываемые местоположения

​Дополнительное чтение

Модель угроз

Встроенные функции безопасности

Принципы безопасности

Границы безопасности

Принцип наименьших привилегий

Защита в глубину

Технологии изоляции

Sandbox runtime

Контейнеры

gVisor

Виртуальные машины

Облачные развертывания

Управление учетными данными

Паттерн прокси

Настройка Claude Code для использования прокси

Реализация прокси

Учетные данные для других сервисов

Пользовательские инструменты

Пересылка трафика

Конфигурация файловой системы

Монтирование кода только для чтения

Записываемые местоположения

Дополнительное чтение