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

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

В отличие от традиционного программного обеспечения, которое следует предопределенным путям кода, эти инструменты динамически генерируют свои действия на основе контекста и целей. Эта гибкость делает их полезными, но это также означает, что их поведение может быть подвержено влиянию содержимого, которое они обрабатывают: файлы, веб-страницы или пользовательский ввод. Это иногда называют инъекцией подсказок. Например, если README репозитория содержит необычные инструкции, Claude Code может включить их в свои действия способами, которые оператор не предусмотрел. Это руководство охватывает практические способы снижения этого риска.

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

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

От чего мы защищаемся?

Агенты могут предпринимать непредусмотренные действия из-за инъекции подсказок (инструкции, встроенные в содержимое, которое они обрабатывают) или ошибки модели. Модели Claude разработаны для сопротивления этому, и, как мы проанализировали в нашей карточке модели, мы считаем, что Claude Opus 4.6 — это наиболее надежная передовая модель, доступная.

Защита в глубину — это все еще хорошая практика. Например, если агент обрабатывает вредоносный файл, который инструктирует его отправить данные клиентов на внешний сервер, сетевые элементы управления могут полностью заблокировать этот запрос.

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

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

• Система разрешений: Каждый инструмент и команда bash можно настроить на разрешение, блокировку или запрос одобрения у пользователя. Используйте глобальные шаблоны для создания правил, таких как "разрешить все команды npm" или "заблокировать любую команду с sudo". Организации могут устанавливать политики, которые применяются ко всем пользователям. См. управление доступом и разрешения.
• Статический анализ: Перед выполнением команд bash Claude Code запускает статический анализ для выявления потенциально рискованных операций. Команды, которые изменяют системные файлы или получают доступ к чувствительным каталогам, помечаются и требуют явного одобрения пользователя.
• Суммирование веб-поиска: Результаты поиска суммируются, а не передаются в контекст в виде необработанного содержимого, что снижает риск инъекции подсказок из вредоносного веб-содержимого.
• Режим песочницы: Команды bash могут выполняться в изолированной среде, которая ограничивает доступ к файловой системе и сети. Подробности см. в документации по изоляции.

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

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

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

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

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

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

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

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

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

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

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

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

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

Среда выполнения песочницы

Для легкой изоляции без контейнеров sandbox-runtime обеспечивает ограничения файловой системы и сети на уровне ОС.

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

Как это работает:

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

Установка:

npm install @anthropic-ai/sandbox-runtime

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

Соображения безопасности:

1. Ядро на одном хосте: В отличие от виртуальных машин, изолированные процессы используют ядро хоста. Уязвимость ядра теоретически может позволить выход. Для некоторых моделей угроз это приемлемо, но если вам нужна изоляция на уровне ядра, используйте gVisor или отдельную виртуальную машину.

2. Нет проверки TLS: Прокси создает список разрешенных доменов, но не проверяет зашифрованный трафик. Если агент имеет разрешающие учетные данные для разрешенного домена, убедитесь, что невозможно использовать этот домен для запуска других сетевых запросов или для утечки данных.

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

Контейнеры

Контейнеры обеспечивают изоляцию через пространства имен 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

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

Архитектура сокета Unix:

С --network none контейнер вообще не имеет сетевых интерфейсов. Единственный способ для агента достичь внешнего мира — через смонтированный сокет Unix, который подключается к прокси, работающему на хосте. Этот прокси может обеспечивать списки разрешенных доменов, вводить учетные данные и регистрировать весь трафик.

Это та же архитектура, используемая sandbox-runtime. Даже если агент скомпрометирован через инъекцию подсказок, он не может утечь данные на произвольные серверы — он может только взаимодействовать через прокси, который контролирует, какие домены доступны. Для получения дополнительной информации см. блог Claude Code sandboxing.

Дополнительные варианты усиления:

gVisor

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

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

Чтобы использовать gVisor с Docker, установите среду выполнения runsc и настройте демон:

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

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

docker run --runtime=runsc agent-image

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

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

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

Виртуальные машины обеспечивают изоляцию на уровне оборудования через расширения виртуализации CPU. Каждая виртуальная машина запускает свое собственное ядро, создавая сильную границу — уязвимость в ядре гостя не напрямую компрометирует хост. Однако виртуальные машины не автоматически "более безопасны" чем альтернативы, такие как gVisor. Безопасность виртуальной машины сильно зависит от гипервизора и кода эмуляции устройства.

Firecracker разработан для легкой изоляции microVM — он может загружать виртуальные машины менее чем за 125 мс с накладными расходами памяти менее 5 МиБ, убирая ненужную эмуляцию устройств для снижения поверхности атаки.

При таком подходе виртуальная машина агента не имеет внешнего сетевого интерфейса. Вместо этого она взаимодействует через vsock (виртуальные сокеты). Весь трафик маршрутизируется через vsock к прокси на хосте, который обеспечивает списки разрешенных доменов и вводит учетные данные перед пересылкой запросов.

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

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

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

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

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

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

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

Этот паттерн имеет несколько преимуществ:

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

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

Claude Code поддерживает два метода маршрутизации запросов выборки через прокси:

Вариант 1: ANTHROPIC_BASE_URL (простой, но только для запросов API выборки)

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

Это указывает Claude Code и Agent SDK отправлять запросы выборки вашему прокси вместо прямого обращения к API Anthropic. Ваш прокси получает открытые 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 с введением учетных данных и ограничением скорости

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

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

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

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

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

Преимущества:

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

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

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

Чтобы изменить трафик HTTPS на произвольные сервисы без использования пользовательского инструмента, вам нужен прокси с завершением TLS, который расшифровывает трафик, проверяет или изменяет его, затем повторно шифрует перед пересылкой. Это требует:

1. Запуска прокси вне контейнера агента
2. Установки сертификата CA прокси в хранилище доверия агента (чтобы агент доверял сертификатам прокси)
3. Настройки 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 для перенаправления исходящего трафика на прозрачный прокси.

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

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

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

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

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

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

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

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

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

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

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

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

• Документация по безопасности Claude Code
• Размещение Agent SDK
• Обработка разрешений
• Sandbox runtime
• The Lethal Trifecta for AI Agents
• OWASP Top 10 for LLM Applications
• Docker Security Best Practices
• gVisor Documentation
• Firecracker Documentation

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