Cursor leva agentes à sua infraestrutura — arquivos ainda podem sair
Em 2 de setembro de 2026, o Cursor passou a permitir que Cloud Agents executem ferramentas em máquinas administradas pelo cliente. Na mesma data, o anúncio da Cloudflare confirmou a integração com Sandboxes isolados dentro da conta do cliente.
O suporte não transforma o Cursor em um produto instalado integralmente na infraestrutura da empresa. Com Self-Hosted Machines, edições, comandos e operações de repositório rodam no worker escolhido, mas o loop do agente, a inferência e o planejamento continuam na nuvem do Cursor; conteúdos necessários ao modelo e determinados artefatos ainda podem atravessar a rede.
O worker executa; o Cursor mantém o loop do agente
A arquitetura divide a sessão entre um plano de execução e um plano de controle. O worker é uma máquina registrada no Cursor por meio da CLI e pode ser um computador de desenvolvimento, uma máquina virtual, um contêiner ou um nó iniciado sob demanda. É nele que o agente edita arquivos, executa o terminal, acessa repositórios e serviços internos e utiliza servidores MCP locais.
O Cursor continua recebendo a solicitação, conduzindo o planejamento e realizando as rodadas de inferência. As chamadas de ferramentas seguem para o worker por uma conexão HTTPS iniciada pela própria máquina; não é necessário abrir portas de entrada nem atribuir um endereço IP público ao worker.
“Autogerenciada”, portanto, descreve principalmente onde as ferramentas produzem efeitos. Não significa que o modelo, o planejamento ou toda a informação usada durante a sessão tenham sido deslocados para dentro da rede do cliente.
O que permanece local e o que pode ser transmitido
O checkout completo, o cache de build e as credenciais armazenadas na máquina permanecem no worker. Isso permite que comandos sejam executados perto de repositórios privados, registries, serviços internos ou hardware específico, sem que o Cursor tenha de operar essa máquina.
A fronteira muda quando o agente precisa interpretar o resultado do trabalho. A documentação técnica do Cursor informa que conteúdo de arquivos, saídas do terminal, diffs, capturas de tela, resultados de MCP e metadados de roteamento podem ser enviados ao serviço durante uma execução. Se o compartilhamento de desktop for ativado, a área de trabalho do agente também é transmitida.
Há ainda os artefatos do Cloud Agent, entre eles capturas, vídeos e referências de logs. O worker pode enviá-los ao armazenamento administrado pelo Cursor para que apareçam em pull requests e no painel. Bloquear o endpoint dedicado impede esse upload sem interromper as chamadas de ferramentas, mas os artefatos deixam de aparecer nesses destinos.
A mesma distinção vale para segredos. Credenciais mantidas no worker não são automaticamente transferidas como um cofre remoto, mas um segredo exposto em uma saída de terminal, captura ou outro resultado devolvido ao agente pode sair da rede. O Privacy Mode impede que código enviado seja usado para treinamento pelo Cursor ou pelos provedores de modelos; ele não elimina a transmissão necessária para inferência e coordenação.
Pools dinâmicos aproximam os agentes da infraestrutura existente
O produto oferece dois arranjos. My Machines conecta uma máquina à conta para fluxos individuais e admite vários agentes no mesmo equipamento. Team Pools cria destinos compartilhados: uma conversa aguarda até que um worker disponível assuma a sessão, e cada worker do pool atende um agente por vez.
O changelog de Self-Hosted Machines registra que a capacidade pode crescer com a chegada de solicitações e diminuir quando workers se desconectam. Máquinas ociosas também podem hibernar e retornar dentro de uma janela de reconexão quando a conversa é retomada. Entre as infraestruturas citadas estão AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel e E2B.
A elasticidade depende de componentes controlados pela organização. O cliente continua responsável pela imagem do worker, pela infraestrutura, pelos segredos, pela política de escala e pela validação do ambiente de produção. Um controlador pode observar a demanda e iniciar ou liberar capacidade, mas esse controlador também roda sob responsabilidade do cliente.
A fronteira ficou controlável, não fechada
Para equipes de plataforma, a mudança permite aplicar controles próprios ao sistema operacional, à rede, às credenciais e ao ciclo de vida das máquinas que executam comandos. Também reduz a necessidade de expor serviços internos a um ambiente de execução operado pelo Cursor.
O desenho continua híbrido. A empresa controla onde alterações em arquivos, builds e acessos à rede acontecem, enquanto o Cursor preserva a coordenação da sessão e o acesso aos modelos. Por isso, filtros de saída, regras para capturas, revisão dos resultados de ferramentas e inspeção do tráfego continuam relevantes.
O suporte a Self-Hosted Machines e a integração com ambientes como Cloudflare Sandboxes estão disponíveis, mas isolamento total não faz parte da arquitetura descrita. A decisão pendente para cada organização é quais conteúdos podem entrar no contexto do modelo e quais artefatos podem deixar o worker sem contrariar suas políticas de segurança e retenção.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.