O Cursor AI é seguro? O editor, o código e o app que você publicou

Você construiu algo no Cursor, funciona, e está prestes a colocar pessoas de verdade nele. Em algum momento dessa semana você digitou «o cursor ai é seguro» em um buscador, e o que voltou foi uma página sobre as configurações de privacidade do Cursor, uma página sobre se código escrito por IA presta, e uma página sobre um download de cursores de mouse personalizados. Nenhuma delas disse uma palavra sobre o app que você está prestes a publicar.

Aqui está a parte que a maioria dessas respostas erra: «o Cursor AI é seguro?» são três perguntas em uma frase só, e elas têm três respostas diferentes. Duas são sobre o Cursor e os modelos por trás dele. A terceira é sobre o que você publicou, e é a que decide se um estranho consegue ler os dados dos seus usuários.

Pense no Cursor como um empreiteiro que você contratou para construir uma casa. Se ele guarda uma cópia das suas plantas é uma pergunta. Se o que ele constrói está dentro das normas é uma segunda. Se as portas trancam depois que você se mudou é a terceira, e ela continua sendo sua pergunta enquanto você morar ali.

O Cursor AI é seguro?

Como editor, é uma ferramenta em nuvem comum: um interruptor de privacidade, uma página de segurança publicada e uma atestação SOC 2 Tipo II. Isso responde uma das três perguntas, e não a que decide se estranhos conseguem ler os dados dos seus usuários.

1. O editor. Se o Cursor guarda seu código, treina com ele ou passa para outra pessoa. Essa é a cópia das plantas com o empreiteiro.
2. O código. Se o que a IA escreve é seguro. Essa é a pergunta se a casa está dentro das normas, e ninguém inspeciona isso na entrada.
3. O app que você publicou. O que um estranho alcança da rua: uma chave no código que um navegador baixa, um banco de dados que responde sem login, um arquivo que nunca deveria ter tido uma URL. Essas são as portas.

Nada do lado do Cursor consegue responder a terceira. Nada do nosso consegue responder as duas primeiras.

O Cursor guarda meu código?

Pelo tempo que leva para responder você, sim. Depois disso depende de um interruptor.

O Cursor é uma ferramenta em nuvem. Quando você pergunta qualquer coisa a ele, as partes relevantes do seu projeto saem do seu computador, vão para os servidores do Cursor e são repassadas a um provedor de modelos (OpenAI, Anthropic, Google, o modelo que você escolheu) para serem respondidas. É assim que o produto funciona. As plantas precisam chegar ao empreiteiro.

O que acontece depois é o interruptor, e a página de uso de dados do Cursor coloca as duas posições em um parágrafo só. Com o Privacy Mode ligado, «os Dados do Cliente não serão usados para treinamento pelo Cursor» e o Cursor «mantém acordos de retenção zero de dados (ZDR) com todos os provedores», ou seja, as empresas que rodam os modelos se comprometem a não guardar nada também. Com ele desligado, o Cursor «pode usar e armazenar dados da base de código, prompts, ações no editor, trechos de código e outros dados e ações de código para melhorar nossos recursos de IA e treinar nossos modelos».

O interruptor está disponível em todos os planos, o gratuito incluído, e um administrador de equipe ou de empresa pode ligá-lo para todo mundo e impedir que os membros o desliguem. O próprio guia de hardening do Cursor diz que ele vem ligado por padrão em contas Enterprise. Em um plano individual é uma configuração, e essa configuração vale a pena procurar hoje.

Mais uma coisa sobre ele, porque já pegou alguém de surpresa. Desde meados de 2025 existem duas versões: «Privacy Mode», que deixa o Cursor guardar alguns dados para recursos como os agentes em nuvem e as memórias, e «Privacy Mode (Legacy)», que não guarda nada. Em julho de 2026 um usuário do Hacker News contou que entrou no app de iOS e encontrou a conta movida da configuração antiga para a atual. Um funcionário do Cursor respondeu que o aviso para ativar os agentes em nuvem tinha feito isso «sem deixar claro o que significava nem que é difícil de desfazer», e que voltar atrás não estava disponível no app. Se você escolheu a mais rígida, confira se ela ainda está selecionada.

Os certificados respondem a uma pergunta mais estreita do que parecem. A página de segurança do Cursor lista uma atestação SOC 2 Tipo II, ISO/IEC 27001 e ISO/IEC 42001. Eles significam que um auditor externo verificou que o Cursor tem controles sobre como trata os dados que guarda, do mesmo jeito que o certificado de seguro de um empreiteiro diz que o empreiteiro está segurado. Eles não dizem nada sobre o código que ele escreve nem sobre o app que você publica com ele.

O que a indexação do código envia?

Um índice do seu projeto, guardado nos servidores do Cursor, com os caminhos dos arquivos criptografados e o código em si nunca guardado como texto legível.

A indexação é como o Cursor responde uma pergunta sobre o projeto inteiro e não só sobre o arquivo que você tem aberto. Ele divide seus arquivos em pedaços, envia para os servidores do Cursor para virarem embeddings (um resumo numérico do assunto de cada pedaço) e guarda esses embeddings para que, quando você perguntar «onde tratamos os reembolsos», ele ache os pedaços certos. A documentação do Cursor diz: «Os caminhos dos arquivos são criptografados antes de serem enviados aos servidores do Cursor. O conteúdo do código nunca é armazenado em texto puro». O que fica do lado deles é um mapa do seu código, e isso é uma coisa diferente de uma cópia.

Duas coisas valem a pena saber sobre o mapa.

Alguns arquivos ficam de fora por padrão, e você pode acrescentar mais. O Cursor pula tudo que está no seu .gitignore e uma lista padrão que inclui .env*, o arquivo onde suas chaves secretas costumam morar. Um arquivo .cursorignore na raiz do projeto, escrito na mesma sintaxe do .gitignore, deixa qualquer outra coisa que você nomear fora do índice e fora do que é mostrado à IA.

O terminal do agente não lê essa lista. Essa é a ressalva que importa para as chaves. A página sobre arquivos de exclusão do Cursor diz que «as ferramentas de terminal e de servidor MCP usadas pelo Agente não conseguem bloquear o acesso ao código regido pelo .cursorignore», e que «a proteção completa não é garantida devido à imprevisibilidade dos LLMs». Quando o agente executa um comando na sua máquina, ele consegue ler o .env como qualquer comando conseguiria. O arquivo está fora do índice e continua ao alcance. Se uma chave está na pasta de projeto que você abriu no Cursor, trate-a como uma chave que o agente consegue ver.

O código que o Cursor escreve é seguro?

Não por padrão, e isso está medido, embora a medição seja dos modelos que o Cursor usa e não do Cursor em si.

A Veracode, uma empresa que vende testes de segurança de código, passou mais de 150 modelos pelas mesmas 80 tarefas de programação, em quatro linguagens, cada tarefa com um jeito seguro e um inseguro de fazer o trabalho. A atualização de primavera de 2026 dela, publicada em 24 de março de 2026, descobriu que só 55% dos resultados eram seguros, um número que a Veracode chama de «praticamente idêntico ao de dois anos atrás», enquanto a parcela que compilava já tinha passado de 95%. Em dois dos quatro tipos de falha os modelos quase nunca escolheram a versão segura: o cross-site scripting, que deixa o texto de um visitante rodar como código no navegador de outro, passou 15% das vezes, e a injeção de log, 13%.

O resumo da própria Veracode é que os modelos «ficaram excelentes em escrever código que compila. Falharam em escrever código que é seguro».

Para você, a pessoa que não escreveu o código, a lacuna entre esses dois números é o achado inteiro. O teste que você faz em um projeto do Cursor é se ele funciona: você clica pelo app e as coisas certas aparecem. Esses são os 95%. O teste que ninguém faz é se o código decidiu quem pode ver o quê, e os 55% dizem que essa decisão foi tomada mais ou menos metade das vezes. Um app pode passar por completo no primeiro teste e reprovar no segundo, porque uma página que mostra a você os seus pedidos e uma página que mostra a qualquer um os pedidos de todo mundo parecem idênticas para a pessoa dona da conta.

Onde essa decisão pertence, e por que «carregue os pedidos» nunca a toma sozinho, está no meio do guia do Cursor.

Injeção de prompt, em linguagem simples

O modelo trata instruções como instruções onde quer que as encontre, inclusive dentro de coisas que ele só deveria ler.

Você diz ao Cursor «resuma esta thread» ou «organize este arquivo», e para isso ele lê a thread ou o arquivo. Se a thread contém uma frase escrita para parecer uma instrução a uma IA, o modelo pode segui-la, porque não tem um jeito confiável de distinguir a sua voz da voz da página. Isso é injeção de prompt, e em um agente de programação, que consegue editar arquivos e executar comandos na sua máquina, as consequências vão além de um resumo ruim.

Dois casos com nome, ambos contra o Cursor. Em março de 2025 a Pillar Security publicou o «Rules File Backdoor»: instruções escondidas com caracteres Unicode invisíveis dentro de um arquivo .cursor/rules, o arquivo de configuração que diz ao Cursor como você quer seu código escrito. O arquivo parecia limpo no editor e em um diff do GitHub, e mandava a IA, em silêncio, adicionar a cada página gerada um script do domínio de um atacante e nunca mencionar isso. A resposta do Cursor foi que aquilo não era uma vulnerabilidade da plataforma dele e que a responsabilidade é do usuário. Em agosto de 2025 a Aim Security divulgou a CVE-2025-54135, que eles chamaram de CurXecute: uma mensagem em um canal público do Slack, lida pelo Cursor por meio de um servidor MCP (um plug-in que deixa o agente alcançar ferramentas externas), conseguia fazer o agente escrever uma entrada na própria configuração mcp.json dele, e o Cursor iniciava essa entrada, executando o comando do atacante, antes de você ter aprovado a edição. O Cursor corrigiu na versão 1.3, em 29 de julho de 2025, e agora toda alteração nesse arquivo espera a sua aprovação.

O que sobra para você é curto. Um arquivo de regras que você copiou de um repositório ou de um post é código, e ele guia tudo que o agente escreve depois, então leia como código. Mantenha o Cursor atualizado, já que a correção do CurXecute foi um número de versão. E todo servidor MCP que você conecta e que lê texto de fora, uma caixa de entrada, uma fila de tickets, uma busca, entrega ao agente frases que você não escreveu.

O que um escaneamento de 30.998 apps no ar diz sobre a terceira pergunta

Que nada do editor chega ao app que você publicou. Não conseguimos distinguir de fora um app feito no Cursor de qualquer outro, e o achado é esse.

Entre 12 e 14 de agosto de 2026, passamos as nove verificações externas que qualquer um pode rodar de graça na nossa página inicial por 30.998 apps no ar. Nós os encontramos por onde estavam publicados: 18.554 no domínio do Lovable, 5.438 no do Base44, 3.042 no do Replit, e assim por diante. Um projeto do Cursor é implantado onde você o colocar, na Vercel, na Netlify, em um domínio que você comprou, e a página que um visitante baixa não carrega marca nenhuma do editor que a escreveu. Então não existe uma coluna do Cursor no relatório, e não pode existir.

O que existe, em cada builder que medimos, é a mesma lista curta de coisas que um dono deixou abertas, e nenhuma delas é decidida pelo editor. Cada parcela abaixo é sobre os apps em que aquela verificação respondeu, porque uma verificação que não conseguiu terminar é desconhecida e não aprovada. Nenhum app é nomeado aqui nem em qualquer outro lugar que publicamos.

A primeira linha é medida sobre os 3.680 apps que nomearam um projeto Supabase e cujo banco de dados respondeu à pergunta, por isso a base dela é menor; o que essa verificação lê e o que não lê tem a escada completa. A quinta linha é a que custa dinheiro sozinha: uma chave secreta da OpenAI, Anthropic, AWS ou Stripe, ou uma chave service_role do Supabase, no código que um navegador baixa.

A última coluna é o que muda no Cursor. No domínio próprio de um builder, duas dessas linhas pertencem ao host: os cabeçalhos são enviados pelo que serve a página, e os source maps seguem as configurações de build do builder. Um projeto do Cursor é o seu repositório, o seu build e o seu deploy, então cada linha dessa tabela é sua, inclusive as duas que um dono de app no Lovable não controla. Isso é mais controle e mais coisa para verificar, e é por isso que o guia do Cursor gasta seu tempo na saída do seu build e no seu banco de dados em vez de no editor. O post sobre o Replit faz as mesmas três perguntas a uma plataforma que hospeda o app e, ao mesmo tempo, deixa você publicar um servidor seu.

A verificação de cinco minutos de fora

Use uma janela anônima para as três primeiras, para que o seu próprio login não responda por um estranho.

1. Abra seu endereço publicado com /.env no final, depois com /.git/config. Os dois devem falhar. Se algum mostrar texto, rotacione hoje cada chave que estiver nele, depois conserte o deploy para que esse arquivo nunca seja servido.
2. Abra do mesmo jeito uma das suas próprias rotas de API, uma que você não gostaria que um estranho lesse. Se ela responder com dados, essa rota precisa de uma verificação de login.
3. Abra seu app no ar e depois a aba Sources das ferramentas de desenvolvedor do navegador. Se você consegue ler seus arquivos originais com os comentários, os source maps estão ligados no seu build de produção.
4. Se seus dados estão no Supabase, a metade de dentro da verificação está no guia do Cursor: procure service_role e sk_live_ na saída do build, depois abra a página de políticas.
5. Ou deixe o escaneamento fazer isso. Ele roda essas e o resto das nove de fora, leva uns 20 segundos, não precisa de conta e imprime «Não foi possível verificar» para tudo que não conseguiu responder, em vez de um sinal de certo: escaneie seu app.

O que muda depois do próximo push?

Qualquer coisa. Um projeto do Cursor vai ao ar quando você faz push, e nada entre o seu editor e a internet relê o app procurando uma rota que perdeu a verificação de login, uma chave colada à meia-noite para passar por um build que estava falhando, ou um source map que voltou a ficar ligado com uma mudança de configuração. O número da Veracode é o motivo de isso importar mais aqui do que em um builder: cada sessão com o agente é código novo que compila e pode não ser seguro, e um escaneamento que você rodou mês passado descreve o app do mês passado.

O Reeve Monitor foi feito para isso. Ele roda de novo todas as nove verificações a cada hora em até três apps, vigia a disponibilidade a cada 60 segundos, avisa você quando um resultado muda em vez de esperar você olhar, e envia um relatório mensal. Custa $12 por mês no preço de lista, com sete dias grátis antes de cobrar; a página de preços às vezes fica abaixo do valor daqui e nunca acima. O Monitor vigia e nada mais. Se o seu app do Cursor guarda os dados no Supabase, o Care é o plano que também mantém uma cópia desse banco de dados, e dos seus arquivos enviados assim que você conecta uma credencial de Storage. Se os dados moram em outro lugar, o Monitor é a metade que serve.

O que fazer esta semana

A metade de dentro de tudo isso, a saída do build e o banco de dados, é o guia do Cursor. O checklist de segurança de 10 minutos cobre o que vale a pena confirmar em qualquer app recém-lançado, seja lá o que o tenha escrito.