Self-hosted Cursor Agent внутри своей инфраструктуры

Агент упирается не только в качество модели

25 марта 2026 года Cursor представила self-hosted Cloud Agents. Их worker запускается внутри инфраструктуры компании: там остаются repository, выполнение инструментов и build artifacts, а агент получает доступ к тем же внутренним dependencies и network endpoints, что инженер или service account.

На поверхности это enterprise-релиз про compliance. На практике он отвечает на более широкий вопрос. Чтобы coding agent самостоятельно проверил предложенный patch, одного доступа к Git обычно мало.

repository
  + dependencies
  + runtime
  + test services
  + credentials
  + network
  = рабочая инженерная среда

Чем автономнее агент, тем больше этой среды ему требуется. В публичном pet project её легко собрать в облаке. В банке, внутреннем GitLab или десятилетнем PHP-монолите нужные ресурсы часто намеренно недоступны извне. Поэтому реальный барьер внедрения звучит уже не как «хорошо ли AI пишет код», а как «где и с какими правами он сможет выполнить работу».

Environment становится частью контекста

Для ассистента контекстом были prompt, открытый файл и пара связанных классов. Агент работает с контекстом другого масштаба. Ему нужно воспроизвести failure, установить private package, поднять контейнеры, вызвать внутренний API и прогнать integration tests.

Типичная корпоративная задача быстро выходит за границы repository:

self-hosted GitLab
        ↓
private Composer registry
        ↓
PostgreSQL + Redis
        ↓
billing.internal.company
        ↓
tests и build artifacts

Если cloud agent видит только исходники, он всё ещё может быть полезен: найти подозрительный branch, написать миграцию, предложить тест. Но feedback loop обрывается в момент, когда composer install требует внутренний registry или тест обращается к закрытому сервису. Агент возвращается из исполнителя в генератор гипотез.

Environment одновременно задаёт место запуска и поставляет исполняемую часть контекста. Модель понимает систему по тексту, результатам команд, поведению зависимостей и ответам сервисов.

Self-hosted здесь означает execution, а не полностью локальный AI

Название легко прочитать как обещание air-gapped deployment, но архитектура релиза гибридная. Cursor Cloud по-прежнему отвечает за agent harness, inference и planning. Worker внутри компании устанавливает исходящее HTTPS-соединение, локально исполняет переданные tool calls и возвращает результаты для следующего шага модели.

Cursor Cloud
inference + planning + agent harness
                 ↕
          outbound HTTPS
                 ↕
worker inside company
repository + tools + build + tests + internal services

Входящие порты, отдельный VPN-туннель до Cursor или доступ провайдера к внутренней машине не требуются. Это хорошо совпадает с обычной корпоративной сетевой политикой: inbound закрыт, outbound разрешается и контролируется по правилам организации.

Иными словами, это self-hosted execution environment, а не полностью локальная модель. Для regulated-проекта разница принципиальна: она определяет threat model, список согласований и то, какие инструменты вообще можно подключить к агенту.

Legacy получает полноценный feedback loop

Самый показательный use case — не новый сервис на публичных пакетах, а старый проект, который работает только из корпоративной сети. Например, PHP 7.x, собственный framework, внутренний Composer repository, PostgreSQL и SOAP-сервис за VPN.

Агент может прочитать такой код:

$client = new BillingClient(
    $this->config->item('billing_url')
);

Но billing_url ведёт на billing.internal.company, класс приезжает из пакета company/billing-sdk, а воспроизвести ошибку можно только на тестовой базе. Из внешнего sandbox агент понимает форму задачи, но не её фактическое поведение.

Worker внутри того же контура возвращает нормальный инженерный цикл:

прочитать код → установить private dependencies
      ↓
воспроизвести bug → изменить реализацию
      ↓
запустить tests → проверить результат → создать PR

Это не делает модель умнее. Зато даёт ей наблюдения, без которых даже сильное reasoning остаётся предположением. Для legacy такой доступ может оказаться ценнее очередного прироста benchmark score.

Агент внутри сети не должен стать root внутри компании

Self-hosted deployment решает вопрос, где выполняются команды. Он не отвечает, какие команды допустимы и к каким системам можно обращаться. Агент становится новым техническим субъектом рядом с разработчиком, CI runner и service account — значит, для него нужен отдельный permission boundary.

READ       GitLab, package registry
WRITE      отдельная branch + merge request
RUN        containers, build, tests
NETWORK    allowlisted staging endpoints
SECRETS    short-lived credentials по задаче
PRODUCTION deny by default

Доступ к базе особенно хорошо показывает эту границу. Задача «почему заказы остались в processing» почти просит выполнить SQL. Но self-hosted не означает, что агенту следует выдать production password. Безопаснее дать sanitized staging copy, выбранный read-only endpoint или узкий internal API, который возвращает только нужные поля.

То же касается секретов. Вместо общего .env — отдельная identity, минимальный scope и короткий срок жизни token. Вместо неограниченного egress — allowlist. Вместо доверия к красивому diff — журнал команд и обязательные checks перед merge.

Хорошая архитектура не пытается сделать агента эквивалентом senior-инженера со всеми исторически накопленными доступами. Она выдаёт ему ровно тот набор возможностей, который нужен конкретному workflow.

Отдельный worker снижает радиус ошибки

Каждая self-hosted agent session получает dedicated worker. Он может быть long-lived или single-use и завершаться после задачи. Сессии не делят одну машину, поэтому их filesystem, processes и временные credentials проще изолировать друг от друга.

Task A → Worker A → destroy
Task B → Worker B → destroy
Task C → Worker C → destroy

Одноразовый worker удобен как clean room: образ заранее проверен, credentials выдаются на время, после выполнения окружение удаляется. Но сам lifecycle не гарантирует безопасность. Если worker получил широкий token или может отправить чувствительный database dump в tool output, его одноразовость проблему не исправит.

Нужны несколько независимых барьеров: hardened image, network policy, лимиты ресурсов, audit trail, redaction чувствительного output и контроль того, какие artifacts разрешено сохранить. Изоляция сессии — хороший фундамент, но не замена policy.

При масштабировании coding agents становятся нагрузкой для платформы

Cursor предлагает Helm chart и Kubernetes operator для организаций, которым нужны тысячи workers. Ресурс WorkerDeployment описывает pool, а controller управляет scaling, rolling updates и lifecycle. Для инфраструктуры без Kubernetes предусмотрен fleet-management API.

Это уже язык Platform Engineering, а не настройки IDE. Команде нужно решать, кто обновляет worker image, где хранятся credentials, сколько параллельных сессий разрешено проекту, как ограничиваются CPU и память, куда уходят логи и кто расследует подозрительный tool call.

Cursor приводит Money Forward как пример такого перехода: финансовая компания строит workflow, который должен позволить почти тысяче инженеров создавать pull requests из Slack через self-hosted Cloud Agents. Здесь AI — не персональное расширение отдельного разработчика, а общая внутренняя capability с едиными policies.

developer request
        ↓
agent platform
        ↓
isolated worker + company policy
        ↓
verified pull request

У такой платформы есть привычные эксплуатационные свойства: capacity planning, quotas, observability, patch management и incident response. Стоимость модели остаётся важной, но к ней добавляется цена compute и поддержки самого worker fleet.

Три мартовских релиза складываются в одну систему

Self-hosted Agents особенно интересно смотреть рядом с двумя предыдущими релизами Cursor. Automations определяют, когда агент начинает работу. Composer 2 добавляет собственную модель, обученную под agent harness. Self-hosted worker определяет, где исполняются действия.

5 марта   Automations   → trigger
19 марта  Composer 2    → model
25 марта  Self-hosted   → execution environment

trigger + model + harness + worker + company infrastructure

Например, CI сообщает о failure, automation создаёт задачу, agent планирует исправление, внутренний worker забирает код из GitLab, устанавливает private packages, поднимает test database и создаёт merge request. Каждый компонент по отдельности полезен. Вместе они превращаются в автономный engineering pipeline.

Именно поэтому термин Cloud Agent постепенно описывает не столько физическое место запуска, сколько режим работы: background, remote, persistent и parallel. Orchestration может оставаться у provider, тогда как исполнение находится внутри customer perimeter.

Что проверить до запуска первого worker

Я бы начинал не с Kubernetes operator и не с выдачи агенту копии developer credentials. Сначала нужен один ограниченный workflow, для которого понятны входные данные, допустимые действия и критерий завершения.

1. Какие tool results уходят во внешний inference?
2. Какие repositories и branches доступны worker?
3. Какие internal endpoints действительно нужны?
4. Откуда и на какой срок выдаются secrets?
5. Может ли агент менять production?
6. Где хранятся команды, artifacts и audit logs?
7. Кто подтверждает merge и опасные действия?

Хороший первый сценарий — воспроизводимая задача на staging: исправить упавший тест, обновить внутреннюю dependency или подготовить PR после статического анализатора. Здесь легко измерить пользу и одновременно увидеть, где агент просит слишком широкий доступ.

Только после этого имеет смысл расширять boundary: добавлять сервисы, события и параллельные workers. Agent infrastructure лучше растить так же, как CI/CD — от минимального доверенного контура к формализованной платформе.

От AI-инструмента к AI-инфраструктуре

Self-hosted Cloud Agents не превращают Cursor в полностью локальное решение и не снимают вопросы compliance. Они делают другое: переносят execution туда, где уже находятся закрытые repositories, private packages, legacy runtime и внутренние сервисы.

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

Главный вопрос внедрения теперь звучит не «какую модель купить разработчикам». Он звучит так: как встроить недетерминированный agent workload в корпоративную инфраструктуру, дать ему достаточный feedback loop и при этом не расширить права дальше необходимого?

Именно поэтому релиз 25 марта важен за пределами enterprise security. Agentic development становится инфраструктурной дисциплиной на пересечении Developer Experience, Platform Engineering и Security. Cursor self-hosted workers — один из первых наглядных признаков этого перехода.