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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка:

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

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

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

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

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

Контейнеры

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

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

Вот что делает каждый вариант:

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

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

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

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

gVisor

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

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

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

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

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

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

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

Виртуальные машины обеспечивают изоляцию на уровне оборудования через расширения виртуализации ЦП. Каждая виртуальная машина запускает свое собственное ядро, создавая сильную границу — уязвимость в ядре гостя не напрямую компрометирует хост. Однако виртуальные машины не являются автоматически «более безопасными», чем альтернативы, такие как 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 выборки)

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

Вариант 2: HTTP_PROXY / HTTPS_PROXY (системный)

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Запуска прокси вне контейнера агента
2. Установки сертификата ЦС прокси в хранилище доверия агента (чтобы агент доверял сертификатам прокси)
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 и доверенного сертификата ЦС — они просто гарантируют, что трафик действительно достигает прокси.

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

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

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

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

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

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

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

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

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

• Документация по безопасности 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