AIREITERUm worker pode estar protegido pelo seu firewall e, ainda assim, enviar trechos de código-fonte, saídas do terminal, diffs e capturas de tela para o Cursor. O Cursor Self-Hosted Machines oferece execução self-hosted, não um agente self-hosted nem uma implantação do Cursor isolada da rede.
Esta análise mostra o que atravessa essa fronteira e o que os controles realmente alteram, com base no anúncio de 2 de setembro de 2026, na documentação do Self-Hosted Machines e na política de uso de dados do Cursor.
A fronteira de dados, resumida em uma tabela
O Cursor divide uma execução do Cloud Agent entre a nuvem e um worker gerenciado por você. “Self-hosted” descreve onde a execução acontece, não todos os sistemas nem todos os caminhos percorridos pelos dados.
| Dados ou sistema | Onde é executado ou armazenado | Pode chegar ao Cursor? | Controle ou limitação relevante |
|---|---|---|---|
| Loop do agente, inferência e planejamento | Nuvem do Cursor | Já está no Cursor | Não é movido pelo Self-Hosted Machines. |
| Edições de arquivos e comandos do terminal | Seu worker | Os resultados podem ser enviados de volta | O worker executa as ferramentas. |
| Checkout completo e cache de build | Seu worker | Não são transferidos por padrão | A cópia completa do projeto permanece local. |
| Credenciais locais da máquina | Seu worker | Não são transferidas por padrão | Mantenha segredos fora de comandos, saídas e artefatos. |
| Conteúdo de arquivos e diffs | Seu worker e, depois, o contexto/resultados do agente | Sim, quando necessário | O Privacy Mode trata do uso em treinamento, não da transferência. |
| Saída do terminal e resultados do MCP local | Seu worker e, depois, os resultados das ferramentas | Sim, quando retornados | Os resultados podem conter código ou dados sensíveis. |
| Capturas de tela e transmissão da área de trabalho | Seu worker e, depois, o Cursor quando produzidos/compartilhados | Sim | Sessões de uso do computador podem transmitir a área de trabalho do agente. |
| Vídeos, capturas de tela e referências a logs | Armazenamento de artefatos gerenciado pelo Cursor | Sim, por padrão | Bloqueie o host de artefatos para desativar os uploads. |
| Solicitações de modelo usando chave de API | Caminho de processamento do Cursor | Sim | BYOK não contorna o backend do Cursor. |
A distinção importante é simples: o repositório inteiro pode permanecer na sua máquina enquanto partes selecionadas do contexto ainda atravessam a rede para a inferência. Isso é controle parcial da execução, não uma garantia de ausência de tráfego de saída.
O que o Cursor realmente move para a sua infraestrutura
O Self-Hosted Machines transfere a execução das ferramentas para uma máquina controlada pelo cliente. O worker pode editar arquivos, executar comandos, acessar serviços internos, operar um navegador e se conectar a servidores MCP locais. O Cursor mantém na nuvem o loop do agente, a inferência, o planejamento e a orquestração das sessões.
O worker é iniciado com o comando da CLI do Cursor agent worker start. Ele abre uma conexão HTTPS de saída persistente com o Cursor. Segundo o Cursor, essa conexão parte do worker: não é necessário abrir uma porta de entrada, ter um endereço IP público ou configurar um túnel VPN.
O fluxo de sessão documentado é o seguinte:
- Uma sessão do Cloud Agent é iniciada na interface do Cursor.
- O loop do agente na nuvem do Cursor planeja a próxima ação.
- O Cursor envia uma chamada de ferramenta pela conexão com o worker.
- O worker executa o comando, a edição, a ação no navegador ou a operação MCP.
- O worker devolve o resultado para a próxima etapa de inferência.
O worker ainda precisa de acesso de saída a api2.cursor.sh e api2direct.cursor.sh; atualizações da CLI e parte da configuração do uso do computador também podem exigir downloads.cursor.com. O modelo baseado apenas em conexões de saída evita o acesso de entrada à sua rede, mas não transforma o worker em um ambiente offline para execução de modelos.
O Cursor apresenta essa divisão como uma opção para repositórios ou serviços privados que os workers hospedados não conseguem acessar, hardware especializado como GPUs ou Macs e sistemas operacionais ou imagens de build personalizados. Se o único requisito for conectividade privada, o guia de escolha de runtime do Cursor recomenda considerar primeiro os Cloud Agents gerenciados com listas de permissões, redes semelhantes ao Tailscale, AWS PrivateLink ou Cloudflare Tunnel.
O que pode sair do worker — e o que o Privacy Mode muda
A documentação do Cursor lista explicitamente conteúdo de arquivos, saída do terminal, diffs, capturas de tela, resultados do MCP local e metadados de roteamento como dados que o worker pode enviar. A questão da privacidade tem três partes distintas: o que é transferido, se isso é usado para treinamento e por quanto tempo é retido.
O Privacy Mode controla o treinamento, não o tráfego de saída
A visão geral de uso de dados e privacidade do Cursor, atualizada em 28 de agosto de 2026, diz que o Privacy Mode impede que os Dados do Cliente sejam usados para treinamento pelo Cursor e afirma que a empresa mantém acordos de retenção zero de dados com seus provedores. A mesma página faz uma ressalva: classificadores de risco podem reter prompts ou conversas para investigação, e pode haver cache temporário de arquivos por motivos de latência e eficiência de rede.
O Cursor descreve os arquivos em cache como criptografados com chaves geradas pelo cliente, mantidas nos servidores do Cursor durante a solicitação. Essa é uma afirmação do Cursor sobre retenção e proteção; não é uma evidência de que a solicitação nunca chegue aos servidores da empresa.
O detalhe da chave de API também importa. O Cursor afirma que usar sua própria chave de API de um provedor não contorna o backend da empresa, porque as solicitações continuam passando pelo Cursor para a montagem final do prompt. O BYOK pode mudar quem autoriza o uso do modelo, mas não deve ser tratado como um caminho direto e privado entre o cliente e o provedor.
Um usuário fez a mesma distinção arquitetural ao analisar o recurso:
“Limite importante: as máquinas self-hosted do Cursor movem a execução, não o agente inteiro. O Cursor diz que a inferência e o planejamento permanecem na nuvem; as saídas das ferramentas retornam e podem conter código. Em uma análise de segurança, trate isso como execução self-hosted — não como um agente self-hosted.” — @ham_zax, X
O bloqueio de artefatos não cria um air gap
O Cursor documenta uma forma específica de interromper uploads de artefatos: bloquear o tráfego HTTPS de saída para cloud-agent-artifacts.s3.us-east-1.amazonaws.com. As chamadas e os resultados das ferramentas continuam funcionando, mas capturas de tela, vídeos e referências a logs não aparecerão em pull requests nem no dashboard do Cursor.
Isso é útil quando a organização não precisa de artefatos visuais. Não é uma solução completa de privacidade, porque conteúdos de arquivos, saída do terminal, diffs, capturas usadas durante a inferência e resultados do MCP ainda podem ser devolvidos pela conexão da sessão do agente.
O transporte do MCP cria outra distinção prática. A documentação do Team Pools do Cursor diz que servidores MCP baseados em comandos, ou stdio, são executados no worker e podem acessar redes privadas. Servidores MCP HTTP/SSE são tratados pelo backend do Cursor para OAuth, cache de sessão e autenticação. Portanto, um endpoint MCP privado precisa ser analisado também pelo tipo de transporte, não apenas pelo local onde o host está.
Escolha o runtime pelo requisito, não pelo rótulo
O Cursor oferece três opções de runtime. O self-hosting faz sentido quando o limite de execução, o hardware ou o ambiente são requisitos documentados, e não apenas uma preferência.
| Runtime | Onde as chamadas de ferramentas são executadas | Mais indicado para | Principal responsabilidade |
|---|---|---|---|
| Cloud Agents gerenciados pelo Cursor | VM isolada gerenciada pelo Cursor | A maioria das equipes que pode usar redes gerenciadas e ambientes padrão baseados em Ubuntu | O Cursor gerencia o ciclo de vida da VM, a capacidade, o isolamento e a destruição após a configuração do seu ambiente. |
| My Machines | Notebook, devbox, Mac ou VM de um usuário | Fluxo de trabalho pessoal, repositório com estado local ou prova de conceito rápida | Você gerencia disponibilidade, credenciais, dependências, limpeza e o checkout. |
| Team Pools | Workers gerenciados pela organização | Frotas empresariais, GPUs, Macs, Kubernetes, roteamento por etiquetas e capacidade centralizada | Sua equipe gerencia hosts, imagens, segredos, escalabilidade, monitoramento, resets e falhas. |
Escolha Cloud Agents gerenciados quando o único requisito for acesso privado
Os Cloud Agents gerenciados podem ser suficientes se a organização conseguir definir sua fronteira por meio de permissões de repositório, listas de permissões de rede, um cliente semelhante ao Tailscale ou conectividade privada compatível. O guia de runtime do Cursor recomenda a infraestrutura gerenciada para a maioria das equipes e a descreve como o caminho com menos operações.
Isso evita operar uma frota de workers e mantém o ciclo de vida gerenciado das VMs e a concorrência elástica do Cursor. Não significa que agentes gerenciados não movimentem dados; significa que o ambiente de execução é operado pelo Cursor, e não pela sua equipe.
Escolha My Machines para um usuário e um ambiente controlado
O My Machines conecta uma máquina pessoal a uma conta individual do Cursor. É uma opção prática quando o desenvolvedor já tem um Mac, devbox ou VM remota configurada, com dependências locais e acesso à rede que seria trabalhoso reproduzir em outro lugar.
O custo está na operação. A máquina precisa permanecer online durante as sessões ativas, e o usuário fica responsável pela limpeza, atualização do checkout, estado do disco, credenciais e reparo das dependências. A documentação de self-hosting do Cursor diz que vários agentes podem rodar na mesma máquina, mas esse não é o modelo de uma frota centralizada para equipes.
Escolha Team Pools apenas quando o controle da frota compensar a complexidade
O Team Pools é voltado para equipes Enterprise. Ele usa autenticação por conta de serviço, capacidade compartilhada de workers, etiquetas e escalabilidade baseada em controladores. Um pool gpu pode encaminhar tarefas para máquinas com GPU; um pool ios pode encaminhá-las para Macs. O Cursor documenta até 200 workers por usuário e 1.000 workers por equipe, enquanto implantações maiores exigem uma conversa sobre escalabilidade.
Os pools podem escalar até zero e usar workers persistentes, conteinerizados, baseados em Kubernetes ou hospedados por parceiros. O Cursor afirma que restaurar um workspace liberado pode levar vários minutos. A flexibilidade é útil para tarefas com picos de demanda, mas o gerenciamento de imagens, resets dos workers, planejamento de capacidade, rotação de segredos e monitoramento passam a ser responsabilidade do cliente.
O custo combina infraestrutura e uso de modelos
A documentação do Self-Hosted Machines e a página Cursor Models & Pricing descrevem as responsabilidades relacionadas a modelos, planos e infraestrutura, mas não listam uma tarifa separada do Self-Hosted Machines por worker. O modelo de custo informado é: você continua pagando pelo modelo escolhido através do Cursor e, além disso, paga pela máquina, pelo contêiner, pelo cluster, pelo armazenamento, pela rede, pelo monitoramento e pelas operações que executar.
Por isso, o self-hosting é um argumento fraco para economizar quando não existe uma exigência específica de rede ou hardware. Pools dinâmicos e hibernação podem reduzir o custo computacional ocioso, mas o ponto de equilíbrio depende do perfil da carga, do tempo de inicialização e da quantidade de estado que precisa ser reconstruída; o Cursor não publica um número universal.
Checklist de segurança antes de ativar o recurso
Use esta lista com a pessoa responsável por segurança, plataforma ou compliance, em vez de tratar a expressão “self-hosted” como sinal automático de aprovação.
- Defina o requisito de fronteira com precisão. Determine se a política exige que o checkout completo, a execução das ferramentas, as credenciais, as solicitações de inferência, os artefatos ou todos esses elementos permaneçam dentro do perímetro. O Self-Hosted Machines coloca sob seu controle apenas o worker de execução e o estado local completo.
- Classifique o contexto devolvido. Conteúdo de arquivos, diffs, saída do terminal, capturas de tela e resultados do MCP podem ser enviados ao Cursor. Verifique se essas saídas podem conter código-fonte, dados de clientes, tokens, URLs internas ou respostas de produção.
- Ative o Privacy Mode de forma consciente. Ele altera a política declarada pelo Cursor para uso em treinamento e retenção pelos provedores; não impede o processamento das solicitações, o cache temporário nem o tratamento por detecção de risco.
- Entenda corretamente o BYOK. Segundo a página de uso de dados do Cursor, uma chave de API não remove o backend do Cursor do caminho da solicitação.
- Decida separadamente sobre a saída de artefatos. Permita ou bloqueie
cloud-agent-artifacts.s3.us-east-1.amazonaws.comconforme a aceitabilidade de capturas de tela, vídeos e referências a logs em PRs e no dashboard. Quando o firewall permitir, prefira uma regra específica para esse host. - Use uma lista de permissões apenas para conexões de saída. Libere somente os endpoints documentados do Cursor e os hosts de atualização ou uso do computador que forem habilitados intencionalmente. O worker não deve precisar de porta de entrada nem de IP público.
- Revise o transporte do MCP. Use MCP stdio no worker quando um servidor precisar acessar um serviço privado e avalie os resultados retornados. Não presuma que um endpoint MCP HTTP/SSE permaneça dentro da sua rede apenas porque o serviço é privado.
- Isole e redefina os workers. Para Team Pools, defina como as máquinas serão apagadas ou recriadas entre agentes, como as credenciais serão injetadas e como os logs serão monitorados. Os guias e templates do Cursor são arquiteturas de referência, não uma frota de produção totalmente gerenciada.
- Teste o caminho de falha. Confirme o que acontece quando os endpoints do Cursor, o armazenamento de artefatos, o worker, um registro privado ou um servidor MCP ficam indisponíveis. Um host de artefatos bloqueado não deve ser confundido com uma sessão do agente bloqueada.
- Rejeite a opção para cargas air-gapped. Se o requisito for impedir qualquer transferência externa do contexto do modelo ou não usar inferência em uma nuvem de terceiros, esta arquitetura não atende. O loop do agente continua na nuvem do Cursor.
| Seu requisito real | Decisão |
|---|---|
| Comandos, estado local ou hardware personalizado precisam ser executados no seu ambiente | Use o Self-Hosted Machines, com controles para a saída de contexto e artefatos. |
| Os agentes precisam acessar serviços privados, mas a execução pode ocorrer em uma VM gerenciada | Comece pelos Cloud Agents gerenciados e pela conectividade privada compatível. |
| Nenhum contexto do modelo pode sair da rede ou a inferência precisa ser offline | Rejeite esta arquitetura; ela ainda depende da nuvem do Cursor. |
FAQ de privacidade do Cursor Self-Hosted Machines
O Cursor Self-Hosted Machines é totalmente self-hosted?
Não. O Cursor mantém na nuvem o loop do agente, a inferência, o planejamento e a orquestração. Sua máquina hospeda a execução das ferramentas e o estado de trabalho local.
O código-fonte sai da máquina self-hosted?
Conteúdos selecionados de arquivos, diffs, saída do terminal, capturas de tela e resultados do MCP local podem sair do worker como entradas ou resultados de ferramentas do agente. O Cursor afirma que o checkout completo e o cache de build permanecem no worker, portanto a fronteira é parcial, e não uma questão de tudo ou nada.
O Privacy Mode impede que os dados atravessem a rede?
Não. O Privacy Mode é descrito como um mecanismo que impede o uso dos dados em treinamentos pelo Cursor e pelos provedores de modelos, conforme os acordos de retenção declarados pelo Cursor. Ele não impede que o worker envie o contexto necessário para a inferência.
O BYOK contorna o Cursor?
Não. A página de uso de dados do Cursor afirma que as solicitações feitas com chave de API ainda passam pelo backend da empresa para a montagem final do prompt. O BYOK não deve ser tratado como uma conexão direta entre o seu worker e um provedor de modelos.
Posso impedir o upload de capturas de tela e vídeos?
Você pode bloquear o acesso de saída a cloud-agent-artifacts.s3.us-east-1.amazonaws.com. A execução das ferramentas continua, mas os artefatos não aparecerão em pull requests nem no dashboard do Cursor. Outros dados da sessão do agente ainda podem ser enviados ao Cursor.
O worker precisa de uma regra de firewall de entrada ou de uma VPN?
O Cursor documenta um modelo baseado em conexões de saída via HTTPS. A empresa afirma que não são necessários uma porta de entrada, um IP público ou um túnel VPN, embora o worker ainda precise de acesso de saída aos endpoints documentados do Cursor e a quaisquer serviços que precise utilizar.
Posso usar Team Pools em um plano pessoal ou de categoria inferior?
A documentação do Cursor posiciona o Team Pools para clientes Enterprise e exige uma chave de API de conta de serviço. O My Machines é a opção de worker pessoal; não presuma que uma chave de API pessoal possa iniciar um worker do Team Pool.
Posso executar o Cursor Self-Hosted Machines completamente offline?
Não. O loop do agente e a inferência permanecem na nuvem do Cursor, e o worker exige uma conexão de saída. Um requisito offline ou air-gapped demanda outra arquitetura, com orquestração e inferência de modelos hospedadas localmente.
Use o Cursor Self-Hosted Machines quando sua equipe precisar de execução controlada pelo cliente, acesso a redes privadas, hardware personalizado ou um ambiente persistente. Se o requisito for manter o tráfego de IA fora da nuvem, escolha outra arquitetura: este recurso muda onde os comandos são executados, não onde o agente pensa.