Manter seu código-fonte e ambiente de desenvolvimento seguros é importante para nós. Esta página descreve como abordamos a segurança no Cursor.

Envie possíveis vulnerabilidades por e-mail para security-reports@cursor.com.

Para quaisquer dúvidas relacionadas à segurança, entre em contato conosco pelo e-mail security@cursor.com.

Embora já tenhamos várias organizações de grande porte que confiam no Cursor, observe que ainda estamos no processo de evolução do nosso produto e de aprimoramento da nossa postura de segurança. Se você trabalha em um ambiente altamente sensível, deve ter cuidado ao usar o Cursor (ou qualquer outra ferramenta de IA). Esperamos que esta página traga transparência sobre o nosso progresso e ajude você a fazer uma avaliação adequada de riscos.

#Certificações e avaliações de terceiros

Cursor possui certificação SOC 2 Tipo II. Acesse trust.cursor.com para solicitar uma cópia do relatório.

Comprometemo-nos a realizar, pelo menos uma vez por ano, testes de penetração (pentests) conduzidos por terceiros especializados e reconhecidos. Acesse trust.cursor.com para solicitar um resumo executivo do relatório mais recente.

#Segurança da infraestrutura

Dependemos dos seguintes subprocessadores, organizados aproximadamente do mais crítico para o menos crítico. Observe que dados de código são enviados para nossos servidores para alimentar todos os recursos de IA do Cursor (veja a seção de Solicitações de IA) e que dados de código de usuários no modo de privacidade (legado) nunca são armazenados (veja a seção Garantia do Modo de Privacidade).

Explore como cada modo afeta a forma como os dados são enviados e armazenados:

*O Cursor respeita listas de bloqueio de modelos e não enviará nenhuma solicitação para modelos em uma lista de bloqueio.

Nenhuma parte da nossa infraestrutura está localizada na China. Não usamos diretamente nenhuma empresa chinesa como subprocessadora e, até onde sabemos, nenhum de nossos subprocessadores usa empresas chinesas.

Atribuímos acesso à infraestrutura aos membros da equipe com base no princípio do menor privilégio. Impomos autenticação multifator para a AWS. Restringimos o acesso a recursos usando tanto controles em nível de rede quanto segredos.

#Segurança do cliente

Cursor é um fork de código aberto do Visual Studio Code (VS Code), mantido pela Microsoft. Eles publicam comunicados de segurança na página de segurança do GitHub. A cada duas versões principais do VS Code, fazemos o merge do código upstream 'microsoft/vscode' no Cursor. Você pode verificar em qual versão do VS Code a sua versão do Cursor é baseada clicando em "Cursor > About Cursor" no app. Se houver um patch de segurança de alta gravidade no VS Code upstream, faremos cherry-pick da correção antes do próximo merge e lançaremos uma atualização imediatamente.

Nosso app fará solicitações para os seguintes domínios para se comunicar com nosso backend. Se você estiver atrás de um proxy corporativo, adicione esses domínios à lista de permissões para garantir que o Cursor funcione corretamente.

• 'api2.cursor.sh': Usado para a maior parte das requisições de API.

• 'api5.cursor.sh': Usado para requisições do agente do Cursor.

• 'api3.cursor.sh': Usado para requisições do Cursor Tab (apenas HTTP/2).

• 'repo42.cursor.sh': Usado para indexação da base de código (apenas HTTP/2).

• 'api4.cursor.sh', 'us-asia.gcpp.cursor.sh', 'us-eu.gcpp.cursor.sh', 'us-only.gcpp.cursor.sh': Usados para requisições do Cursor Tab, dependendo da sua localização (apenas HTTP/2).

• 'adminportal42.cursor.sh': Usado para configurar SSO e verificação de domínio.

• 'marketplace.cursorapi.com', 'cursor-cdn.com', 'downloads.cursor.com', 'anysphere-binaries.s3.us-east-1.amazonaws.com': Usados para atualizações do cliente e para baixar extensões do marketplace de extensões.

Duas diferenças de segurança em relação ao VS Code a observar:

1. Workspace Trust é desativado por padrão no Cursor. Você pode ativá-lo definindo 'security.workspace.trust.enabled' como 'true' nas configurações do Cursor. Ele é desativado por padrão para evitar confusão entre o "Restricted Mode" do Workspace Trust e o "Privacy Mode" do Cursor, e porque suas regras de confiança são complexas e difíceis de entender (por exemplo, mesmo com o Workspace Trust ativado, você não está protegido contra extensões maliciosas, apenas contra pastas maliciosas). Estamos abertos a feedback da comunidade sobre se devemos ativá-lo por padrão.

2. Assinaturas de código de extensões: o Cursor não verifica assinaturas de extensões que são baixadas do marketplace. O VS Code começou recentemente a fazer isso. Em particular, a configuração 'extensions.verifySignature' é 'false' por padrão no Cursor, mas 'true' no VS Code. Se você defini-la como 'true' no Cursor, verá um pop-up informando que a verificação de assinatura falhou sempre que tentar baixar uma extensão. Esperamos passar a oferecer suporte à verificação de assinatura de extensões em um futuro de médio prazo.

#Solicitações de IA

Para oferecer seus recursos, o Cursor faz solicitações de IA ao nosso servidor. Isso acontece por diversos motivos. Por exemplo, enviamos solicitações de IA quando você faz perguntas no chat, enviamos solicitações de IA a cada tecla pressionada para que o Cursor Tab possa fazer sugestões para você e também podemos enviar solicitações de IA em segundo plano para ampliar o contexto ou procurar bugs para mostrar a você.

Uma solicitação de IA geralmente inclui contexto como seus arquivos visualizados recentemente, seu histórico de conversas e trechos relevantes de código com base nas informações do language server. Esses dados de código são enviados para nossa infraestrutura na AWS e, em seguida, para o provedor de inferência de modelo de linguagem apropriado (Fireworks/OpenAI/Anthropic/Google). Observe que as solicitações sempre passam pela nossa infraestrutura na AWS, mesmo se você tiver configurado sua própria chave de API da OpenAI nas configurações.

Atualmente, não temos capacidade de rotear diretamente do aplicativo do Cursor para sua implantação Enterprise da OpenAI/Azure/Anthropic, pois a montagem dos prompts acontece em nosso servidor, e nossos modelos personalizados na Fireworks são fundamentais para oferecer uma boa experiência ao usuário. Ainda não temos uma opção de implantação de servidor auto-hospedado.

#Indexação da base de código

Cursor permite indexar semanticamente sua base de código, o que possibilita responder perguntas com o contexto de todo o seu código, além de escrever código melhor referenciando implementações existentes. A indexação da base de código é ativada por padrão, mas pode ser desativada nas configurações.

Nosso recurso de indexação da base de código funciona da seguinte forma: quando ativado, ele analisa a pasta que você abre no Cursor e calcula uma árvore de Merkle de hashes de todos os arquivos. Arquivos e subdiretórios especificados por '.gitignore' ou '.cursorignore' são ignorados. A árvore de Merkle é então sincronizada com o servidor. A cada 10 minutos, verificamos inconsistências de hash e usamos a árvore de Merkle para descobrir quais arquivos foram alterados e fazer upload apenas deles.

Em nosso servidor, dividimos os arquivos em blocos e geramos embeddings, armazenando esses embeddings no Turbopuffer. Para permitir filtrar resultados de busca vetorial por caminho de arquivo, armazenamos com cada vetor um caminho de arquivo relativo ofuscado, bem como o intervalo de linhas ao qual o bloco corresponde. Também armazenamos o embedding em um cache na AWS, indexado pelo hash do bloco, para garantir que indexar a mesma base de código pela segunda vez seja muito mais rápido (o que é particularmente útil para equipes).

No momento da inferência, calculamos um embedding, deixamos o Turbopuffer fazer a busca de vizinhos mais próximos, enviamos de volta o caminho de arquivo ofuscado e o intervalo de linhas para o cliente e lemos localmente esses blocos de arquivo no cliente. Em seguida, enviamos esses blocos de volta ao servidor para responder à pergunta do usuário. Isso significa que, para usuários em modo de privacidade, nenhum código em texto simples é armazenado em nossos servidores ou no Turbopuffer.

Algumas observações:

• Para bloquear o envio de arquivos específicos da sua base de código para os servidores do Cursor e sua inclusão em requisições de IA, adicione um arquivo '.cursorignore' à sua base de código listando os arquivos e diretórios que devem ser excluídos. O Cursor fará o máximo possível para evitar que esses arquivos sejam expostos em qualquer requisição.

• Detalhes da ofuscação de caminho de arquivo: o caminho é dividido por '/' e '.' e cada segmento é criptografado com uma chave secreta armazenada no cliente e um nonce determinístico curto de 6 bytes. Isso vaza informações sobre a hierarquia de diretórios e terá algumas colisões de nonce, mas oculta a maior parte das informações.

• Reversão de embeddings: trabalhos acadêmicos mostraram que reverter embeddings é possível em alguns casos. Ataques atuais dependem de ter acesso ao modelo e inserir strings curtas em vetores grandes, o que nos leva a acreditar que o ataque seria relativamente difícil de executar aqui. Dito isso, é definitivamente possível que um adversário que invada nosso banco de dados vetorial aprenda coisas sobre as bases de código indexadas.

• Quando a indexação da base de código está ativada em um repositório Git, também indexamos o histórico do Git. Especificamente, armazenamos SHAs de commits, informações sobre os commits pais e nomes de arquivos ofuscados (como acima). Para permitir o compartilhamento da estrutura de dados entre usuários no mesmo repositório Git e na mesma equipe, a chave secreta para ofuscar os nomes de arquivos é derivada de hashes dos conteúdos de commits recentes. Mensagens de commit e conteúdos ou diffs de arquivos não são indexados.

• Nosso recurso de indexação frequentemente sofre com alta carga, o que pode fazer com que muitas requisições falhem. Isso significa que, às vezes, arquivos precisarão ser enviados várias vezes antes de serem totalmente indexados. Uma forma de isso se manifestar é que, se você verificar o tráfego de rede para 'repo42.cursor.sh', poderá ver mais uso de largura de banda do que o esperado.

#Garantia do modo de privacidade

O modo de privacidade pode ser ativado nas configurações ou por um administrador de equipe. Quando está ativado, garantimos que dados de código nunca sejam armazenados por nossos provedores de modelo nem usados para treinamento. O modo de privacidade pode ser ativado por qualquer pessoa (usuário gratuito ou Pro) e, por padrão, é ativado de forma obrigatória para qualquer usuário que seja membro de uma equipe.

Levamos a garantia do modo de privacidade muito a sério. Mais de 50% de todos os usuários do Cursor têm o modo de privacidade ativado.

Cada requisição ao nosso servidor inclui um cabeçalho 'x-ghost-mode', contendo um valor booleano que indica se o usuário está em modo de privacidade. Para evitar tratar acidentalmente um usuário em modo de privacidade como um usuário fora do modo de privacidade, sempre assumimos, por padrão, que o usuário está em modo de privacidade se o cabeçalho estiver ausente.

Todas as requisições ao nosso servidor passam primeiro por um proxy, que decide qual serviço lógico deve lidar com a requisição (por exemplo, o "chat service" ou o "Cursor Tab service"). Cada serviço lógico existe em duas réplicas quase idênticas: uma réplica que trata requisições em modo de privacidade e outra réplica que trata requisições fora do modo de privacidade. O proxy verifica o valor do cabeçalho 'x-ghost-mode' e envia a requisição para a réplica apropriada. As próprias réplicas também verificam o cabeçalho, por redundância. Por padrão, todas as funções de log das réplicas de modo de privacidade são no-ops (ou seja, não executam nenhuma ação), a menos que terminem com sufixos como 'infoUnrestricted', que revisamos cuidadosamente para nunca anexar nenhum dado de código potencial ou prompts. Para requisições que disparam tarefas em segundo plano, da mesma forma temos filas paralelas e réplicas de workers para modo de privacidade e fora do modo de privacidade. Essa infraestrutura paralela nos deixa confiantes na nossa garantia de modo de privacidade e em sua resiliência contra erros acidentais ou bugs.

Para a aplicação do modo de privacidade em nível de equipe, cada cliente envia um ping ao servidor a cada 5 minutos para verificar se o usuário está em uma equipe que aplica o modo de privacidade. Se estiver, isso sobrescreve a configuração de modo de privacidade do cliente. Para evitar casos em que o ping de modo de privacidade do cliente falhe por qualquer motivo, nosso servidor também, no caminho crítico (hot path), verifica se o usuário faz parte de uma equipe que aplica o modo de privacidade e, em caso positivo, trata a requisição como se estivesse em modo de privacidade mesmo que o cabeçalho diga o contrário. Em serviços sensíveis à latência, armazenamos esse valor em cache por 5 minutos e, em qualquer falha de cache, assumimos que o usuário está em modo de privacidade. Em resumo, isso significa que, quando um usuário entra em uma equipe, ele terá a garantia de estar em modo de privacidade no máximo 5 minutos após entrar na equipe.

#Exclusão de conta

Você pode excluir sua conta a qualquer momento no Settings dashboard (clique em "Advanced" e depois em "Delete Account"). Isso vai excluir todos os dados associados à sua conta, incluindo quaisquer bases de código que tenham sido indexadas. Garantimos a remoção completa dos seus dados em até 30 dias (nós excluímos os dados imediatamente, mas alguns dos nossos bancos de dados e do nosso armazenamento em nuvem mantêm backups por, no máximo, 30 dias).

É importante observar que, se algum dos seus dados tiver sido usado no treinamento de modelos (o que só aconteceria se você não estivesse com o modo de privacidade ativado na época), nossos modelos já treinados não serão imediatamente retreinados. No entanto, quaisquer modelos futuros que forem treinados não usarão os seus dados, já que esses dados terão sido excluídos.

#Divulgação de vulnerabilidades

Se você acredita que identificou uma vulnerabilidade no Cursor, envie um relatório para security-reports@cursor.com.

Comprometemo-nos a acusar o recebimento de relatórios de vulnerabilidade em até 5 dias úteis e a tratá-los o mais rápido possível. Incidentes críticos serão comunicados por e-mail a todos os usuários.