Cursor IA na empresa: o que ligar antes de liberar o editor para o time

Quase tudo o que se publica em português sobre o Cursor fala com quem vai programar: como instalar, como pedir código ao agente, quais atalhos decorar. Faz sentido, porque é o desenvolvedor quem procura a ferramenta. Mas a decisão de colocá-la no computador da empresa costuma ser de outra pessoa, e essa pessoa tem outras perguntas: para onde vai o código, quem pode desligar a proteção e o que acontece com a senha do banco de dados que está num arquivo de configuração.

Este artigo responde a essas perguntas com o que a documentação oficial do Cursor diz hoje. Ele explica o que é a ferramenta e como ela trabalha por dentro, compara os planos pelo que cada um deixa a empresa controlar e termina num checklist de governança para cumprir antes de liberar o primeiro assento. Os preços citados foram conferidos na página oficial em 07/10/2026.

O que é o Cursor IA e por que liberar é uma decisão da empresa?

O Cursor é um editor de código com inteligência artificial integrada. Ele foi construído sobre a base do VS Code, então a aparência e boa parte das extensões são familiares para quem já usa o editor da Microsoft. A diferença está no que vem junto: um Agent que recebe uma tarefa em linguagem natural e edita vários arquivos, roda comandos e testa; um autocompletar (o Tab) que prevê a próxima edição; e o Inline Edit, que reescreve um trecho selecionado a pedido.

Para fazer isso, o Cursor precisa ler o código. E ler, aqui, significa enviar trechos do projeto para modelos de linguagem que rodam fora do computador da pessoa. É por isso que a pergunta deixa de ser de produtividade e passa a ser de governança: o código da empresa sai da máquina toda vez que alguém pede ajuda à IA. O que acontece com ele depois depende de configurações que, na maioria dos planos, não vêm prontas.

Isso não significa que a ferramenta seja insegura. Significa que a segurança dela é, em boa parte, uma escolha de configuração, e escolha que ninguém faz acaba sendo feita pelo padrão.

Como o Cursor funciona por dentro?

Vale separar as formas pelas quais o código chega até a IA, porque cada uma tem um controle diferente:

• Leitura direta pelo editor: o Agent, o Tab e o Inline Edit leem os arquivos abertos e os que julgam relevantes para a tarefa.
• Referências com @: no chat, a pessoa aponta um arquivo, uma pasta ou a documentação para entrar no contexto.
• Indexação do repositório: o Cursor indexa o projeto para encontrar o trecho certo quando a pergunta é vaga.
• Terminal: o Agent roda comandos (instalar pacote, rodar teste, listar arquivo) e lê o resultado.
• Servidores MCP: conectores que dão ao Agent acesso a sistemas externos, como banco de dados, gestor de tarefas ou documentação interna.
• Cloud agents: agentes que rodam na nuvem do Cursor, com uma cópia do repositório.

As três primeiras passam por controles do próprio editor. As duas seguintes, terminal e MCP, são ferramentas que o Agent aciona como qualquer programa acionaria, e é nelas que mora a surpresa que este artigo vai detalhar. Sobre a última, a documentação de privacidade informa que os cloud agents guardam cópias criptografadas do repositório temporariamente, enquanto o agente roda.

Quanto custa o Cursor e o que cada plano deixa a empresa controlar?

A página de preços organiza o Cursor em quatro planos. Para quem decide a compra, a coluna que importa não é a de recursos de IA, que mudam quase todo mês, e sim a de quem manda na configuração.

Cursor, página de preços, e documentação Privacy and Data Governance, consultadas em 07/10/2026.

Dois pontos da página merecem atenção de quem orça. Primeiro, todo plano inclui um volume de uso de modelos, e o consumo continua depois que ele acaba, cobrado depois (sob demanda). O preço do assento é o piso, não o teto, a mesma lógica que analisamos no artigo sobre o que o assento do GitHub Copilot não cobre. Segundo, a diferença entre Teams e Enterprise não é de inteligência artificial: é de controle.

O que o Privacy Mode muda nos dados do código?

O Privacy Mode é a chave que separa dois regimes de uso dos dados. A página oficial de uso de dados descreve os dois sem rodeio:

Para uma empresa, o primeiro regime é difícil de defender: código proprietário, regras de negócio e, às vezes, dados de cliente que aparecem em arquivos de teste podem virar insumo de melhoria de produto de um terceiro. Se a empresa tem contrato de confidencialidade com cliente, ou trata dados pessoais dentro do código, o Privacy Mode desligado pode contrariar o que ela mesma prometeu.

Há uma ressalva que a documentação de privacidade faz e que vale conhecer: a retenção zero cobre a maioria dos modelos, mas alguns modelos exigem retenção pelo provedor para revisões automáticas e humanas de prevenção de abuso. Nesses casos, segundo o Cursor, os dados não são usados para treino nem para melhoria de produto, mas ficam guardados por um período. Por isso a lista de modelos liberados também é decisão de governança, não só de preferência técnica.

Por que o Privacy Mode precisa ser forçado, e não só ligado?

Aqui está o ponto que os tutoriais não cobrem. Alguns dizem que o Privacy Mode protege o código e o recomendam para empresas, o que está certo. O que não dizem é em que plano ele já vem ligado.

Na prática, uma empresa no plano Teams tem três estados possíveis, e só um deles é seguro:

1. Desligado: ninguém mexeu no painel, e o time trabalha no regime em que os dados podem ser usados para treino.
2. Ligado, mas não forçado: o administrador ligou, mas qualquer membro pode desligar na própria conta, por curiosidade ou para testar um recurso.
3. Ligado e forçado: o membro não consegue desativar. É o único estado que a empresa pode afirmar a um cliente.

Existe ainda uma brecha fora do painel: a pessoa pode abrir o Cursor no computador da empresa com a conta pessoal, onde a configuração do time não vale. A documentação prevê isso: em computadores gerenciados por MDM, a política de IDs de time permitidos (Allowed Team IDs) impede o login com contas pessoais. Sem esse bloqueio, o Privacy Mode forçado protege só quem entrou pela porta certa.

O que o .cursorignore bloqueia e o que escapa dele?

O .cursorignore é um arquivo, na raiz do projeto, que lista caminhos que o Cursor não deve ler, com a mesma sintaxe do .gitignore. Em tutoriais, ele aparece quase sempre como ajuste de desempenho: excluir a pasta de dependências ou os arquivos de cache para a indexação ficar mais rápida. Ele faz isso, mas muita gente o trata também como barreira de segurança, e a documentação oficial avisa que essa barreira tem buracos.

O mecanismo é simples. O ignore impede que o Agent abra o arquivo pelas ferramentas de leitura do editor e que ele entre por @. Mas, se o Agent decidir rodar no terminal um comando que imprime o conteúdo do arquivo, ou se um servidor MCP consultar o sistema onde o dado está, a saída volta para o contexto do modelo. Ninguém precisa agir de má-fé: basta o agente tentar entender por que um teste falhou.

Vale registrar o que o Cursor já faz por padrão: a mesma documentação lista mais de uma centena de padrões ignorados automaticamente, incluindo arquivos de ambiente (.env*), arquivos de lock e pastas de controle de versão. É uma boa rede de proteção, sujeita aos mesmos dois limites: terminal e MCP.

Onde ficam os segredos se o ignore não segura?

A consequência prática do limite do .cursorignore é uma regra antiga de engenharia, que a IA tornou urgente: segredo não mora no repositório. Chave de API, senha de banco, certificado e token de integração devem sair da pasta do projeto, por três caminhos possíveis:

• Cofre de segredos (o serviço do provedor de nuvem ou uma ferramenta dedicada), com o código buscando o valor em tempo de execução.
• Variáveis de ambiente injetadas pelo servidor ou pela esteira de deploy, nunca gravadas num arquivo dentro do projeto.
• Credenciais de desenvolvimento separadas, com permissão mínima e apontando para bases de teste, de modo que um vazamento acidental não alcance dado real.

O mesmo raciocínio vale para os servidores MCP. Um MCP conectado ao banco de produção dá ao Agent a capacidade de ler o banco de produção, com ou sem ignore. Antes de liberar um conector, a pergunta é: se o Agent ler tudo o que este conector alcança, o que acontece? Se a resposta preocupa, o conector deve apontar para outra base ou ficar desligado.

Esse cuidado não é exclusivo do Cursor. No artigo sobre as permissões que a empresa define no Claude Code, mostramos a mesma lógica numa ferramenta de terminal: o que o agente pode executar importa tanto quanto o que ele pode ler.

O que só o plano Enterprise controla?

O Teams resolve o essencial (Privacy Mode forçado e login corporativo por SSO). O Enterprise acrescenta os controles que permitem à empresa limitar o próprio Agent, e não só os dados. Pela página de preços, eles são:

• Controle de acesso a repositório, modelo e MCP: define quais projetos podem ser abertos, quais modelos ficam disponíveis (inclusive para evitar os que exigem retenção) e quais servidores MCP podem ser conectados.
• Controles de auto-run, navegador e rede: limitam o que o Agent executa sem pedir confirmação e para onde ele pode se conectar.
• Logs de auditoria e contas de serviço: registram quem fez o quê, o que a empresa vai precisar no dia em que um cliente ou um auditor perguntar.
• Gestão de assentos via SCIM: quem sai da empresa perde o acesso junto com a conta corporativa, sem depender de alguém lembrar.
• Uso compartilhado (pooled usage) e cobrança por fatura, além de API de rastreamento de código gerado por IA.

A documentação de privacidade cita ainda chaves de criptografia gerenciadas pelo cliente (CMEK) para o Enterprise, além da criptografia padrão em trânsito (TLS 1.2+) e em repouso (AES-256) para todos. A pergunta de compra, então, não é "precisamos do Enterprise?", e sim "temos obrigação contratual ou regulatória de provar o que a ferramenta fez?". Se a resposta for sim, os logs de auditoria e o controle de MCP tendem a decidir sozinhos.

Do Hobby ao Enterprise, a IA do Cursor quase não muda. O que muda é quem decide sobre os dados.

E as certificações do Cursor resolvem a questão de segurança?

A ferramenta passa por auditoria externa: a página de segurança do Cursor informa certificações AIUC-1, ISO/IEC 27001:2022 e ISO/IEC 42001:2023 e atestação SOC 2 Type II, com relatórios disponíveis sob pedido. Para um questionário de fornecedor, isso responde boa parte das perguntas sobre o lado do Cursor.

O que a certificação não responde é o lado da empresa. Ela atesta os controles do fornecedor, não a configuração que o cliente deixou no padrão. O risco real está na combinação de Privacy Mode não forçado, conta pessoal liberada, segredo no repositório e MCP apontando para produção, e nenhuma dessas quatro coisas aparece num relatório SOC 2 do Cursor.

Checklist: o que ligar antes de liberar o primeiro assento

A ordem abaixo foi pensada para que nenhum desenvolvedor abra o Cursor antes de a configuração estar pronta. Leva uma tarde para um time pequeno.

1. Escolha o plano pelo controle, não pelo modelo

Para uso de empresa, o piso é o Teams. Hobby e Individual são contas pessoais: a empresa não tem painel, não força Privacy Mode e não retira o acesso de quem sai. Se houver exigência de auditoria ou de controle de MCP, avalie o Enterprise já na primeira conversa comercial.

2. Ligue e force o Privacy Mode

No painel do time, em configurações, ligue o Privacy Mode e marque a opção de forçá-lo para os membros. Depois faça o teste de dois minutos descrito acima com uma pessoa do time.

3. Feche a porta da conta pessoal

Ative o SSO para que o login corporativo seja o único caminho e, nos computadores gerenciados, aplique a política de times permitidos (Allowed Team IDs) via MDM. Sem isso, a conta pessoal continua aberta na mesma máquina.

4. Escreva o .cursorignore sabendo o limite dele

Liste no ignore o que não deve ser lido pelo editor: pastas de dados de exemplo, dumps de banco, documentos de cliente. E registre no próprio arquivo, num comentário, que ele não bloqueia terminal nem MCP, para que ninguém o trate como cofre.

5. Tire os segredos do repositório

Faça uma varredura por chaves e senhas no histórico do repositório, mova o que encontrar para um cofre ou para variáveis de ambiente injetadas e troque (rotacione) as credenciais que já estiveram expostas.

6. Defina a lista de MCP e de modelos permitidos

No Enterprise, isso é configuração. No Teams, é política escrita: quais conectores podem ser instalados, para quais bases eles apontam e quais modelos ficam fora por exigirem retenção.

7. Combine o teto de consumo

Como o uso continua depois do volume incluído, decida antes quem pode ultrapassá-lo e até quanto. Sem combinado, a primeira fatura define a política.

Quais os erros mais comuns ao liberar o Cursor para o time?

• Comprar assentos Individual para cada pessoa. Parece mais barato que o Teams, mas deixa a empresa sem painel, sem Privacy Mode forçado e sem controle de quem tem acesso.
• Ligar o Privacy Mode e não forçar. Ligado sem trava é preferência, não política.
• Tratar o .cursorignore como cofre. Ele organiza o que o editor lê; o Agent com terminal e MCP chega ao arquivo do mesmo jeito.
• Conectar MCP à base de produção para "facilitar o diagnóstico". O Agent passa a ler produção sempre que achar útil.
• Ignorar a conta pessoal. A configuração do time não vale para quem entra com o e-mail próprio na máquina da empresa.
• Escolher modelo só pela qualidade da resposta. Alguns exigem retenção pelo provedor; para código sensível, isso entra na conta.
• Medir sucesso pela quantidade de código gerado. Mais código não é entrega mais estável, como detalhamos no artigo sobre o que os dados da DORA mostram sobre IA e estabilidade.

O que muda por tipo de empresa?

Para agências e software houses, o ponto crítico é o MCP. Um mesmo desenvolvedor costuma atender vários clientes, e um conector configurado para o projeto de um cliente pode continuar ativo quando ele abre o projeto de outro. A política precisa dizer qual conector vale para qual projeto.

Por onde começar hoje?

1. Descubra quantas pessoas já usam o Cursor por conta própria, e com qual conta.
2. Escolha o plano pelo nível de controle que a empresa precisa provar, não pelo modelo de IA.
3. Ligue e force o Privacy Mode, ative o SSO e bloqueie contas pessoais nas máquinas gerenciadas.
4. Varra o repositório atrás de segredos, mova-os para fora e rotacione os expostos.
5. Escreva o .cursorignore e a política de MCP e modelos, deixando registrado o limite do ignore.
6. Libere para um grupo piloto, com teto de consumo combinado, e só depois para o time.

A ferramenta rende mais quando entra numa esteira que já tem revisão, testes e regras claras sobre dados. É assim que trabalha o desenvolvimento com IA da Alliance: a IA acelera o que o processo já garante. E se a dúvida for onde a IA renderia mais na operação como um todo, e não só no código, o diagnóstico gratuito de marketing mapeia a maturidade de cada área e aponta por onde começar.