Il sandbox non basta più: come Cursor, Codex, Gemini CLI e Antigravity sono stati bypassatiPer mesi il messaggio rassicurante degli editor e delle CLI potenziate da AI è stato semplice: l’agente lavora dentro un sandbox, quindi anche se un prompt injection lo convince a fare qualcosa di malevolo, il danno resta confinato al workspace. Il team di ricerca di Pillar Security ha appena dimostrato, in una serie di sette advisory pubblicate come “The Week of Sandbox Escapes”, che questa assunzione è sbagliata per almeno quattro strumenti molto usati da sviluppatori e sistemisti: Cursor, OpenAI Codex CLI, Google Gemini CLI e Antigravity.La cosa interessante, e preoccupante, è che in nessuno dei casi l’agente ha attaccato direttamente il confine del sandbox. Ha semplicemente scritto un file che uno strumento fidato, esterno al sandbox, ha poi eseguito, caricato o scansionato per conto proprio.Il vero confine non è il processo dell’agenteIl modello mentale comune è: “dentro il workspace l’agente può fare quello che vuole, fuori è protetto”. Pillar mostra che questo confine ha in realtà tre livelli distinti:Esecuzione diretta: cosa può lanciare il processo dell’agenteScrittura nel workspace: quali file l’agente può creare o modificareFiducia dell’host: cosa fanno i componenti non sandboxati con quei fileÈ il terzo livello a rompersi sistematicamente. Editor e CLI moderni sono pieni di automazioni che girano fuori dal sandbox: estensioni Python che scoprono interpreti, integrazioni Git che scansionano repository, VS Code che carica task file, hook engine che eseguono comandi al lifecycle, Docker Desktop che espone un socket locale privilegiato. Un agente sandboxato può rispettare ogni singola regola che gli è stata imposta e comunque condizionare l’input che questi componenti consumeranno.Le quattro classi di vulnerabilitàI ricercatori raggruppano i sette bug in quattro pattern ricorrenti:1. Sandbox a denylist che non tengono il passo del sistema operativoIl caso più chiaro è la sandbox Seatbelt di Antigravity su macOS: un profilo “allow by default” deve ricordarsi di bloccare ogni singola funzionalità pericolosa del sistema operativo. Come scrive Pillar, “non è un sandbox, è una lista di cose che qualcuno si è ricordato di bloccare, sempre corta di una voce”.2. Configurazioni di progetto che sono a tutti gli effetti codice eseguibileDiversi bug non sono breakout classici: l’agente ha scritto file che era autorizzato a scrivere. Il problema è nato dopo, quando l’host ha trattato quei file come configurazione fidata. È il caso dell’hook .claude in Cursor, diventato esecuzione di comandi non sandboxata (ora CVE-2026-48124, corretto nella 3.0.0), o del task config .vscode che Antigravity ha usato per aggirare la sua Secure Mode.3. Allowlist di comandi “sicuri” per nome, non per invocazioneIn Codex CLI, un comando come git show era considerato sicuro perché il nome suggerisce sola lettura. Ma Git ha decine di flag che cambiano completamente il comportamento: possono scrivere file, caricare configurazioni, invocare hook. La domanda giusta, scrivono i ricercatori, non è “git show è sicuro?” ma “quale invocazione esatta viene eseguita, con quali argomenti, in quale directory, contro quale configurazione?”. OpenAI ha corretto il bug nella v0.95.0 e pagato una bounty per severità alta.4. Demoni locali privilegiati fuori dal sandboxIl bug più trasversale riguarda il socket Docker: un demone locale privilegiato raggiungibile da Codex, Cursor e Gemini CLI contemporaneamente, che diventava un ambiente di esecuzione non sandboxato. Sandboxare il processo dell’agente non serve a nulla se lascia aperto un demone con accesso pieno all’host: il confine si sposta semplicemente sull’API del demone.Come si arriva all’exploit: il ruolo del prompt injectionIn tutti i casi il vettore d’ingresso è un’istruzione malevola nascosta in un README, in una issue, in una dipendenza o in un diff, che l’agente legge come input “normale” durante il suo lavoro. Da lì, l’istruzione si trasforma in un’azione locale sulla macchina dello sviluppatore, senza che l’utente abbia mai approvato esplicitamente nulla di sospetto: dal punto di vista dell’agente, ha semplicemente scritto un file di configurazione plausibile in un progetto.Google ha classificato le due vulnerabilità di Antigravity come “Other valid security vulnerabilities”, applicando un downgrade perché richiedono ingegneria sociale o che l’utente si fidi di un repository con prompt injection indiretto — pur riconoscendo, nelle parole dei ricercatori, che uno dei report era “di qualità eccezionale”.Cosa chiedere ai vendor (e cosa verificare in azienda)Per chi gestisce endpoint di sviluppo con strumenti agentici, Pillar suggerisce di andare oltre la domanda “ha un sandbox?” e porsi domande più operative:Cosa può scrivere l’agente, esattamente?Quali componenti dell’host si fidano di quei file?Quali demoni locali privilegiati sono raggiungibili dall’agente?Quali comandi saltano l’approvazione, e perché?La policy valuta il nome del comando o l’invocazione e i suoi effetti reali?Il prodotto distingue file creati dall’utente da file creati dall’agente?Che telemetria esiste quando un componente fidato esegue qualcosa scritto dall’agente?Sul piano pratico, per chi amministra postazioni di sviluppo con Cursor, Codex CLI, Gemini CLI o Antigravity: aggiornate immediatamente alle versioni patchate (Cursor 3.0.0+, Codex CLI 0.95.0+), verificate che l’accesso al socket Docker dagli strumenti AI sia effettivamente ristretto quando non necessario, e trattate le configurazioni di progetto generate o modificabili da un agente (hook, task VS Code, config Git non standard) come superficie di attacco da rivedere in code review, non come dettagli innocui.ConclusioneIl punto centrale della ricerca di Pillar non è la lista dei singoli bug, quasi tutti già corretti, ma il pattern che li accomuna: gli agenti di coding sono diventati attori endpoint a tutti gli effetti, con accesso a codice sorgente, chiavi SSH, token cloud e sessioni browser, e processano di routine input non fidato (README, issue, dipendenze, diff). Un sandbox che protegge solo il processo dell’agente, ignorando cosa scrive e chi si fida di quello che scrive, non è un confine di sicurezza reale. Per chi introduce questi strumenti in azienda, la domanda da porsi non è più “abbiamo attivato il sandbox”, ma “sappiamo tracciare ogni volta che un componente fidato dell’host esegue qualcosa che l’agente ha scritto”.Fonte: Pillar Security, “The Week of Sandbox Escapes” e BleepingComputer.

Cosa cambia con la GA dei browser toolsDal 1° luglio 2026 i browser tools per GitHub Copilot in Visual Studio Code sono generalmente disponibili (GA) e attivi di default. Non si tratta di una semplice estensione per il debugging: gli agenti di Copilot ottengono ora le stesse azioni che un developer compirebbe normalmente in un browser reale — aprire pagine, navigare, cliccare, digitare, gestire dialog, leggere il contenuto del DOM, catturare errori di console e screenshot, fino all’esecuzione di flussi scriptati quando conviene eseguire una sequenza di passi invece di tante singole chiamate a tool.Per chi lavora quotidianamente su applicazioni web — sviluppo frontend, test end-to-end, troubleshooting di regressioni UI — questa funzionalità cambia sensibilmente il flusso di lavoro con l’AI: l’agente può verificare da solo se una modifica ha funzionato, invece di chiedere all’utente di incollare uno screenshot o l’output della console.Cosa può fare davvero l’agente nel browserSotto il cofano, VS Code espone all’agente un set di azioni equivalenti a quelle di uno strumento di automazione come Playwright, ma integrate direttamente nell’editor:Apertura e navigazione di pagine, click, digitazione testo, hover, drag and drop, gestione di dialog nativi del browser.Lettura del contenuto della pagina, cattura degli errori di console e degli screenshot per il debugging visivo.Esecuzione di flussi scriptati quando una sequenza di passi predefinita è più efficiente di singole chiamate a tool separate.Le DevTools restano comunque disponibili direttamente nella toolbar del browser integrato, così lo sviluppatore può ispezionare elementi, leggere la console e fare debug manuale in parallelo a quanto fa l’agente.Il modello di permessi: cosa resta sotto il tuo controlloDare a un agente AI la capacità di pilotare un browser reale solleva ovvie domande di sicurezza. Il team di VS Code ha progettato il modello di permessi attorno a tre principi:Le tue schede restano private di defaultL’agente non può leggere né interagire con una scheda che hai aperto tu finché non selezioni esplicitamente Share with Agent. L’accesso concesso può essere revocato in qualsiasi momento.Le schede dell’agente sono isolateLe pagine che l’agente apre autonomamente girano in sessioni pulite, senza accesso a cookie o storage della tua normale sessione di navigazione. Se esegui più agenti in parallelo nella finestra Agents, ciascuno mantiene le proprie schede private rispetto agli altri.I permessi sensibili restano manualiFotocamera, microfono, geolocalizzazione, notifiche e lettura della clipboard non vengono mai concessi automaticamente: ogni sito richiede un’approvazione esplicita da parte tua, e l’agente non può approvarli al posto tuo. Solo azioni a basso rischio, come la scrittura sanificata sulla clipboard, sono consentite di default.Controlli enterprise e configurazione della retePer chi gestisce flotte di postazioni sviluppatore, VS Code espone controlli centralizzati pensati proprio per governare questa superficie:// settings.json — disabilitare completamente i browser tools
{
 "workbench.browser.enableChatTools": false
}

// Limitare i domini raggiungibili dagli agenti e dal browser integrato
{
 "chat.agent.networkFilter": true,
 "chat.agent.allowedNetworkDomains": [
 "*.miaazienda.it",
 "github.com"
 ],
 "chat.agent.deniedNetworkDomains": [
 "*.pagamenti-esterni.com"
 ]
}La regola pratica da tenere a mente in produzione: gli elenchi di domini negati hanno sempre precedenza su quelli consentiti, ed entrambi supportano wildcard (ad esempio *.example.com). Restano inoltre attivi i normali prompt di Workspace Trust e le approvazioni già previste per gli altri tool dell’agente, quindi l’attivazione dei browser tools non aggira le policy di sicurezza esistenti a livello di workspace.Un caso d’uso pratico: test end-to-end guidato dall’agenteUn flusso tipico che questa funzionalità sblocca è la verifica autonoma di una modifica UI. Dopo aver chiesto a Copilot di correggere un bug nel form di login, si può semplicemente chiedere all’agente di “aprire l’app in locale, compilare il form con credenziali di test e verificare che il redirect alla dashboard funzioni”. L’agente aprirà una scheda browser isolata, eseguirà i passaggi, catturerà eventuali errori di console e screenshot, e riporterà l’esito direttamente in chat, senza che lo sviluppatore debba fare context switch verso il browser.Per team con suite di test end-to-end già basate su Playwright o Cypress, i browser tools non sostituiscono la pipeline CI, ma accorciano il ciclo di iterazione locale: si individua un problema, si corregge, si verifica visivamente, il tutto restando nell’editor.Come iniziareLa funzionalità è disponibile sia nella finestra dell’editor sia nella finestra Agents. È sufficiente aggiornare VS Code all’ultima versione e chiedere all’agente di aprire o testare una pagina: i browser tools sono attivi per impostazione predefinita da GA in poi. Per la documentazione completa, si vedano le pagine ufficiali sui browser tools per gli agenti e la relativa guida al testing con agenti nel browser.ConclusioneIl passaggio a GA dei browser tools segna un salto di maturità per gli agenti AI integrati in VS Code: da assistenti che scrivono codice sulla fiducia, a strumenti capaci di verificare autonomamente il proprio lavoro in un ambiente reale. Per i team enterprise, la combinazione di isolamento delle sessioni, permessi granulari e filtri di rete configurabili rende la funzionalità adottabile anche in contesti con requisiti di sicurezza stringenti, a patto di configurare fin da subito le allowlist di dominio e di rivedere periodicamente chi ha accesso a quali capacità.Fonte: GitHub Changelog — Browser tools for GitHub Copilot in VS Code are generally available