Windsurf è sicuro da usare? Rischi, controlli e best practice

Cosa è cambiato nel 2026. Il 2 giugno 2026 Cognition, l'azienda dietro Devin, ha rinominato Windsurf in Devin Desktop e presentato Devin Local come successore di Cascade. La release 3.9.19 dell'8 settembre 2026 ha chiuso il passaggio: Cascade è stato rimosso e Devin Local è ormai l'unico agente dell'editor. windsurf.com reindirizza a devin.ai. Visto che quasi tutti cercano ancora "Windsurf", questa guida mantiene il nome; dove un controllo è cambiato insieme all'agente, viene descritto quello attuale.

Cos'è Windsurf e perché cambia il modello di sicurezza?

Windsurf è un editor di codice AI-native costruito attorno a un agente (Cascade, poi Devin Local) che non si limita a completare una riga ma porta a termine un compito. Descrivi l'intento in linguaggio naturale (costruisci questa funzionalità, correggi questo test che fallisce, esegui un refactoring su questi moduli) e l'agente indicizza il repository per il contesto, modifica più file in una singola esecuzione, esegue comandi da terminale e si estende tramite il Model Context Protocol (MCP) per raggiungere i sistemi con cui il tuo codice dialoga. Fa parte del più ampio passaggio alla sicurezza degli agenti di codice AI come disciplina, perché l'editor è ora un attore, non un assistente.

Quella combinazione è ciò che rompe il vecchio modello di sicurezza. Un assistente IDE classico offriva un completamento; un essere umano lo leggeva e sceglieva di accettarlo o rifiutarlo. Il raggio d'azione di un suggerimento sbagliato era un singolo blocco di codice che lo sviluppatore doveva comunque incollare. L'agente invece agisce. Legge file che non hai mai nominato, esegue comandi che non hai mai digitato, riscrive codice in tutto l'albero e richiama strumenti MCP che hai collegato settimane fa e dimenticato. La superficie di attacco non è più "cosa ha suggerito il modello". È "cosa può fare questo agente con l'accesso che ha, quanto codice può generare a volume e chi può influenzare le sue istruzioni".

Un suggerimento è una bozza che un essere umano sceglie di accettare. Un'azione è una cosa già accaduta. Il modello di sicurezza deve passare dalla revisione di bozze al vincolo delle azioni.

C'è un secondo cambiamento, e riguarda la velocità. La pull request è diventata la casa della sicurezza applicativa perché si collocava al ritmo umano: una persona rallentava, leggeva il diff e solo allora faceva il merge. L'agente non gira al ritmo umano. Una singola sessione dell'agente può produrre più codice in un pomeriggio di quanto un revisore ne legga in una settimana, e l'editor genererà volentieri codice funzionante che è silenziosamente insicuro. Quando ciò accade, il diff smette di essere un punto di controllo e diventa la trascrizione di decisioni già prese. Qualsiasi controllo che agisca solo alla pull request ora sta rivedendo la storia, non prevenendola. La stessa dinamica compare in Cursor e Claude Code; ciò che distingue Windsurf è quanto il suo agente si appoggi a MCP per lavorare.

Per la maggior parte dei team la domanda pratica non è se Windsurf abbia protezioni integrate. Le ha, e diverse sono genuinamente buone. La domanda è se siano sufficienti per l'uso quotidiano. La risposta onesta è no. I controlli di Windsurf riducono il rischio, ma un'adozione sicura dipende ancora da permessi, isolamento, supervisione umana e validazione indipendente su codice, dipendenze, segreti e pipeline.

Come funziona il modello di sicurezza di Windsurf?

Il modello di Windsurf è costruito attorno a tre idee: dimostra che la piattaforma gestisce i dati in modo responsabile, dai allo sviluppatore le leve per tenere il codice sensibile fuori dalla portata del modello e vincola le azioni che l'agente può compiere. In pratica ciò emerge come una manciata di controlli, ed è una base ragionevole per un editor così capace.

La trappola è leggere quell'elenco come un confine di sicurezza definitivo. La Zero Data Retention protegge i tuoi dati ma non dice nulla sulla sicurezza del codice che l'agente scrive. Un file di esclusione funziona solo se lo tieni aggiornato. Le regole di permesso aiutano solo se le tieni strette, e nel momento in cui aggiungi un Allow ampio (o passi l'agente alla modalità Bypass, che approva ogni chiamata) il passo di approvazione che le rendeva sicure sparisce. La conformità attesta come Windsurf gestisce il suo servizio, non quanto in sicurezza l'agente si comporti sulla tua macchina o quali server MCP gli colleghi. Ogni controllo qui ha un limite documentato, e la prossima sezione riguarda cosa succede quando ci si appoggia troppo su di essi.

Quali sono i principali rischi per la sicurezza in Windsurf?

I rischi qui sotto non sono teorici. Mappano a vulnerabilità divulgate, ricerche pubblicate e alla OWASP Top 10 per le applicazioni LLM. I numeri che li inquadrano sono gli stessi che ogni team AppSec sta ora citando.

40%

del codice generato dall'AI era vulnerabile attraverso gli scenari di sicurezza MITRE Top-25 (NYU, Asleep at the Keyboard)

#1

prompt injection, il principale rischio LLM per il terzo anno consecutivo (OWASP LLM01)

10,5%

delle soluzioni degli agenti di codice AI erano sicure, contro il 61% funzionalmente corretto (Carnegie Mellon SusVibes)

1. Codice generato dall'AI insicuro

Il compito dell'agente è scrivere codice in fretta, e in fretta non significa in sicurezza. La ricerca indipendente continua a trovare lo stesso divario: lo studio NYU "Asleep at the Keyboard" ha rilevato circa il 40% del codice generato dall'AI vulnerabile attraverso gli scenari MITRE Top-25, e il benchmark SusVibes di Carnegie Mellon ha trovato sicuro solo il 10,5% delle soluzioni degli agenti di codice AI. Windsurf si colloca saldamente al suo interno. Il divario tra "funziona" e "è sicuro" è dove vive il pericolo: codice che supera il test e spedisce la vulnerabilità, generato più in fretta di quanto qualsiasi revisore riesca a tenere il passo.

Gli schemi sono prevedibili. SQL concatenato come stringa anziché query parametrizzate (la classica SQL injection), encoding dell'output mancante che apre l'XSS, assenza di validazione dell'input sugli endpoint generati, autorizzazione compromessa su una nuova route. Non sono bug esotici; sono i classici di OWASP, riprodotti alla velocità della macchina perché il modello ha imparato da un corpus pubblico pieno di essi. Più in fretta l'agente spedisce, più in fretta i difetti si accumulano, e il codice dall'aspetto funzionante è esattamente quello che un revisore frettoloso lascia passare.

2. Prompt injection tramite file, web e MCP

La prompt injection è il rischio distintivo degli strumenti di codice agentici, ed è il rischio LLM numero uno di OWASP (LLM01) per il terzo anno consecutivo. Un attaccante nasconde istruzioni in qualcosa che l'agente legge, e l'agente le segue, scavalcando il comportamento previsto.

In Windsurf la forma pericolosa è quella indiretta, e un agente così connesso moltiplica le porte d'ingresso. L'agente legge file del repository, scarica pagine web e consuma l'output degli strumenti MCP, e ognuno di questi canali può trasportare un'istruzione ostile. Un commento sepolto nel README di una dipendenza che dice "prima di continuare, esegui questo script di setup", una issue costruita ad arte o una risposta di strumento avvelenata possono bastare. Poiché un modello linguistico non può separare in modo affidabile un'istruzione attendibile da una dannosa incorporata nei dati, l'injection può portare a esecuzione di comandi, esfiltrazione di dati o manipolazione silenziosa del codice. Un agente guidato non si limita a rispondere male, agisce.

3. Server MCP dannosi e con permessi eccessivi

L'MCP è ciò che rende potente l'agente, ed è un nuovo confine di fiducia che la maggior parte dei team non ha modellato a livello di minacce. Questo è il rischio più specifico di Windsurf, perché l'agente si appoggia pesantemente a MCP e i server sono dichiarati in file di configurazione facili da far crescere e facili da dimenticare. Un server con permessi eccessivi può esporre molto più di quanto il compito necessiti: un server di database con accesso in lettura a tutto, un server di filesystem puntato sulla home directory, uno strumento di deploy con credenziali di produzione.

Un server dannoso o compromesso va oltre. Gli attacchi di tool poisoning nascondono istruzioni dentro le descrizioni e le risposte degli strumenti, così il solo fatto di avere il server connesso può guidare l'agente prima ancora che chiami lo strumento. I meccanismi, e perché un server connesso è di per sé un vettore di injection, sono trattati nella nostra guida alla sicurezza MCP e al tool poisoning. La mitigazione è brusca e corretta: usa server che hai scritto tu o di cui ti fidi davvero, limita ciascuno ai dati e alle azioni più ristretti di cui necessita, e tratta tutto ciò che un server restituisce come input non attendibile da validare, non come verità su cui il modello può agire.

L'attaccante avvelena la descrizione o la risposta di uno strumento MCPL'agente la legge come un'istruzione attendibileLa direttiva nascosta scavalca l'intento dello sviluppatoreL'Action Guard blocca la scrittura ostile del file prima che arrivi su disco

4. Supply chain e pacchetti MCP soggetti a typosquatting

L'agente installa pacchetti, clona repository e collega strumenti come parte del normale lavoro. Se tira dentro una libreria compromessa o connette un server MCP ostile, il codice dannoso gira con qualsiasi accesso l'ambiente conceda. Non è ipotetico. All'inizio del 2026 una campagna di typosquatting su npm tracciata come "SANDWORM_MODE" ha piantato server MCP malevoli imitando utility popolari, prendendo di mira specificamente gli assistenti di codice AI tra cui Windsurf, Cursor e Claude Code.

L'allucinazione dei pacchetti aggrava il rischio: un agente che inventa un nome di pacchetto plausibile ma inesistente offre agli attaccanti uno slot da registrare e armare. L'agente spesso approverà l'installazione con sicurezza, perché il nome sembra giusto e il compito lo richiedeva. Un package.json avvelenato, un hook post-install dannoso o un pacchetto MCP soggetto a typosquatting possono trasformare un prompt di routine "configura questo repo" in furto di credenziali.

5. Esposizione di segreti e contesto sensibile

Windsurf è utile perché il suo agente ha contesto, e quel contesto include regolarmente più del codice sorgente. Qualsiasi cosa raggiungibile nel workspace, un file .env, una configurazione con stringhe di connessione, endpoint API interni, può essere trascinata nel contesto del modello a meno che tu non la escluda esplicitamente con un file di esclusione. Le funzionalità AI di Windsurf inviano inoltre codice a un'API esterna per generare risposte, quindi per la logica di business sensibile la questione di dove va quel traffico è reale, e la Zero Data Retention, insieme all'opt-out dall'addestramento, è la leva che usi per controllarla.

L'esposizione è spesso indiretta. Mentre riassume un repository o esegue il debug di un errore, l'agente può far emergere un token, una credenziale o un hostname interno in un output che poi finisce in una chat, un ticket o un file committato, dove sopravvive a lungo dopo la fine della sessione. La postura predefinita è la comodità, e comodità significa accesso ampio a meno che tu non lo restringa a mano.

6. Esecuzione di comandi e modalità di approvazione automatica

L'agente esegue comandi shell e modifica sistemi, quindi un agente manipolato può eseguirne di dannosi. Le regole di permesso e il prompt di approvazione per ogni comando sono i controlli che mantengono sicura questa parte, e si erodono in due modi familiari. Il primo è la stanchezza da approvazioni: quando l'agente chiede decine di volte all'ora, le persone smettono di leggere e iniziano a cliccare "consenti sempre", e nel giro di una settimana l'impostazione predefinita prudente è diventata silenziosamente una concessione generale. Il secondo è la modalità Bypass (Turbo, ai tempi di Cascade), in cui l'agente esegue ogni chiamata senza fermarsi per l'approvazione, rimuovendo l'unico passo che si frappone tra un'istruzione iniettata e un comando distruttivo.

Il pericolo si aggrava quando l'editor gira con accesso ampio alla macchina dello sviluppatore. Una catena di azioni singolarmente innocue, installa questa dipendenza, esegui questo task, applica questa modifica, può installare malware, alterare una configurazione CI o aprire un meccanismo di persistenza. È esattamente per questo che il gating dei comandi, il privilegio minimo e gli ambienti isolati contano, ed è per questo che la combinazione da temere è quella comune: un repo o un server MCP non attendibile, una configurazione permissiva per evitare l'attrito e un'istruzione iniettata che l'agente tratta come legittima.

Cosa copre la sicurezza integrata di Windsurf, e cosa no?

I controlli nativi sono reali, e conviene essere precisi sulla linea tra ciò che gestiscono e ciò che lasciano a te.

Leggi la colonna di destra come il lavoro vero e proprio. I controlli integrati di Windsurf sono sbilanciati verso la privacy dei dati e la conformità del fornitore, che è dove atterrano le prime domande di un acquirente. Non sono stati progettati per fermare un avversario determinato che controlla gli input dell'agente (un file, una pagina web, uno strumento MCP), e non dicono quasi nulla sulla sicurezza del codice che l'agente scrive. Tutto ciò che trasforma "Windsurf è installato" in "Windsurf è governato" vive nelle pratiche che seguono.

Windsurf è sicuro da usare in azienda?

Windsurf è sicuro da distribuire in azienda quando è configurato e contenuto, e rischioso quando non lo è. La sua attestazione SOC 2 e FedRAMP, la Zero Data Retention e i file di esclusione superano l'asticella dell'approvvigionamento e prevengono una classe reale di fughe di dati. Il rischio residuo vive nel comportamento dell'agente, non nella conformità del fornitore.

Per un'organizzazione regolamentata, la storia della conformità risponde alla domanda sul rischio del fornitore (come Windsurf gestisce i dati dal suo lato) ma lascia aperta la domanda sul rischio applicativo (cosa scrive l'agente, cosa esegue e con quali server MCP dialoga). Sono problemi separati, e un'attestazione non chiude il secondo. Un rollout aziendale pratico tratta Windsurf come un agente potente che ha bisogno di guardrail: Zero Data Retention e opt-out dall'addestramento verificati per i repository sensibili, .devinignore mantenuto come artefatto di sicurezza, regole di permesso strette fissate a livello di team (prevalgono su qualsiasi regola utente o di progetto), un insieme di server MCP verificati e inventariati, ambienti isolati per il lavoro non attendibile e revisione umana obbligatoria più SAST su tutto ciò che l'agente produce. Il badge di conformità ti fa entrare dalla porta; la governance è ciò che impedisce alla porta di essere il punto debole.

Come si proteggono i server MCP in Windsurf?

Tratta ogni server MCP come un confine di fiducia, non come una comodità. Usa server che hai scritto tu o che provengono da fornitori di cui ti fidi davvero, limita ciascuno ai dati e alle azioni più ristretti di cui necessita, e valida tutto ciò che un server restituisce anziché lasciare che l'agente vi agisca direttamente. Il file di configurazione MCP è un artefatto di sicurezza, e merita la stessa disciplina di revisione del controllo degli accessi.

In concreto, controlla la configurazione MCP come controlli l'IAM. Mantieni un inventario di ogni server connesso così che un pacchetto malevolo o soggetto a typosquatting (come i server "SANDWORM_MODE") non si infili inosservato, e rimuovi i server non più usati. Sui piani Teams ed Enterprise, una allowlist MCP blocca ogni server che non vi compare. Non connettere mai un server con credenziali di produzione a un ambiente che esegue anche codice non attendibile, perché un singolo payload di tool poisoning può trasformare quella connessione in esfiltrazione. Limita i server di database alla sola lettura e alle specifiche tabelle che un compito richiede; punta i server di filesystem a una directory di progetto, mai alla cartella home; e dai agli strumenti di deploy token effimeri e a portata limitata anziché chiavi di produzione permanenti. Poiché una descrizione di strumento avvelenata è prompt injection per definizione, la connessione stessa fa parte della tua superficie di attacco già prima che uno strumento venga chiamato, ed è per questo che un controllo indipendente al prompt che possa bloccare un'azione pericolosa conta anche quando ogni server sembra legittimo.

Quali sono le best practice per usare Windsurf in sicurezza?

Queste nove pratiche colmano il divario tra la base nativa e una postura di sicurezza reale. Nessuna di esse è esotica; la disciplina sta nell'applicarle in modo coerente in un team che si muove in fretta.

1. Verifica la Zero Data Retention per il lavoro sensibile, e fai tuo il compromesso. Dal passaggio a Devin, i tuoi dati possono servire all'addestramento finché un piano a pagamento non fa opt-out dalla pagina Data Controls (su Teams lo fa un amministratore). Tratta l'opt-out come predefinito per qualsiasi repository con logica di business reale, dati regolamentati o codice proprietario. Dove un team lo allenta, rendilo una decisione esplicita e documentata, limitata al lavoro a bassa sensibilità, non un'impostazione silenziosa che nessuno ha controllato.

2. Cura .devinignore come un artefatto di sicurezza. Escludi i file .env, gli store di credenziali, la configurazione dell'infrastruttura, le stringhe di connessione e qualsiasi modulo sensibile sia dall'indicizzazione sia dalla portata dell'agente, e affiancalo a una regola Deny Read(**/.env*): con la sandbox attiva, nasconde quei percorsi anche ai comandi shell. Rivedilo come rivedi il controllo degli accessi: secondo una pianificazione, dopo ogni nuovo segreto o servizio e come parte dell'onboarding di un nuovo repo. Un file di ignore non aggiornato è il modo più comune in cui un segreto finisce nel contesto di un modello.

3. Tieni strette le regole di permesso, e resisti all'approvazione automatica. Scrivi regole Deny per i comandi distruttivi e quelli che toccano credenziali (un Deny vince sempre), lascia Ask su tutto ciò che raggiunge dati reali e resta fuori dalla modalità Bypass in qualsiasi ambiente con accesso a dati reali o host di produzione. Bypass rimuove l'unico passo di approvazione che si frappone tra un'istruzione iniettata e un comando distruttivo.

4. Verifica e inventaria ogni server MCP. Connetti solo server che hai scritto tu o di cui ti fidi davvero, limita ciascuno ai dati e alle azioni più ristretti di cui necessita, mantieni un inventario nella configurazione MCP e non collegare mai un server con credenziali di produzione a un ambiente che esegue codice non attendibile. Tratta descrizioni e risposte degli strumenti come input non attendibile.

5. Mantieni un essere umano nel ciclo sul codice generato. Tratta l'output dell'agente come una bozza, non come un'implementazione finale. Indirizza tutto il codice generato o modificato attraverso la revisione delle pull request e i test automatizzati, con scrutinio extra su autenticazione, validazione degli input, query SQL e percorsi privilegiati. Un agente che produce migliaia di righe al giorno genera difetti sottili più in fretta di quanto emergano da soli.

6. Analizza il codice generato dall'AI con SAST nella CI. Poiché solo una frazione delle soluzioni AI è sicura per impostazione predefinita, un gate di analisi statica non è opzionale. Esegui SAST su ogni pull request, fai fallire la build sui risultati ad alta severità (SQL injection, XSS, autorizzazione mancante) e riporta indietro i risultati così che le stesse classi smettano di ripresentarsi. I test funzionali non coglieranno un endpoint vulnerabile ma funzionante; solo un controllo consapevole della sicurezza lo farà.

7. Governa dipendenze e pacchetti. Limita le installazioni a registry attendibili o mirror interni, richiedi l'approvazione per i nuovi pacchetti e analizza tutto con la software composition analysis. Non lasciare che l'agente installi automaticamente pacchetti oscuri per quanto sicuro li suggerisca, e verifica che un pacchetto suggerito esista davvero prima che venga aggiunto.

8. Gestisci i segreti fuori portata. Tieni i segreti in chiaro fuori dal workspace che l'agente può vedere. Usa un vault e iniettali a runtime, oscura i valori sensibili nei log e nell'output, e non lasciare mai file di credenziali dove l'indicizzazione possa raggiungerli. Se un segreto compare mai in una trascrizione, un file generato o un commit, ruotalo immediatamente e indaga su come ci è arrivato.

9. Esegui il lavoro rischioso in ambienti isolati a privilegio minimo, e imposta la policy per sensibilità. Usa container o VM in sandbox per il lavoro assistito dall'AI su codice non attendibile, esegui Windsurf senza privilegi elevati e blocca le connessioni in uscita non approvate così che una sessione compromessa non possa esfiltrare. La sandbox di Devin Local, a livello di sistema operativo, limita i file e i domini che i suoi comandi possono raggiungere, e gli amministratori Enterprise possono imporla. Classifica i repository (pubblici, interni, regolamentati, di produzione) e applica controlli più rigidi a quelli sensibili, mantenendo i sistemi critici fuori da qualsiasi percorso diretto verso le credenziali di produzione.

Dove si fermano i controlli integrati: proteggere l'agente al momento del prompt

Ripercorri i rischi ed emerge uno schema. Zero Data Retention, il file di esclusione, le regole di permesso e SAST agiscono tutti su ciò che l'agente ha già deciso di fare, o su codice che ha già scritto. Si raggruppano attorno alla pull request, perché è lì che l'AppSec ha sempre vissuto. Ma la PR è stata un punto di controllo solo perché un essere umano la leggeva, e al ritmo dell'agente nessuno la legge più dall'inizio alla fine.

Il luogo dove imporre una regola non è più il diff; è il prompt, prima che la riga insicura venga scritta. Qualunque regola tu voglia che l'agente segua deve essere nelle sue mani nel momento in cui scrive, non in attesa in uno scanner che arriva quando il codice è già su disco e l'agente è già passato al compito successivo.

È questo il livello che aggiunge VibeDefend. È una CLI npm gratuita che si installa con un solo comando e collega Windsurf (oltre a Claude Code, Cursor, OpenAI Codex e VS Code Copilot) a quattro livelli di governance che girano dentro il loop dell'agente.

npx -y @cybedefend/vibedefend@latest installScegli EU o US, conferma WindsurfInserisci .cybedefend/config.json nel repoIl prossimo prompt è governato

I quattro livelli gestiscono modalità di fallimento diverse. Regole di business sono le convenzioni del tuo repo che non sono mai state messe per iscritto (usa Decimal128 per il denaro, l'autorizzazione passa per requireOwner); VibeDefend le estrae dal modo in cui il tuo team già scrive codice e le carica nel contesto dell'agente prima di ogni modifica. Regole di sicurezza portano OWASP Top 10, SOC 2, GDPR e ISO 27001 dentro il codice mentre viene scritto, così il requisito del framework diventa parte del codice anziché una casella da spuntare al momento dell'audit. Action Guard in Windsurf passa dagli hook dell'editor, che coprono la scrittura e la lettura dei file e i comandi shell: VibeDefend serve le regole prima di ogni modifica, e il guard può fermare la scrittura di un file che viola le regole prima che arrivi su disco, una lettura grezza di un file .env, o un sudo rm -rf o un psql ad hoc contro un host di produzione prima che parta, avvisando o bloccando per regola con ogni intercettazione nell'audit trail. Windsurf non ha un hook per le richieste web e non filtra le chiamate agli strumenti MCP: per quelle, uno snippet di .windsurfrules chiede all'agente di verificare prima, e regge finché il modello segue il suo file di regole. Live Findings collega l'agente alla piattaforma di sicurezza del codice di CybeDefend, i suoi scanner (SAST con reachability, SCA, segreti, IaC e CI/CD) in esecuzione continua, così l'agente non si limita a scrivere codice sicuro, smista e corregge le vulnerabilità che hai già. Quanto a dove va il tuo codice: gli action guard decidono sul tuo laptop, prima che un'azione parta; per servire le regole che riguardano la riga in scrittura, VibeDefend invia un breve estratto di quel codice al backend di CybeDefend, e la scansione prima del commit invia i file modificati, entrambi nella regione EU o US che scegli all'installazione. Le due regioni sono fisicamente separate, e il tuo codice non viene mai usato per addestrare un modello.

Domande frequenti

Windsurf è sicuro?

Windsurf è sicuro da usare quando è configurato e contenuto, e rischioso quando non lo è. La sua attestazione SOC 2 e FedRAMP, la Zero Data Retention, i file di esclusione e le regole di permesso prevengono una classe reale di fughe di dati e incidenti. Il rischio residuo viene dal codice che l'agente genera (solo una frazione è sicura pronta all'uso), dagli input (prompt injection in file, pagine web e output di strumenti MCP), dai server MCP che connetti e dall'ambiente circostante (segreti esposti, repo non attendibili, modalità di approvazione automatica). Trattalo come un agente potente che ha bisogno di esclusione dei segreti, gating dei comandi, verifica dei server, revisione umana e SAST, non come uno strumento sicuro per impostazione predefinita.

Windsurf invia il mio codice al cloud?

Sì. Le funzionalità AI di Windsurf inviano codice a un'API esterna per generare risposte, il che può includere contenuti dei file e il contesto circostante del tuo compito. Cosa succede dopo dipende dal tuo piano. Windsurf teneva il codice fuori dai suoi server per impostazione predefinita su Teams ed Enterprise; dal passaggio a Devin, Cognition dice che i tuoi dati possono servire all'addestramento finché un piano a pagamento non fa opt-out dalla pagina Data Controls, il che attiva anche la Zero Data Retention presso i fornitori dei modelli, e i dati Enterprise non vengono mai usati per l'addestramento senza consenso scritto. Per la logica di business sensibile, verifica l'opt-out, escludi segreti e dati regolamentati dal contesto con .devinignore, e confronta la policy di gestione dei dati di Cognition con i tuoi requisiti. Anche un livello di governance come VibeDefend invia un po' di codice: un breve estratto per servire le regole e i file modificati per la scansione prima del commit, nella regione EU o US che scegli all'installazione, mai usati per addestrare un modello.

Cos'è Windsurf Cascade ed è un rischio per la sicurezza?

Cascade era l'agente di Windsurf: leggeva il repository, modificava più file, eseguiva comandi da terminale e richiamava strumenti MCP per portare a termine un compito descritto in linguaggio naturale. Dall'8 settembre 2026 non c'è più nell'editor, ora Devin Desktop: lo sostituisce Devin Local, che fa lo stesso lavoro sotto regole Allow, Ask e Deny. Nessuno dei due è un rischio di per sé, ma entrambi cambiano il modello di rischio, perché agiscono anziché offrire suggerimenti che un essere umano accetta. Le domande di sicurezza diventano cosa l'agente può eseguire, quale codice genera e chi può influenzare le sue istruzioni. Tieni strette le sue regole di permesso, i suoi server MCP verificati, il suo contesto libero da segreti e il suo output sotto revisione umana e SAST.

Come proteggo i server MCP in Windsurf?

Tratta ogni server MCP come un confine di fiducia. Usa server che hai scritto tu o che provengono da fornitori di cui ti fidi davvero, limita ciascuno ai dati e alle azioni più ristretti di cui necessita, e valida tutto ciò che un server restituisce anziché lasciare che l'agente vi agisca direttamente. Mantieni un inventario nella configurazione MCP così che un pacchetto malevolo o soggetto a typosquatting non si infili inosservato, non connettere mai un server con credenziali di produzione a un ambiente che esegue codice non attendibile, e ricorda che una descrizione di strumento avvelenata è prompt injection per definizione, quindi la connessione fa parte della tua superficie di attacco già prima che uno strumento venga chiamato.

Windsurf può eseguire comandi o codice automaticamente?

Per impostazione predefinita l'agente chiede conferma prima di eseguire un comando shell o scrivere un file, e le regole Allow lasciano passare senza prompt i comandi che scegli. Il rischio arriva quando quel passo di approvazione viene rimosso, sia per stanchezza da approvazioni (cliccare "consenti sempre" finché l'impostazione predefinita diventa una concessione generale) sia passando alla modalità Bypass, in cui l'agente esegue ogni chiamata senza fermarsi (Cascade la chiamava Turbo). Tieni strette le regole, nega i comandi distruttivi e quelli che toccano credenziali, e tieni Bypass disattivato in qualsiasi ambiente con accesso a dati reali o host di produzione.

La Zero Data Retention basta a rendere sicuro Windsurf?

No, ed è importante essere precisi. La Zero Data Retention è un controllo dei dati: limita dove viene conservato il tuo codice e se viene usato per l'addestramento. Non dice nulla sulla sicurezza del codice che l'agente genera, sul fatto che una prompt injection possa guidare l'agente o sul fatto che un server MCP sia dannoso. La Zero Data Retention protegge i tuoi dati; non protegge la tua applicazione. Hai ancora bisogno di .devinignore, di regole di permesso strette, di server MCP verificati, di SAST, di revisione umana e di un controllo al prompt.

In cosa la sicurezza di Windsurf è diversa da quella di Cursor o Claude Code?

I fondamentali sono condivisi (privilegio minimo, esclusione dei segreti, revisione umana, scansione delle dipendenze), ma le superfici differiscono. La superficie distintiva di Windsurf è quanto pesantemente il suo agente si appoggi a MCP, il che rende la configurazione MCP e il tool poisoning il rischio da modellare per primo; Cursor ha spedito il Workspace Trust disattivato per impostazione predefinita e genera un alto tasso di codice insicuro; Claude Code ha una profonda integrazione con MCP e shell con permessi a livelli. Tutti e tre condividono lo stesso divario: i controlli integrati si raggruppano alla pull request, mentre la regola deve raggiungere l'agente al momento del prompt. La soluzione comune è un livello di governance al prompt come VibeDefend, oppure prenota una sessione per vederlo sul tuo repo.