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

​

Модель угроз

​

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

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

​

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

​

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

​

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

​

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

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

​

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

​

Sandbox runtime

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

npm install @anthropic-ai/sandbox-runtime

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

​

Контейнеры

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

​

gVisor

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

docker run --runtime=runsc agent-image

​

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

​

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

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

​

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

​

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

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

​

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

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

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

​

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

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

​

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

​

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

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

​

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

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

​

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

​

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

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

​

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

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