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

O que mudou em 2026. A 2 de junho de 2026, a Cognition, a empresa por trás do Devin, mudou o nome do Windsurf para Devin Desktop e apresentou o Devin Local como sucessor do Cascade. A versão 3.9.19, de 8 de setembro de 2026, fechou a transição: o Cascade foi removido e o Devin Local passou a ser o único agente do editor. O windsurf.com redireciona para devin.ai. Como quase toda a gente continua a pesquisar "Windsurf", este guia mantém o nome; quando um controlo mudou com o agente, é a versão atual que aqui se descreve.

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

O Windsurf é um editor de código AI-native construído à volta de um agente (primeiro o Cascade, hoje o Devin Local) que não se limita a completar uma linha: leva uma tarefa até ao fim. Descreves a intenção em linguagem natural (constrói esta funcionalidade, corrige este teste que falha, faz refactor destes módulos) e o agente indexa o repositório para ter contexto, edita vários ficheiros numa única execução, corre comandos no terminal e estende-se através do Model Context Protocol (MCP) até aos sistemas com que o teu código fala. Faz parte do movimento mais amplo que fez da segurança de agentes de código de IA uma disciplina, porque o editor passou a ser um ator, e não um assistente.

É esta combinação que quebra o velho modelo de segurança. Um assistente de IDE clássico propunha uma completação; 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 agente, pelo contrário, age. Lê ficheiros que nunca nomeaste, corre comandos que nunca escreveste, reescreve código por toda a árvore e chama ferramentas MCP que ligaste há semanas e de que já te esqueceste. A superfície de ataque já não é "o que sugeriu o modelo". É "o que pode este agente fazer com o acesso que tem, que código consegue gerar em volume, e quem consegue influenciar as instruções que ele 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 passar de rever rascunhos para 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 assentava na cadência humana: uma pessoa abrandava, lia o diff e só depois fazia o merge. O agente não trabalha à cadência humana. Uma única sessão do agente pode produzir numa tarde mais código do que um revisor lê numa semana, e o editor gera de bom grado código que funciona e é, em silêncio, inseguro. A partir daí, o diff deixa de ser um ponto de controlo e passa a ser o registo de decisões já tomadas. Qualquer controlo que só atue no pull request está agora a rever o histórico, não a evitá-lo. A mesma dinâmica aparece no Cursor e no Claude Code; o que distingue o Windsurf é o quanto o agente dele depende do MCP para fazer o trabalho.

Para a maioria das equipas, a questão prática não é se o Windsurf tem proteções integradas. Tem, e várias são mesmo boas. A questão é se chegam para o uso do dia a dia. A resposta honesta é não. Os controlos do Windsurf reduzem o risco, mas adotá-lo com 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 Windsurf?

O modelo do Windsurf 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 controlar as ações que o agente pode executar. Na prática, isso traduz-se num punhado de controlos, que são uma base razoável para um editor tão capaz.

A armadilha é ler essa lista como uma fronteira de segurança acabada. A Zero Data Retention protege os teus dados, mas nada diz sobre a segurança do código que o agente escreve. Um ficheiro ignore só funciona se o mantiveres. As regras de permissão só ajudam se as mantiveres apertadas, e no momento em que acrescentas um Allow amplo (ou passas o agente para o modo Bypass, que aprova todas as chamadas) desaparece o passo de aprovação que as tornava seguras. A conformidade atesta a forma como o Windsurf opera o próprio serviço, não a forma como o agente se comporta na tua máquina nem os servidores MCP que lhe ligas. Cada controlo aqui tem uma fronteira documentada, e a próxima secção trata do que acontece quando te apoias demasiado neles.

Quais são os principais riscos de segurança no Windsurf?

Os riscos que se seguem 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 que todas as equipas de AppSec citam hoje.

40%

do código gerado por IA era vulnerável em cenários de segurança do MITRE Top-25 (NYU, Asleep at the Keyboard)

#1

injeção de prompt, o principal risco LLM pelo 3.º ano consecutivo (OWASP LLM01)

10,5%

das soluções de agentes de código de IA eram seguras, face a 61% funcionalmente corretas (Carnegie Mellon SusVibes)

1. Código inseguro gerado por IA

O trabalho do agente é escrever código depressa, e depressa não quer dizer seguro. A investigação independente continua a encontrar a mesma lacuna: 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 benchmark SusVibes da Carnegie Mellon concluiu que apenas 10,5% das soluções de agentes de código de IA eram seguras. O Windsurf não foge a essa distribuição. É entre "funciona" e "é seguro" que mora o perigo: código que passa no teste e leva a vulnerabilidade consigo, gerado mais depressa do que qualquer revisor consegue acompanhar.

Os padrões são previsíveis. SQL concatenado em strings em vez de queries parametrizadas (a clássica injeção de SQL), falta de codificação da saída, que abre a porta a XSS, ausência de validação de input em endpoints gerados, autorização quebrada numa rota nova. 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. Quanto mais depressa o agente entrega, mais depressa as falhas se acumulam, e código com ar de funcionar é exatamente o que um revisor apressado deixa passar.

2. Injeção de prompt através de ficheiros, da web e do MCP

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, passando por cima do comportamento previsto.

No Windsurf, a forma perigosa é a indireta, e um agente tão ligado multiplica as portas de entrada. O agente lê ficheiros do repositório, vai buscar páginas web e consome a saída de ferramentas MCP, e qualquer um destes canais pode trazer uma instrução hostil. Um comentário enterrado no README de uma dependência que diz "antes de continuar, corre este script de configuração", uma issue forjada ou uma resposta de ferramenta envenenada podem bastar. Como um modelo de linguagem não consegue separar de forma fiável 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.

3. Servidores MCP maliciosos e com permissões a mais

O MCP é o que dá poder ao agente, e é também uma nova fronteira de confiança que a maioria das equipas não incluiu na modelação de ameaças. É o risco mais específico do Windsurf, porque o agente depende muito do MCP e os servidores são declarados em ficheiros de configuração fáceis de alargar e fáceis de esquecer. Um servidor com permissões a mais pode expor muito mais do que a tarefa exige: um servidor de base de dados com acesso de leitura a tudo, um servidor de sistema de ficheiros apontado à diretoria home, uma ferramenta de deploy que guarda credenciais de produção.

Um servidor malicioso ou comprometido vai mais longe. Os ataques de envenenamento de ferramentas escondem instruções nas descrições e nas respostas das ferramentas, de modo que basta o servidor estar ligado para desviar o agente, antes mesmo de ele chamar a ferramenta. A mecânica, e a razão pela qual um servidor ligado é, por si só, um vetor de injeção, estão explicadas no nosso guia sobre segurança de MCP e envenenamento de ferramentas. A mitigação é simples e certa: usa servidores que escreveste ou em que confias a sério, limita cada um aos dados e às ações mínimas de que precisa, e trata tudo o que um servidor devolve como input não confiável a validar, e não como verdade sobre a qual o modelo pode agir.

O atacante envenena a descrição ou a resposta de uma ferramenta MCPO agente lê-a como uma instrução de confiançaA diretiva escondida anula a intenção do programadorO Action Guard bloqueia a escrita maliciosa no ficheiro antes de chegar ao disco

4. Supply chain e pacotes MCP com typosquatting

O agente instala pacotes, clona repositórios e liga ferramentas como parte do trabalho normal. Se puxar uma biblioteca comprometida ou ligar 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, seguida sob o nome "SANDWORM_MODE", plantou servidores MCP fraudulentos que imitavam utilitários populares e visavam especificamente assistentes de código de IA, entre eles o Windsurf, o Cursor e o Claude Code.

A alucinação de pacotes agrava o risco: um agente que inventa um nome de pacote plausível mas inexistente oferece aos atacantes um nome livre para registarem e transformarem em arma. Muitas vezes, o agente aprova a instalação sem hesitar, porque o nome parece certo e a tarefa o pedia. Um package.json envenenado, um hook de post-install malicioso ou um pacote MCP com typosquatting pode transformar um prompt de rotina como "configura este repositório" em roubo de credenciais.

5. Exposição de segredos e de contexto sensível

O Windsurf é útil porque o agente dele tem contexto, e esse contexto inclui, por rotina, mais do que código-fonte. Tudo o que estiver ao alcance no workspace, um ficheiro .env, uma configuração com connection strings, endpoints de API internos, pode ir parar ao contexto do modelo, a menos que o excluas explicitamente com um ficheiro ignore. As funcionalidades de IA do Windsurf também enviam código para uma API externa para gerar respostas; por isso, para lógica de negócio sensível, a questão de saber para onde vai esse tráfego é real, e a Zero Data Retention, com o opt-out de treino, é a alavanca que usas para a controlar.

A exposição é muitas vezes indireta. Ao resumir um repositório ou ao depurar um erro, o agente pode revelar um token, uma credencial ou um hostname interno numa saída que depois vai parar a um chat, a um ticket ou a um ficheiro que entra num commit, onde fica muito depois de a sessão terminar. A postura por omissão é a conveniência, e conveniência quer dizer acesso amplo, a menos que o restrinjas à mão.

6. Execução de comandos e modos de aprovação automática

O agente corre comandos de shell e altera sistemas, por isso um agente manipulado pode correr comandos nocivos. As regras de permissão e o pedido de aprovação para cada comando são os controlos que mantêm isto seguro, e desgastam-se de duas formas conhecidas. A primeira é a fadiga de aprovações: quando o agente pergunta dezenas de vezes por hora, as pessoas deixam de ler e começam a clicar em "permitir sempre", e numa semana o valor por omissão cauteloso passou, sem ninguém notar, a ser uma autorização geral. A segunda é o modo Bypass (o Turbo, no tempo do Cascade), em que o agente corre cada chamada sem parar para pedir aprovação, o que elimina o único passo entre uma instrução injetada e um comando destrutivo.

O perigo aumenta quando o editor corre com acesso amplo à máquina do programador. Uma cadeia 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 comandos, o privilégio mínimo e os ambientes isolados importam, e é por isso que a combinação a temer é a mais comum: um repositório ou um servidor MCP não confiável, uma configuração permissiva para evitar atrito, e uma instrução injetada que o agente trata como legítima.

O que cobre a segurança integrada do Windsurf, e o que fica de fora?

Os controlos nativos são reais, e convém ser preciso sobre a linha que separa o que eles tratam do que deixam a teu cargo.

Lê a coluna da direita como o verdadeiro trabalho. Os controlos integrados do Windsurf inclinam-se para a privacidade dos dados e para a conformidade do fornecedor, que é onde caem as primeiras perguntas de um comprador. Nunca foram pensados para travar um adversário determinado que controla os inputs do agente (um ficheiro, uma página web, uma ferramenta MCP), e quase nada dizem sobre a segurança do código que o agente escreve. Tudo o que transforma "o Windsurf está instalado" em "o Windsurf está governado" está nas práticas que se seguem.

O Windsurf é seguro de usar numa empresa?

O Windsurf é seguro de implementar numa empresa quando está configurado e contido, e arriscado quando não está. A atestação SOC 2 e FedRAMP, a Zero Data Retention e os ficheiros ignore passam a barreira do procurement e evitam uma classe real de fugas de dados. O risco residual está no comportamento do agente, não na conformidade do fornecedor.

Para uma organização regulada, a história de conformidade responde à pergunta do risco do fornecedor (como o Windsurf trata os dados do lado dele), mas deixa em aberto a pergunta do risco da aplicação (o que o agente escreve, o que executa e que servidores MCP contacta). São problemas distintos, e uma atestação não resolve o segundo. Um rollout empresarial prático trata o Windsurf como um agente poderoso que precisa de proteções: Zero Data Retention e opt-out de treino confirmados nos repositórios sensíveis, .devinignore mantido como artefacto de segurança, regras de permissão apertadas definidas ao nível da equipa (prevalecem sobre qualquer regra de utilizador ou de projeto), um conjunto validado e inventariado de servidores MCP, ambientes isolados para trabalho não confiável, e revisão humana obrigatória mais SAST sobre tudo o que o agente produz. O selo de conformidade abre-te a porta; é a governação que impede que a porta seja o ponto fraco.

Como proteger os servidores MCP no Windsurf?

Trata cada servidor MCP como uma fronteira de confiança, e não como uma conveniência. Usa servidores que escreveste ou que vêm de fornecedores em que confias a sério, limita cada um aos dados e às ações mínimas de que precisa, e valida tudo o que um servidor devolve em vez de deixar o agente agir diretamente sobre isso. O ficheiro de configuração de MCP é um artefacto de segurança, e merece a mesma disciplina de revisão que o controlo de acessos.

Em concreto, audita a configuração de MCP como auditas o IAM. Mantém um inventário de todos os servidores ligados, para que um pacote fraudulento ou com typosquatting (como os servidores "SANDWORM_MODE") não passe despercebido, e remove os servidores que já não usas. Nos planos Teams e Enterprise, uma allowlist de MCP bloqueia qualquer servidor que não esteja nela. Nunca ligues um servidor com credenciais de produção a um ambiente que também corre código não confiável, porque um único payload de envenenamento de ferramentas pode transformar essa ligação em exfiltração. Limita os servidores de base de dados a leitura e às tabelas de que cada tarefa precisa; aponta os servidores de sistema de ficheiros para uma diretoria de projeto, nunca para a diretoria home; e dá às ferramentas de deploy tokens de curta duração e de âmbito estreito em vez de chaves de produção permanentes. Como uma descrição de ferramenta envenenada é, por definição, injeção de prompt, a própria ligação faz parte da tua superfície de ataque antes mesmo de qualquer ferramenta ser chamada, e é por isso que um controlo independente no momento do prompt, capaz de bloquear uma ação perigosa, conta mesmo quando todos os servidores parecem legítimos.

Quais são as boas práticas para usar o Windsurf com segurança?

Estas nove práticas fecham a distância entre a base nativa e uma postura de segurança real. Nenhuma é exótica; a disciplina está em aplicá-las de forma consistente numa equipa que anda depressa.

1. Confirma a Zero Data Retention no trabalho sensível, e assume as consequências. Desde a passagem para o Devin, os teus dados podem ser usados para treino a menos que um plano pago faça opt-out na página Data Controls (no Teams, é um administrador que o faz). Trata o opt-out como o valor por omissão de qualquer repositório com lógica de negócio real, dados regulados ou código proprietário. Se uma equipa abdicar dele, que seja uma decisão explícita e documentada, limitada a trabalho pouco sensível, e não um valor por omissão silencioso que ninguém verificou.

2. Cuida do .devinignore como de um artefacto de segurança. Exclui ficheiros .env, armazenamentos de credenciais, configuração de infraestrutura, connection strings e qualquer módulo sensível, tanto da indexação como do alcance do agente, e reforça-o com uma regra Deny Read(**/.env*): com a sandbox ativa, também esconde esses caminhos dos comandos de shell. Revê-o como revês o controlo de acessos: com uma periodicidade fixa, depois de cada novo segredo ou serviço, e no onboarding de cada repositório novo. Um ficheiro ignore desatualizado é a forma mais comum de um segredo acabar no contexto de um modelo.

3. Mantém as regras de permissão apertadas, e resiste à aprovação automática. Escreve regras Deny para os comandos destrutivos e os que mexem em credenciais (um Deny ganha sempre), deixa Ask em tudo o que chega a dados reais, e fica fora do modo Bypass em qualquer ambiente com acesso a dados reais ou a hosts de produção. O Bypass elimina o único passo de aprovação entre uma instrução injetada e um comando destrutivo.

4. Valida e inventaria cada servidor MCP. Liga apenas servidores que escreveste ou em que confias a sério, limita cada um aos dados e às ações mínimas de que precisa, mantém um inventário na configuração de MCP, e nunca ligues um servidor com credenciais de produção a um ambiente que corre código não confiável. Trata as descrições e as respostas das ferramentas como input não confiável.

5. Mantém um humano no circuito do código gerado. Trata a saída do agente como um rascunho, não como uma implementação final. Faz passar todo o código gerado ou alterado por revisão de pull request e testes automatizados, com escrutínio redobrado na autenticação, na validação de input, nas queries SQL e nos caminhos privilegiados. Um agente que produz milhares de linhas por dia produz falhas subtis mais depressa do que elas vêm à tona sozinhas.

6. Analisa o código gerado por IA com SAST no CI. Como só uma 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 nas descobertas de alta severidade (injeção de SQL, XSS, autorização em falta) e aproveita os resultados 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 orientada para a segurança o faz.

7. Governa as dependências e os pacotes. Restringe as instalações a registries de confiança ou a mirrors internos, exige aprovação para pacotes novos e passa tudo por análise de composição de software. Não deixes o agente instalar sozinho pacotes obscuros, por mais confiança que mostre ao sugeri-los, e confirma que um pacote sugerido existe mesmo antes de o adicionares.

8. 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 na saída, e nunca deixes ficheiros de credenciais onde a indexação lhes chegue. Se um segredo aparecer alguma vez num log, num ficheiro gerado ou num commit, faz a rotação desse segredo de imediato e investiga como lá foi parar.

9. Corre o trabalho arriscado em ambientes isolados e de privilégio mínimo, e define a política por sensibilidade. Usa contentores ou VMs isoladas para o trabalho assistido por IA sobre código não confiável, corre o Windsurf 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. A sandbox do Devin Local, ao nível do sistema operativo, limita os ficheiros e os domínios a que os comandos dele chegam, e os administradores Enterprise podem impô-la. Classifica os repositórios (público, interno, regulado, produção) e aplica controlos mais rigorosos aos sensíveis, mantendo os sistemas críticos fora de qualquer caminho direto para credenciais de produção.

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

Volta a percorrer os riscos e surge um padrão. A Zero Data Retention, o ficheiro ignore, as regras de permissão e o SAST atuam todos sobre o que o agente já decidiu fazer, ou sobre código que já escreveu. Concentram-se à volta do pull request, porque foi sempre aí que a AppSec viveu. Mas o PR só foi um ponto de controlo porque um humano o lia, e à cadência do agente ninguém o lê de uma ponta à outra.

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 agente 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 Windsurf (e também o Claude Code, o Cursor, o OpenAI Codex e o VS Code Copilot) a quatro camadas de governação que correm dentro do ciclo do agente.

npx -y @cybedefend/vibedefend@latest installEscolher EU ou US, confirmar WindsurfColocar .cybedefend/config.json no repositórioO próximo prompt está governado

As quatro camadas tratam de modos de falha diferentes. As Regras de Negócio são as convenções do teu repositório que nunca foram escritas (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 agente antes de cada edição. As Regras de Segurança levam o OWASP Top 10, o SOC 2, o RGPD e a ISO 27001 para dentro do código à medida que é escrito, de modo que o requisito do framework passa a fazer parte do código em vez de ser uma caixa a assinalar na altura da auditoria. O Action Guard funciona no Windsurf através dos hooks do editor, que cobrem a escrita e a leitura de ficheiros e os comandos de shell: o VibeDefend serve as regras antes de cada edição, e o guard pode travar uma escrita de ficheiro que não cumpra as regras antes de chegar ao disco, uma leitura em bruto de um ficheiro .env, ou um sudo rm -rf ou um psql ad-hoc contra um host de produção antes de correr, com aviso ou bloqueio conforme a regra, e cada interceção fica no registo de auditoria. O Windsurf não tem hook para pedidos web e não filtra as chamadas a ferramentas MCP: para essas, um excerto do .windsurfrules pede ao agente que verifique primeiro, o que funciona enquanto o modelo seguir o seu ficheiro de regras. O Live Findings liga o agente à plataforma de segurança de código da CybeDefend, cujos scanners (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD) correm continuamente, de modo que o agente não só escreve código seguro, como faz a triagem e corrige as vulnerabilidades que já tens. Quanto ao destino do teu código: os action guards decidem no teu portátil, antes de uma ação 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. As duas regiões são fisicamente separadas, e o teu código nunca é usado para treinar um modelo.

Perguntas frequentes

O Windsurf é seguro?

O Windsurf é seguro de usar quando está configurado e contido, e arriscado quando não está. A atestação SOC 2 e FedRAMP, a Zero Data Retention, os ficheiros ignore e as regras de permissão evitam uma classe real de fugas de dados e de acidentes. O risco residual vem do código que o agente gera (só uma fração é segura logo à partida), dos inputs (injeção de prompt em ficheiros, páginas web e saída de ferramentas MCP), dos servidores MCP que ligas e do ambiente à volta (segredos expostos, repositórios não confiáveis, modos de aprovação automática). Trata-o como um agente poderoso que precisa de exclusão de segredos, controlo de comandos, validação de servidores, revisão humana e SAST, e não como uma ferramenta segura logo à partida.

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

Sim. As funcionalidades de IA do Windsurf enviam código para uma API externa para gerar respostas, o que pode incluir o conteúdo de ficheiros e o contexto à volta da tua tarefa. O que acontece a seguir depende do teu plano. O Windsurf mantinha o código fora dos servidores por omissão nos planos Teams e Enterprise; desde a passagem para o Devin, a Cognition diz que os teus dados podem ser usados para treino a menos que um plano pago faça opt-out na página Data Controls, o que também ativa a Zero Data Retention junto dos fornecedores de modelos, e os dados Enterprise nunca são usados para treino sem consentimento por escrito. Para lógica de negócio sensível, confirma esse opt-out, exclui do contexto os segredos e os dados regulados com .devinignore, e compara a política de tratamento de dados da Cognition com os teus próprios requisitos. Uma camada de governação como o VibeDefend também envia algum código: um excerto curto para servir as regras e os ficheiros alterados para a análise feita antes do commit, para a região da UE ou dos EUA que escolhes na instalação, e esse código nunca é usado para treinar um modelo.

O que é o Windsurf Cascade, e é um risco de segurança?

O Cascade era o agente do Windsurf: lia o repositório, editava vários ficheiros, corria comandos no terminal e chamava ferramentas MCP para concluir uma tarefa descrita em linguagem natural. Desde 8 de setembro de 2026 já não existe no editor, agora Devin Desktop: foi substituído pelo Devin Local, que faz o mesmo trabalho sob regras Allow, Ask e Deny. Nenhum dos dois é um risco em si, mas ambos mudam o modelo de risco, porque agem em vez de propor sugestões que um humano aceita. As perguntas de segurança passam a ser o que o agente pode executar, que código gera e quem consegue influenciar as instruções que recebe. Mantém as regras de permissão apertadas, os servidores MCP validados, o contexto livre de segredos e a saída do agente sob revisão humana e SAST.

Como protejo os servidores MCP no Windsurf?

Trata cada servidor MCP como uma fronteira de confiança. Usa servidores que escreveste ou que vêm de fornecedores em que confias a sério, limita cada um aos dados e às ações mínimas de que precisa, e valida tudo o que um servidor devolve em vez de deixar o agente agir diretamente sobre isso. Mantém um inventário na configuração de MCP, para que um pacote fraudulento ou com typosquatting não passe despercebido, nunca ligues um servidor com credenciais de produção a um ambiente que corre código não confiável, e lembra-te de que uma descrição de ferramenta envenenada é, por definição, injeção de prompt: a ligação faz parte da tua superfície de ataque antes mesmo de qualquer ferramenta ser chamada.

O Windsurf pode correr comandos ou código automaticamente?

Por omissão, o agente pede autorização antes de correr um comando de shell ou de escrever num ficheiro, e as regras Allow deixam passar sem perguntar os comandos que escolheres. O risco aparece quando esse passo de aprovação desaparece, seja por fadiga de aprovações (clicar em "permitir sempre" até o valor por omissão se tornar uma autorização geral), seja por passares para o modo Bypass, em que o agente corre cada chamada sem parar (o Cascade chamava-lhe Turbo). Mantém as regras apertadas, proíbe os comandos destrutivos e os que mexem em credenciais, e deixa o Bypass desligado em qualquer ambiente com acesso a dados reais ou a hosts de produção.

A Zero Data Retention chega para tornar o Windsurf seguro?

Não, e convém ser preciso. A Zero Data Retention é um controlo de dados: limita onde o teu código fica guardado e se é usado para treino. Nada diz sobre a segurança do código que o agente gera, sobre a possibilidade de uma injeção de prompt desviar o agente, ou sobre a possibilidade de um servidor MCP ser malicioso. A Zero Data Retention protege os teus dados; não protege a tua aplicação. Continuas a precisar do .devinignore, de regras de permissão apertadas, de servidores MCP validados, de SAST, de revisão humana e de um controlo no momento do prompt.

Em que é que a segurança do Windsurf difere do Cursor ou do Claude Code?

Os fundamentos são comuns (privilégio mínimo, exclusão de segredos, revisão humana, análise de dependências), mas as superfícies são diferentes. A superfície própria do Windsurf é o quanto o agente dele depende do MCP, o que faz da configuração de MCP e do envenenamento de ferramentas o primeiro risco a modelar; o Cursor saiu com o Workspace Trust desativado por omissão e gera uma taxa elevada de código inseguro; o Claude Code tem uma integração profunda com o MCP e com a shell, com permissões por níveis. Os três têm a mesma lacuna: os controlos integrados concentram-se no pull request, quando a regra tem de chegar ao agente no momento do prompt. A correção comum é uma camada de governação no momento do prompt como o VibeDefend, ou marca uma sessão para a veres no teu próprio repositório.