O Cursor é seguro de usar? Riscos, controlos e boas práticas

O que é o Cursor e porque é que muda o modelo de segurança?

O Cursor é um editor de código pensado de raiz para a IA, um fork do VS Code reconstruído à volta do modelo em vez de à volta do ficheiro. Trabalha dentro do fluxo habitual do programador (o editor, o terminal integrado, o painel do agente) e age a partir de instruções em linguagem natural: explica esta base de código, constrói esta funcionalidade, corrige este teste que falha, refatoriza estes ficheiros. Para o fazer bem, indexa o repositório para dar contexto ao modelo, edita vários ficheiros numa única execução do agente, executa tarefas e comandos de terminal e estende-se através do Model Context Protocol (MCP) até bases de dados, sistemas de issues e ferramentas internas.

É esta combinação que parte o velho modelo de segurança. Um assistente de IDE clássico oferecia uma sugestão de código; um humano lia-a e decidia aceitá-la ou rejeitá-la. O raio de impacto de uma má sugestão era um bloco de código que um programador ainda tinha de colar. O Cursor, pelo contrário, executa ações. Lê ficheiros que nunca indicaste, corre comandos que nunca escreveste, reescreve código por toda a árvore e pode executar uma tarefa no instante em que abres uma pasta. A superfície de ataque já não é "o que sugeriu o modelo". É "o que pode este editor fazer com o acesso que tem, que código consegue gerar em volume e quem consegue influenciar as instruções que recebe".

Uma sugestão é um rascunho que um humano escolhe aceitar. Uma ação é algo que já aconteceu. O modelo de segurança tem de deixar de rever rascunhos e passar a restringir ações.

Há uma segunda mudança, e tem que ver com a velocidade. O pull request tornou-se a casa da segurança de aplicações porque funcionava à cadência humana: uma pessoa abrandava, lia o diff e só depois fazia o merge. O Cursor não trabalha à cadência humana. Uma única sessão de agente pode produzir mais código numa tarde do que um revisor lê numa semana, e o editor gera de bom grado código que funciona mas é, sem dar nas vistas, inseguro. A partir daí, o diff deixa de ser um ponto de controlo e passa a ser a ata de decisões já tomadas. Qualquer controlo que só atue no pull request está a rever o passado, não a evitá-lo.

Para a maioria das equipas, a pergunta prática não é se o Cursor tem proteções nativas. Tem, e várias são mesmo boas. A pergunta é se chegam para o uso diário. A resposta honesta é não. A própria página de segurança do Cursor documenta controlos reais, que reduzem o risco, mas adotá-lo em segurança continua a depender de permissões, isolamento, supervisão humana e validação independente do código, das dependências, dos segredos e das pipelines.

Como funciona o modelo de segurança do Cursor

O modelo do Cursor assenta em três ideias: provar que a plataforma trata os dados de forma responsável, dar ao programador alavancas para manter o código sensível fora do alcance do modelo e conter o que um projeto aberto pode fazer. Na prática, isso traduz-se num punhado de controlos.

É uma base razoável, e a maior parte disto não existia nos assistentes de IDE de há uma geração. A armadilha é tomá-la por uma fronteira de segurança acabada. O Privacy Mode protege os teus dados, mas não diz nada sobre a segurança do código que o Cursor escreve. O .cursorignore só funciona se o mantiveres. O Workspace Trust só te protege se estiver ligado, e durante boa parte da história do Cursor não estava. O SOC 2 atesta a forma como o Cursor gere o serviço, não o grau de segurança com que se comporta na tua máquina. Cada um destes controlos tem um limite documentado, e a próxima secção mostra o que acontece quando te apoias demasiado neles.

Os 6 principais riscos de segurança no Cursor

Os riscos abaixo não são teóricos. Correspondem a vulnerabilidades divulgadas, a investigação publicada e ao OWASP Top 10 para Aplicações LLM. Os números que os enquadram são os mesmos que todas as equipas de AppSec citam hoje.

1. Workspace Trust desligado por omissão, levando a execução silenciosa de código

É o problema que mais marca o Cursor. Em setembro de 2025, o The Hacker News noticiou uma falha ("Cursor AI Code Editor Flaw Enables Silent Code Execution via Malicious Repositories") cuja origem era o Workspace Trust vir desativado por omissão. Como o Cursor é um fork do VS Code, um projeto pode trazer uma tarefa .vscode/tasks.json configurada com runOn: folderOpen e, com a confiança desligada, essa tarefa arranca no instante em que um programador abre a pasta e corre código arbitrário no contexto do utilizador.

O ataque é trivial de montar. Um atacante publica no GitHub um repositório apelativo, esconde lá dentro uma tarefa de "autorun" e espera que alguém o clone e o abra no Cursor. Sem prompt, sem clique, sem revisão: basta abrir o projeto para roubar credenciais, alterar ficheiros ou plantar uma base para um ataque mais amplo. Os investigadores (Oasis Security) recomendaram a mesma mitigação que nós: ativa o Workspace Trust, abre primeiro os repositórios não confiáveis noutro editor e audita um projeto antes de o abrires no Cursor. A correção é uma definição, mas só ajuda os programadores que sabem que a têm de ligar.

2. Código inseguro gerado por IA

O trabalho do Cursor é escrever código depressa, e depressa não quer dizer seguro. O benchmark SusVibes da Carnegie Mellon, que avalia agentes de código comerciais, o Cursor incluído, concluiu que o melhor par de agente e modelo produzia código funcionalmente correto em 61% das vezes, mas código seguro em apenas 10,5%, e que mais de 80% das soluções funcionalmente corretas continuavam a ter uma vulnerabilidade. O perigo está no intervalo entre "funciona" e "é seguro": código que passa nos testes e leva a vulnerabilidade para produção.

Os padrões são previsíveis. SQL concatenado em strings em vez de queries parametrizadas (a clássica injeção de SQL), prototype pollution em JavaScript, falta de codificação da saída que abre a porta ao XSS, endpoints gerados sem validação de input. Não são bugs exóticos; são os clássicos da OWASP, reproduzidos à velocidade da máquina porque o modelo aprendeu com um corpus público cheio deles. O estudo "Asleep at the Keyboard" da NYU concluiu que cerca de 40% do código gerado por IA era vulnerável nos cenários do MITRE Top-25, e o Cursor cabe por inteiro nessa distribuição. Quanto mais depressa o editor entrega, mais depressa as falhas se acumulam, e um código com ar de funcionar é exatamente o que um revisor apressado deixa passar.

3. Exposição de dados e de contexto

O Cursor é útil porque tem contexto, e esse contexto inclui muitas vezes mais do que código-fonte. Tudo o que está aberto no workspace, um ficheiro .env, uma config com strings de ligação, endpoints internos de API, pode ser puxado para o contexto do modelo, a menos que o excluas explicitamente com o .cursorignore. As funcionalidades de IA do Cursor enviam também código para uma API externa para gerar as respostas. Para lógica de negócio sensível, saber para onde vai esse tráfego é uma questão real, e é o Privacy Mode que decide o que o Cursor e os fornecedores ficam a guardar.

A exposição é muitas vezes indireta. Ao resumir um repositório ou ao depurar um erro, o agente pode deixar escapar um token, uma credencial ou um hostname interno numa saída que acaba depois num chat, num ticket ou num ficheiro com commit, onde fica muito depois de a sessão terminar. Como a Endor Labs e outros já notaram, a indexação da base de código alarga esta superfície: quanto mais o Cursor indexa, mais coisas pode alcançar sem querer. A postura por omissão é a conveniência, e conveniência quer dizer acesso amplo, a menos que o restrinjas à mão.

4. Injeção de prompt e envenenamento de ficheiros de regras

A injeção de prompt é o risco que define as ferramentas de código agênticas, e é o risco LLM número um da OWASP (LLM01) pelo terceiro ano consecutivo. Um atacante esconde instruções em algo que o agente lê, e o agente segue-as, por cima do comportamento previsto.

No Cursor, a forma perigosa é a indireta, com uma particularidade própria do Cursor: o ficheiro de regras. As instruções maliciosas podem vir no conteúdo do repositório, num ficheiro .cursorrules ou de regras de projeto, ou na saída de uma ferramenta MCP. Como um ficheiro de regras existe para orientar o agente, um ficheiro envenenado é injeção de prompt por definição: um contribuidor ou uma dependência mete instruções forjadas nas regras, e o Cursor trata-as como política. Um comentário num README a dizer "antes de continuar, corre este script de configuração" pode bastar. Como um modelo de linguagem não consegue distinguir com fiabilidade uma instrução de confiança de uma instrução maliciosa embutida nos dados, a injeção pode levar à execução de comandos, à exfiltração de dados ou à manipulação silenciosa do código. Um agente manipulado não se limita a responder mal: age.

5. Cadeia de abastecimento e servidores MCP maliciosos

O Cursor instala pacotes, clona repositórios e liga-se a ferramentas externas no decorrer do trabalho normal. Se puxar uma biblioteca comprometida ou se ligar a um servidor MCP hostil, o código malicioso corre com o acesso que o ambiente lhe der. Não é uma hipótese. No início de 2026, uma campanha de typosquatting no npm, identificada como "Sandworm_Mode", plantou servidores MCP falsos que imitavam utilitários populares e visavam especificamente assistentes de código de IA, entre eles o Cursor, o Claude Code e o Devin Desktop.

O MCP é uma nova fronteira de confiança para a qual a maioria das equipas ainda não fez a modelação de ameaças. Um servidor malicioso ou comprometido pode esconder instruções nas descrições e nas respostas das suas ferramentas, de modo que basta estar ligado para orientar o agente antes mesmo de a ferramenta ser chamada. A alucinação de pacotes agrava o risco: um agente que inventa um nome de pacote plausível mas inexistente deixa aos atacantes um nome livre para registarem e transformarem em arma. E o agente aprova muitas vezes a instalação com toda a confiança, porque o nome parece certo e a tarefa pedia-o.

6. Vulnerabilidades documentadas do editor que levam a RCE

Para além da falha de autorun, o Cursor acumulou uma série de avisos de segurança, incluindo investigação publicada por grupos como a Geordie AI, sobre vetores de contorno da confiança e de execução de código no próprio editor (hooks Git escondidos, execução persistente por contorno da confiança do MCP e problemas relacionados). A conclusão que se repete é que o Cursor é razoavelmente seguro enquanto IDE e francamente inseguro enquanto gerador automático de código sem uma camada externa de revisão.

O perigo cresce quando o editor corre com acesso amplo à máquina do programador. Uma sequência de ações inofensivas uma a uma (instala esta dependência, corre esta tarefa, aplica esta edição) pode instalar malware, alterar uma configuração de CI ou abrir um mecanismo de persistência. É exatamente por isto que o controlo de confiança, o privilégio mínimo e os ambientes isolados contam, e é por isso que a combinação a temer é a mais comum: um repositório não confiável, uma configuração permissiva para evitar atrito e uma instrução injetada que o editor trata como legítima.

O que a segurança nativa do Cursor cobre, e o que não cobre

Os controlos nativos são reais, e convém ser preciso sobre a fronteira entre o que resolvem e o que deixam a teu cargo.

O verdadeiro trabalho está na coluna da direita. Os controlos nativos do Cursor estão virados para a privacidade dos dados e para a conformidade do fornecedor, que é onde caem as primeiras perguntas de quem compra. Nunca foram pensados para travar um adversário determinado que controla os inputs do editor, e não dizem quase nada sobre a segurança do código que o Cursor escreve. Tudo o que faz passar de "o Cursor está instalado" a "o Cursor está governado" está nas práticas que se seguem.

Boas práticas para proteger o Cursor

Estas nove práticas fecham a lacuna entre a base nativa e uma postura de segurança a sério. Nenhuma é exótica; a disciplina está em aplicá-las com consistência numa equipa que avança depressa.

1. Ativa o Workspace Trust e trata os repositórios não confiáveis como hostis. Liga o Workspace Trust como parte normal da configuração, para que uma pasta aberta não possa executar uma tarefa sozinha. Abre primeiro num ambiente isolado (sandbox) ou noutro editor os repositórios que não escreveste, audita o .vscode/tasks.json e os hooks Git antes de confiares neles e nunca explores um repositório público apelativo na tua instância principal do Cursor sem verificar o que ele está autorizado a correr.

2. Impõe o Privacy Mode a toda a equipa e decide o que pode guardar código. O Privacy Mode deixa o teu código fora do treino e impede os fornecedores de modelos de o guardarem. Impõe-no a partir do dashboard da equipa em qualquer repositório com lógica de negócio real, dados regulados ou código proprietário. Depois, decide de forma explícita sobre as funcionalidades que guardam código do lado do Cursor, a começar pelos Cloud Agents, e sobre os modelos cujo fornecedor retém os dados, como o Claude Fable 5, em vez de deixares isso ao critério de cada programador.

3. Trata o .cursorignore como um artefacto de segurança. Exclui os ficheiros .env, os armazéns de credenciais, a configuração de infraestrutura, as strings de ligação e qualquer módulo sensível, tanto do contexto da IA como da indexação. Revê o ficheiro de exclusão como revês o controlo de acessos: com regularidade, depois de cada novo segredo ou serviço e como parte do onboarding de cada novo repositório. Um .cursorignore desatualizado é a forma mais comum de um segredo acabar no contexto de um modelo.

4. Mantém um humano no circuito do código gerado. Trata a saída do Cursor como um rascunho, não como uma implementação acabada. Faz passar todo o código gerado ou alterado por revisão de pull request e testes automáticos, com atenção redobrada à autenticação, à validação de input, às queries SQL e aos caminhos privilegiados, precisamente as áreas onde os dados do SusVibes mostram o modelo a falhar. A questão não é desconfiar da ferramenta; é que um editor que produz milhares de linhas por dia produz falhas subtis mais depressa do que elas vêm à superfície por si.

5. Analisa o código gerado por IA com SAST no CI. Como só uma pequena fração das soluções de IA é segura por omissão, um gate de análise estática não é opcional. Corre SAST em cada pull request, faz falhar o build perante descobertas de alta severidade (injeção de SQL, XSS, prototype pollution, autorização em falta) e devolve os resultados aos programadores para que as mesmas classes deixem de se repetir. Os testes funcionais não apanham um endpoint vulnerável que funciona; só uma verificação pensada para a segurança o apanha.

6. Controla dependências, pacotes e servidores MCP. Limita as instalações a registos de confiança ou a mirrors internos, exige aprovação para pacotes novos e analisa tudo com análise de composição de software. Valida cada servidor MCP como uma fronteira de confiança: usa os que escreveste ou em que confias a sério, dá a cada um o mínimo de dados e de ações de que precisa e mantém um inventário, para que um pacote com typosquatting como os servidores "Sandworm_Mode" não entre sem ninguém dar por isso.

7. Mantém os segredos fora de alcance. Não deixes segredos em texto simples no workspace que o agente consegue ver. Usa um cofre e injeta-os em tempo de execução, oculta os valores sensíveis nos logs e nas saídas e nunca deixes ficheiros de credenciais onde a indexação do Cursor lhes possa chegar. Se um segredo aparecer alguma vez numa transcrição, num ficheiro gerado ou num commit, roda-o de imediato e investiga como lá foi parar.

8. Corre o trabalho arriscado em ambientes isolados e com privilégio mínimo. Usa contentores ou VMs isoladas para o trabalho assistido por IA sobre código não confiável, corre o Cursor sem privilégios elevados e bloqueia as ligações de saída não aprovadas, para que uma sessão comprometida não consiga exfiltrar dados. Separa os ambientes por sensibilidade, de modo que o trabalho de alto risco fique contido e o raio de impacto de um ataque continue pequeno. Na tua própria máquina, não atives o Run Everything, o antigo YOLO mode: vê o que cada run mode do Cursor deixa o agente fazer.

9. Define a política por repositório e pela sensibilidade do ambiente. Classifica os repositórios (público, interno, regulado, produção) e aplica controlos mais apertados aos sensíveis: Privacy Mode ligado, indexação limitada, saída restringida, revisão mais exigente. Nos sistemas críticos, usa o Cursor apenas em ambientes sem caminho direto para as credenciais de produção, e documenta a política para que os programadores saibam onde a ajuda da IA é permitida e com que restrições.

Onde os controlos nativos param: proteger o agente no momento do prompt

Volta a percorrer os riscos e surge um padrão. O Workspace Trust, o Privacy Mode, o .cursorignore e o SAST atuam todos sobre o que o editor já decidiu fazer, ou sobre código que já escreveu. Concentram-se à volta do pull request, porque é aí que a AppSec sempre viveu. Mas o PR só foi um ponto de controlo porque um humano o lia, e ao ritmo do agente já ninguém o lê do princípio ao fim.

O sítio para impor uma regra já não é o diff; é o prompt, antes de a linha insegura ser escrita. Qualquer regra que queiras que o Cursor siga tem de estar nas mãos dele no momento em que escreve, e não à espera num scanner que só chega quando o código já está em disco e o agente já passou à tarefa seguinte.

É essa a camada que o VibeDefend acrescenta. É uma CLI npm gratuita que se instala com um só comando e liga o Cursor (e também o Claude Code, o OpenAI Codex, o Devin Desktop e o VS Code Copilot) a quatro camadas de governação que correm dentro do ciclo do agente.

Regras de Negócio As convenções do teu repositório que nunca ninguém escreveu (usar Decimal128 para dinheiro, a autorização passa por requireOwner). O VibeDefend extrai-as da forma como a tua equipa já programa e carrega-as no contexto do Cursor antes de cada edição. Regras de Segurança OWASP Top 10, SOC 2, RGPD e ISO 27001, carregadas no dia em que instalas. O agente lê o lembrete aplicável antes de escrever, e o requisito do framework passa a fazer parte do código em vez de ser uma caixa a assinalar na altura da auditoria. Action Guard As chamadas destrutivas (um sudo rm -rf, uma leitura em bruto de uma variável de ambiente com cara de segredo, um psql ad-hoc contra um host de produção) são intercetadas antes de dispararem. Avisa ou bloqueia conforme a regra, e cada interceção fica no registo de auditoria. Live Findings Cada resultado dos scanners da CybeDefend (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD) está ao vivo no contexto do Cursor, e por isso ele não só escreve código seguro como faz a triagem e corrige as vulnerabilidades que já existem.

Num controlo tão perto do código, importa saber para onde vai o código, tal como importa no próprio Privacy Mode do Cursor, por isso fica dito sem rodeios. Os action guards decidem no teu portátil, antes de um comando correr. Para servir as regras que se aplicam à linha que está a ser escrita, o VibeDefend envia um excerto curto desse código para o backend da CybeDefend, e a análise feita antes do commit envia os ficheiros alterados, ambos para a região da UE ou dos EUA que escolhes na instalação, e o teu código nunca é usado para treinar um modelo. As duas regiões são fisicamente separadas.

Isto não substitui as práticas acima. É a camada em falta que elas dão como existente: a que põe as tuas regras nas mãos do Cursor no momento do prompt, para que a linha insegura seja reescrita antes sequer de ser sugerida, em vez de apanhada três fases depois por um scanner a ler um diff que ninguém teve tempo de ler. O Workspace Trust impede o editor de fazer o que não deve; o VibeDefend molda, logo à partida, o que ele escreve.

Perguntas frequentes

O Cursor é seguro?

O Cursor é seguro de usar quando está bem configurado e contido, e arriscado quando não está. A conformidade SOC 2 Type II, o Privacy Mode, o .cursorignore e o Workspace Trust evitam uma classe real de fugas de dados e de acidentes. O risco que sobra vem dos valores por omissão (Workspace Trust historicamente desligado, indexação ampla), do código que gera (só uma pequena fração é segura logo à partida), dos inputs (injeção de prompt, ficheiros de regras envenenados, servidores MCP maliciosos) e do ambiente à volta (segredos expostos, repositórios não confiáveis). Trata-o como um agente poderoso que precisa de controlo de confiança, exclusão de segredos, revisão humana e SAST, e não como uma ferramenta segura por omissão.

O Cursor envia o meu código para a cloud?

Sim. As funcionalidades de IA do Cursor enviam código para uma API externa para gerar as respostas, o que pode incluir o conteúdo de ficheiros e o contexto à volta da tua tarefa. O Privacy Mode muda o que acontece a esse código do lado do Cursor: com ele ligado, o Cursor não treina com o teu código e os fornecedores de modelos não o guardam, embora os Cloud Agents, por definição, guardem código. Para lógica de negócio sensível, mantém o Privacy Mode ativado, exclui os segredos e os dados regulados do contexto com o .cursorignore e compara o que o Cursor guarda do teu código com os teus próprios requisitos.

O que é o .cursorignore e porque é que importa?

O .cursorignore é um ficheiro (com o mesmo espírito do .gitignore) que diz ao Cursor que caminhos deve excluir do contexto da IA e da indexação da base de código. Importa porque, por omissão, tudo o que está aberto no workspace pode ser puxado para o contexto do modelo, incluindo ficheiros .env, configs e strings de ligação. Um .cursorignore bem mantido é a principal alavanca para manter os segredos e os módulos sensíveis fora do alcance do modelo. Um desatualizado é a forma mais comum de uma credencial acabar num pedido de IA.

Devo ativar o Workspace Trust no Cursor?

Sim. O Workspace Trust só deixa uma pasta aberta executar código depois de uma decisão explícita de confiança. É a mitigação direta da falha de setembro de 2025, em que um repositório armadilhado podia lançar sozinho uma tarefa e correr código no momento em que abrias a pasta. Como o Cursor vinha historicamente com o Workspace Trust desativado por omissão, ativá-lo deve fazer parte normal da tua configuração. Junta-lhe o hábito de abrir primeiro os repositórios não confiáveis num ambiente isolado (sandbox) ou noutro editor.

O Cursor pode correr código de um repositório automaticamente?

Pode, se o Workspace Trust estiver desligado. Como é um fork do VS Code, o Cursor respeita as tarefas configuradas com runOn: folderOpen, por isso um .vscode/tasks.json malicioso num repositório que clonas e abres pode executar de imediato, sem prompt, no teu contexto de utilizador. Foi esta a base da falha de execução silenciosa de código noticiada em setembro de 2025. Ativar o Workspace Trust fecha a lacuna, mas é por causa do comportamento por omissão que nunca deves abrir um projeto não confiável na tua instância principal do Cursor.

O Privacy Mode chega para tornar o Cursor seguro?

Não, e aqui convém ser preciso. O Privacy Mode é um controlo de dados: deixa o teu código fora do treino e impede os fornecedores de modelos de o guardarem. Não diz nada sobre a segurança do código que o Cursor gera, nem sobre se um repositório pode lançar uma tarefa sozinho, se uma injeção de prompt pode manipular o agente ou se um servidor MCP é malicioso. O Privacy Mode protege os teus dados; não protege a tua aplicação. Continuas a precisar do Workspace Trust, do .cursorignore, de SAST, de revisão humana e de um controlo no momento do prompt.

Em que é que a segurança do Cursor difere da do Claude Code, GitHub Copilot ou Codex?

Os fundamentos são os mesmos (privilégio mínimo, exclusão de segredos, revisão humana, análise de dependências), mas as superfícies mudam. Os problemas próprios do Cursor são o Workspace Trust vir desligado por omissão e uma taxa elevada de código inseguro gerado; no Claude Code, é a integração profunda com MCP e com a shell; no GitHub Copilot, as sugestões inseguras e a fuga de segredos em grande escala; no Codex, a injeção de comandos e os incidentes de cadeia de abastecimento. Tratamos cada agente no seu próprio guia: Claude Code, GitHub Copilot e OpenAI Codex. Para ver os seis editores lado a lado, consulta a nossa comparação das funcionalidades de segurança dos editores de código com IA.