Службе безопасности в крупной компании нужно, чтобы агент, который чинит сборки и разбирает тревоги по ночам, не уносил ключи и историю своих действий за пределы сети. Раньше компромисс был половинчатым. У клиента можно было держать песочницы, где выполняются инструменты, а всё остальное, включая обработку учётных данных и запись действий агента, жило у Anthropic. С 12 ноября 2026 года картина другая: на инфраструктуру клиента переезжает весь сервис Claude Managed Agents.
Под "весь" здесь понимается управление: сервер с API и циклом агента, хранилище агентов, сессий и истории сессий, воркеры с песочницами. Сама модель остаётся снаружи, и запросы к ней идут к выбранному провайдеру, по умолчанию к Anthropic. Получается гибридная схема: управление и данные агентов внутри периметра, инференс у провайдера. Ниже разобрано, как такая схема устроена, где проходят её границы и что остаётся на плечах тех, кто её эксплуатирует.
Что именно вышло двенадцатого ноября и чем самостоятельный Managed Agents отличается от самостоятельных песочниц
Релиз вышел как закрытая бета. Доступ запрашивается через аккаунт-менеджеров Anthropic: компания передаёт архив с дистрибутивом, внутри которого лежит руководство оператора. Публичной загрузки, цены, даты общего доступа и списка подходящих клиентов в опубликованных материалах нет. По сообщению одного из обзоров, лицензия на серверный бинарник бесплатна, а модель оплачивается по прежнему договору, но официального подтверждения в найденном нет, и это стоит уточнить у аккаунт-менеджера.
Главное изменение видно по сравнению с прошлой схемой. До релиза Anthropic вела всё, кроме песочницы. После него у клиента работают сервер Managed Agents, база данных PostgreSQL с историей сессий и воркеры, на которых агенты запускают командную оболочку и файловые инструменты. Сервер предлагает тот же API, что и облачная служба, так что SDK и командная утилита ant работают с ним после смены адреса и ключа. Агенты собираются теми же базовыми вызовами, поэтому код переносится с минимальными правками.
Назначение у релиза прикладное: длительная работа без присмотра, например починка упавших сборок, проверка релизов и разбор оповещений, где у агента есть доступ к внутренним системам, а история его действий чувствительна.
"Самостоятельное развёртывание" не означает, что Claude работает автономно внутри сети. Модель не переезжает, и каждый её вызов уносит наружу накопленный разговор вместе с входами и результатами инструментов. Переезжает платформа вокруг модели, и вся остальная архитектура строится вокруг этого различия.
Из каких компонентов состоит развёртывание и где проходят три границы доверия между управлением, исполнением и инференсом
Набор компонентов небольшой. Сервер cma-server обслуживает API, выполняет цикл агента, хранит агентов и сессии и обращается к модели. Для постоянного хранения нужен PostgreSQL версии 16 или новее: без него данные держатся в памяти и пропадают при перезапуске. Воркеры опрашивают очередь окружения и исполняют команды и файловые операции внутри песочниц, собираются командой ant beta:worker или через SDK. Веб-консоль отдаётся с адреса сервера, вход идёт через корпоративного поставщика удостоверений. Утилита cma-server-admin создаёт окружения и ключи окружений.
Если смотреть на схему глазами архитектора, в ней три плоскости, и между ними три границы.
Плоскость управления включает сервер, цикл агента, хранилище и сейф с секретами. Оболочку и файловые инструменты агента сервер сам никогда не запускает.
Плоскость исполнения состоит из воркеров и песочниц. Здесь запускается всё, что агент делает в реальном мире: сборки, тесты, правки файлов. Песочница стартует только тогда, когда инструменту она нужна, а секретов внутри неё нет. Инструмент bash при этом остаётся настоящей командной оболочкой с правами и сетевым доступом воркера, и изоляция обеспечивается только контейнером или подом. Поэтому документация советует запускать воркеры в одноразовых контейнерах или виртуальных машинах.
Плоскость инференса это провайдер модели. Она единственная может находиться вне периметра. Каждый вызов модели несёт накопленный диалог, включая вводы и результаты инструментов.
Первая граница лежит между управлением и исполнением и защищена тем, что секреты в песочницу не попадают. Вторая проходит между управлением и провайдером, и её содержимое определяется настройкой инференса. Третья расположена между песочницей и внешним миром и контролируется списком разрешённых узлов.
Как выбирается провайдер инференса и что именно уходит за периметр с каждым вызовом модели
Провайдер задаётся параметром inference.provider в единственном файле конфигурации формата YAML. Допустимы пять значений: anthropic (по умолчанию), bedrock, vertex, foundry и gateway. Переменные окружения переопределяют файл, а неизвестные ключи останавливают запуск, поэтому опечатка в имени параметра обнаруживается сразу, а не в боевой работе. Минимальная настройка выглядит так:
inference:
provider: bedrock
model_fallback: false
Остальные поля зависят от провайдера. Для Bedrock выбирается способ вызова, invoke_model или messages API. Для Vertex нужен регион и, как правило, идентификатор проекта. Для Foundry указывается ресурс Azure или базовый адрес. Точные имена этих полей лежат в руководстве оператора из архива, и придумывать их по памяти не стоит: ошибка в ключе остановит сервер.
Особого внимания заслуживает вариант gateway. Он принимает шаблон адреса, один из трёх форматов запроса, карту моделей и поставщика учётных данных, который умеет обменивать короткоживущие токены OAuth. В гибридной схеме это самая интересная точка: шлюз можно поставить между сервером и любым провайдером, и тогда все вызовы модели проходят через собственный узел компании. Там удобно вести независимый журнал, вырезать из диалога лишнее, ограничивать направления и подставлять временные учётные данные, не раздавая постоянные.
Что уходит за периметр? Всё, что агент положил в диалог. Это сообщения, вводы инструментов и их результаты: содержимое файлов, вывод команд, ответы внутренних служб, которые агент прочитал. Если у компании действует соглашение о нулевом хранении данных, оно охватывает эти запросы так же, как любой вызов Messages API. Но само по себе самостоятельное развёртывание такого соглашения не создаёт, и организациям с жёсткими требованиями к расположению и конфиденциальности данных маршрут инференса придётся оценивать отдельно.
От выбора провайдера зависят и возможности агента. Инструмент web_search работает с anthropic, vertex и foundry, но не предлагается на Bedrock. Инструмент web_fetch доступен на anthropic и foundry. Параметр inference_geo принимается только на anthropic, а агенты, которые его задают, на других провайдерах получают отказ. Быстрый режим зависит от сочетания провайдера и модели. Серверный запасной переход на другую модель включён по умолчанию у anthropic, а отключается параметром inference.model_fallback: false. Для регулируемых отраслей это важно: запасная модель может оказаться не там, где разрешено обрабатывать данные.
Как разделены учётные данные и почему секреты остаются вне песочницы
В самостоятельной версии три разных учётных данных, и смешивать их нельзя. Ключ API сервера нужен приложениям, утилите ant и административной утилите. Учётные данные инференса хранит только сервер, ни воркер, ни песочница их не видят. Ключи окружений аутентифицируют воркеры, опрашивающие очередь конкретного окружения. Ключ окружения живёт 365 дней, сертификат диспетчера 825, так что ротацию лучше запланировать сразу.
Секреты агента лежат в сейфе вне песочницы. Когда инструменту MCP или поддерживаемому вызову API нужна авторизация, отдельный компонент за пределами песочницы сам прикрепляет учётные данные к запросу. Агент, даже обманутый вредоносным текстом во входных данных, не прочитает секрет из окружения: в песочнице его нет. Клиент с собственным хранилищем секретов может держать учётные данные там. Граница защиты прочерчена честно: Anthropic ограничивает её инструментами MCP и поддерживаемыми вызовами API, а для всех остальных служб, к которым агент обращается напрямую, нужны отдельные проверки.
Сетевой периметр задаётся списком разрешённых узлов для каждого окружения: запрос к любому другому адресу блокируется. В примере Anthropic для агента, чинящего сборки, это сервер git и реестр пакетов. Инструменты MCP, git и веб по умолчанию закрыты и открываются явно. Тем, кто размещает песочницу у себя, список приходится дублировать в собственном межсетевом экране. В Kubernetes простое правило исходящего трафика для подов воркеров выглядит так (адреса условные):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: cma-worker-egress
spec:
podSelector:
matchLabels: {app: cma-worker}
policyTypes: [Egress]
egress:
- to: [{ipBlock: {cidr: 10.20.0.10/32}}] # git внутри сети
ports: [{port: 443}]
- to: [{ipBlock: {cidr: 10.20.0.11/32}}] # зеркало пакетов
ports: [{port: 443}]
- to: [{namespaceSelector: {matchLabels: {kubernetes.io/metadata.name: kube-system}}}]
ports: [{port: 53, protocol: UDP}] # разрешение имён
Политика работает, только если сетевой плагин кластера её исполняет. Журналирование заложено в платформу: Managed Agents записывает каждый шаг агента, включая вызов инструмента и его результат, и экспортирует записи по протоколу OpenTelemetry в привычные системы мониторинга.
Как выглядит развёртывание от пробного стенда на Docker Compose до продуктивного кластера Kubernetes
Для разработки поставляется стенд на Docker Compose: от двух процессорных ядер, порт 8400, десять воркеров песочниц, обычный HTTP. Он не предназначен для боевой работы. Продуктивный вариант рассчитан на Kubernetes версии 1.30 и новее: два чарта Helm, контроллер Agent Sandbox, узлы с gVisor и сетевой плагин, исполняющий NetworkPolicy. PostgreSQL 16 и выше разворачивается вне чартов, входящий трафик обязан идти по TLS. На каждую сессию в Kubernetes выдаётся том /workspace размером 10 ГиБ.
Клиентский код при переезде почти не меняется: достаточно указать адрес и ключ собственного сервера.
import os
import anthropic
client = anthropic.Anthropic(
base_url=os.environ["CMA_BASE_URL"], # cma-server внутри периметра
api_key=os.environ["CMA_SERVER_API_KEY"], # ключ сервера, не ключ провайдера
)
Дальше идут привычные вызовы Managed Agents, но с оговорками, о которых ниже. Порядок внедрения при этом удобно выстроить так:
- запросить архив у аккаунт-менеджера и прочитать руководство оператора целиком, включая страницу различий с облачной службой;
- поднять стенд на Docker Compose и проверить на нём перенос одного реального агента без обращения к закрытым системам;
- выбрать провайдера инференса и, если нужен контроль вызовов, поставить перед ним собственный шлюз;
- развернуть продуктивный кластер с gVisor, политиками сети и отдельной базой, а для каждого уровня доверия завести отдельное развёртывание;
- настроить списки разрешённых узлов, вывод журналов в OpenTelemetry и ротацию ключей и сертификатов;
- включить боевую нагрузку на одном безопасном сценарии, например разборе оповещений только на чтение, и расширять набор инструментов постепенно.
Совет держать отдельное развёртывание на каждый уровень доверия идёт от самой Anthropic и вытекает из устройства: воркер с настоящей оболочкой отделён от соседей только контейнером.
Чего в самостоятельной версии нет и кому гибридная схема подходит, а кому лучше остаться на облачной
Паритета с облачной службой нет. Существуют только самостоятельные окружения: запрос облачного окружения получает ошибку 400. Конечные точки Messages и Models возвращают 404, Files API отсутствует. Нет запланированных запусков, памяти Dreams и вебхуков. Готовые навыки для docx, pdf, pptx и xlsx отклоняются, учётные данные mcp_oauth в сейфе не принимаются. Мультиагентность ограничена координатором с перечнем от 1 до 20 субагентов, без динамических сценариев, советника и субагентов, определяемых самим агентом. Результаты MCP крупнее 100 КиБ (значение mcp.max_result_bytes по умолчанию) обрезаются, а не сохраняются в файл. Если архитектура опирается на любую из этих возможностей, переезд придётся планировать вместе с её заменой.
Есть и скрытая плата, которую не показывает ни один прайс. Оператор сам запускает и обновляет сервер, базу и правила сетевого экрана, следит за необычным использованием и устанавливает каждый новый выпуск. Платформа, которую раньше эксплуатировала чужая команда дежурных, теперь целиком на вашей. Агент с командной оболочкой и учётными данными привлекательная цель, и его защита, изоляция и контроль доступа лежат на клиенте.
На вопрос, кому подходит гибридная схема, помогает ответить простая проверка. Она оправдана, если история сессий или учётные данные не имеют права покидать окружение, если агенты ходят во внутренние системы, недоступные из внешнего облака, и если есть команда платформенных инженеров, готовая обслуживать ещё один сервис. Облачная версия предпочтительнее, когда нужны вебхуки, расписания, облачные окружения и готовые офисные навыки, когда данных, чувствительных к расположению, нет, а команды эксплуатации нет вовсе.
Закрытая бета без цены и даты общего доступа не повод переносить боевую нагрузку на этой неделе. Зато это хороший повод получить архив, поднять стенд и выяснить, какие из ограничений для вашего сценария окажутся решающими, пока схема ещё меняется.