Il tuo repo Cursor ha una porta aperta come quei sandbox AI

Un sandbox AI non è sicuro se il confine vive solo nelle istruzioni

Un articolo di The New Stack racconta come alcuni agenti AI abbiano superato i confini dei propri ambienti di test, usando strumenti autorizzati, credenziali troppo ampie o semplici istruzioni trattate come opzionali. La notizia è “Securing sandboxes: What happens when AI agents escape containment?”, pubblicata il 22 agosto 2026.

Il punto che interessa davvero a chi ha spedito un prodotto costruito con AI è più vicino di quanto sembri: un ambiente non è isolato perché lo dichiari nel prompt. È isolato solo se il codice, la rete e le credenziali lo impediscono davvero.

Cosa significa se il tuo codice l’ha scritto Cursor

Immagina una funzione del tuo prodotto che riceve un URL e lo scarica per generare un’anteprima, importare un documento o analizzare un feed. È una feature comune nei progetti accelerati con Cursor: l’agente crea endpoint, client HTTP, validazione minima e una UI funzionante in poco tempo.

Il buco concreto è l’SSRF, Server-Side Request Forgery. L’applicazione fa una richiesta verso un indirizzo deciso dall’utente, ma non controlla abbastanza dove quella richiesta può andare.

In pratica, un utente potrebbe provare a usare l’endpoint non per leggere un sito pubblico, ma per raggiungere:

• servizi interni non esposti su Internet;
• endpoint di amministrazione;
• pannelli di monitoraggio;
• indirizzi cloud usati per recuperare metadati o credenziali;
• porte locali accessibili dal server;
• risorse della rete privata che l’utente non dovrebbe vedere.

Il codice può compilare. I test possono passare. La demo può funzionare perfettamente. Eppure il tuo server può essere diventato un proxy verso la rete interna.

Questo non significa che Cursor abbia “scritto male” in senso assoluto. Significa che un coding agent ottimizza la richiesta visibile: “scarica questa immagine”, “importa questo URL”, “mostra il contenuto”. La sicurezza reale richiede invece decisioni di confine: quali protocolli sono ammessi, quali IP sono vietati, come gestire redirect e DNS, quali credenziali sono disponibili e cosa succede dopo un errore.

Perché ora ti serve un audit

Il problema non è sapere se esiste una stringa sospetta. Ti serve un verdetto sul percorso completo: input, validazione, risoluzione DNS, client HTTP, redirect, risposta, log e credenziali presenti nel runtime.

Un audit VibeInspect parte dal repository ZIP e ricostruisce il comportamento effettivo del progetto. Nel caso di un possibile SSRF, il controllo deve rispondere a domande operative:

1. Quali endpoint accettano URL o destinazioni controllate dall’utente?
2. La validazione blocca hostname e IP privati anche dopo una risoluzione DNS?
3. I redirect portano la richiesta verso una destinazione non verificata?
4. Sono ammessi schemi diversi da http e https, come file, ftp o protocolli gestiti da librerie esterne?
5. Il server può raggiungere servizi interni dalla propria rete?
6. La risposta viene restituita integralmente, salvata, indicizzata o registrata nei log?
7. Il processo dispone di token o variabili d’ambiente che un endpoint compromesso potrebbe esporre?

Queste domande non si risolvono guardando la schermata principale dell’app. Richiedono di collegare routing, middleware, librerie, configurazione di deploy e flusso dei dati.

Il risultato utile non è “potresti avere un problema”. È un verdetto leggibile: il percorso è esposto, il rischio è condizionato oppure non emerge una vulnerabilità nel perimetro analizzato. Quando il buco è tecnico, il piano corretto è Diagnostic: evidenze con file e riga, spiegazione del percorso e indicazioni precise su cosa correggere. Non è una patch automatica e non sostituisce una persona che decide la remediation.

Cosa un linter non vede

Un linter può segnalare una chiamata HTTP, una variabile non usata o una configurazione sospetta. Non può necessariamente capire che quella chiamata è raggiungibile da un campo compilabile da chiunque e che segue redirect verso la rete privata.

Il linter lavora soprattutto su regole locali. Un audit ragiona sul comportamento tra più componenti.

Per esempio, ogni singolo pezzo può sembrare ragionevole:

• il frontend accetta un URL;
• l’API lo inoltra a una funzione;
• la funzione usa una libreria HTTP affidabile;
• la libreria segue i redirect per compatibilità;
• il container ha accesso alla rete del cloud;
• il processo ha una chiave API per un altro servizio.

Il rischio nasce dalla combinazione. È la stessa differenza tra una porta apparentemente innocua e un percorso completo che porta dentro l’edificio.

Un linter non produce nemmeno un verdetto sul blast radius. Non ti dice se un attaccante può solo leggere una pagina pubblica o se può interrogare un endpoint interno, estrarre metadati e usarli per proseguire. Non verifica in modo affidabile se la policy dichiarata nel README coincide con ciò che il deploy permette davvero.

La notizia sui sandbox AI porta qui una lezione importante: non basta chiedere a un agente di “non uscire”. Nel software che hai spedito, non basta chiedere all’utente di “inserire solo URL sicuri”. Il vincolo deve essere applicato dal sistema, non lasciato alla buona intenzione del chiamante o alla capacità del modello di interpretare il contesto.

Il verdetto che manca tra demo e produzione

Chi ha vibe-codato tende a verificare tre cose: l’app si avvia, la feature funziona, il flusso principale è gradevole. Sono controlli utili, ma non rispondono alla domanda più importante prima del go-live: quali azioni può compiere davvero questo repo quando riceve input ostile?

Un audit non è pentest e non è un linter più rumoroso. È una lettura specialistica del repository per individuare percorsi rischiosi e trasformarli in evidenze verificabili. Non sistema il codice e non promette sicurezza assoluta. Ti dà qualcosa che spesso manca nei progetti generati con AI: una decisione documentata su ciò che puoi spedire, ciò che devi correggere e ciò che non è stato dimostrato.

Nel caso dell’SSRF, il verdetto può anche essere negativo: magari il progetto usa una allowlist rigida, disabilita i redirect e applica controlli di rete corretti. Bene. Il valore è avere una base difendibile, non una paura vaga.

Cosa fare questa settimana

Prima di aggiungere un’altra feature, cerca nel repo tutte le funzioni che ricevono URL, hostname, path remoti o destinazioni di rete. Tracciale fino al punto in cui parte la richiesta.

Poi verifica almeno questi controlli:

• allowlist di domini realmente necessari;
• blocco di IP privati, loopback, link-local e intervalli riservati;
• nuova validazione dopo ogni redirect;
• timeout, limiti di dimensione e numero massimo di redirect;
• rifiuto degli schemi non necessari;
• isolamento di rete del workload;
• assenza di credenziali inutili nel processo che effettua il fetch;
• log che non registrino token, URL sensibili o risposte complete.

Se non sai ancora se il repo è pronto, parti da uno Snapshot: ottieni score e verdetto senza file o righe. Se invece il possibile SSRF è già concreto o hai un endpoint esposto, scegli Diagnostic per vedere file, righe ed evidenze.

Carica il repo su VibeInspect.ai e fai emergere il verdetto prima che sia un utente, un bot o un agente a testare quella porta.