Un browser Web sandbox esegue il contenuto Web all'interno di un ambiente browser esplicitamente limitato, quindi una pagina con errori o ostile ha meno modi di influenzare l'host, altri utenti o sessioni successive. Per gli agenti AI, "sandbox" può significare diverse cose: la sandbox del processo di Chromium, un profilo browser separato, uno spazio di lavoro dell'app locale, un contenitore, una macchina virtuale, policy di rete o una sessione remota effimera. È necessario nominare il confine prima di poterlo giudicare.
Cos'è un browser web sandbox?
Una definizione utile è composta da tre parti: il processo del browser è vincolato, lo stato del browser ha un ambito e il sistema circostante limita ciò che la sessione può raggiungere o conservare. Se un prodotto apre solo un URL in un'altra scheda, queste non sono informazioni sufficienti per chiamarlo sandbox di sicurezza. Se avvia un nuovo browser remoto ma fornisce a quel browser ampie credenziali di rete, “effimero” non significa automaticamente a basso rischio.
Chromium stesso separa i processi del browser e del renderer e applica meccanismi sandbox specifici della piattaforma. Un servizio può quindi aggiungere una nuova directory di dati utente, un contenitore o una VM, controlli di rete in uscita, iniezione segreta, montaggi di file, limiti di risorse e smontaggio. Ogni livello protegge una risorsa diversa e presenta una modalità di guasto diversa.
Per gli agenti AI, il modello di minaccia è più ampio del JavaScript dannoso. L'agente può seguire l'inserimento rapido in una pagina, selezionare il controllo sbagliato, esporre un segreto in un modulo, scaricare un file non sicuro o riutilizzare una sessione privilegiata per un'attività non prevista. L'isolamento del browser deve pertanto funzionare con le autorizzazioni dell'agente e i criteri di conferma.
Un agente deve utilizzare una sandbox locale o remota?
Decidi in questo ordine: identità, confine di rischio, scala e infine passaggio di controllo. Il primo requisito non negoziabile deve determinare il percorso.
- Scegli un browser persistente locale quando l'attività deve riutilizzare un accesso autorizzato, un'estensione locale o uno stato legato al dispositivo.
- Scegli una sandbox remota quando le pagine non attendibili devono restare fuori dal dispositivo dell'utente, ogni esecuzione deve iniziare da uno stato pulito o molte sessioni devono funzionare in parallelo.
- Scegli un browser locale o remoto con visualizzazione in tempo reale e passaggio di controllo verificati quando una persona deve ispezionare, autenticare, approvare o interrompere l'esecuzione.
- Scegli un approccio ibrido quando servono sia continuità dell'identità sia isolamento fuori dal dispositivo: mantieni in locale il passaggio che dipende dall'account e invia il lavoro anonimo o su larga scala a sessioni remote usa e getta.
| Fattore decisionale | Browser persistente locale | Sandbox remoto |
|---|---|---|
| Accesso esistente | Può riutilizzare un profilo locale autorizzato o uno stato locale dedicato | Di solito importa, ricrea o inserisce lo stato in base alle regole del provider |
| Conquista umana | Direttamente visibile vicino all'utente | Dipende dal supporto e dalla latenza della visualizzazione live/controllo del provider |
| Isolamento dall'host | Limite browser/profilo; l'host rimane locale | Può aggiungere la separazione di contenitori o VM dall'host dell'utente |
| Concorrenza | Limitato da una macchina e contesa locale | Progettato per flotte fornite, quote e sessioni parallele |
| Custodia | Lo stato e gli artefatti rimangono sul computer dell'utente a meno che non vengano sincronizzati | Stato, traffico e artefatti entrano nell'infrastruttura controllata dal provider |
| Manutenzione | L'utente o il team possiede browser, computer, aggiornamenti e capacità | Il fornitore possiede più infrastrutture; il cliente possiede la politica e l'integrazione |
Quali livelli di isolamento contano davvero?
Valuta almeno sei livelli separatamente. L'isolamento del processo limita ciò che un renderer compromesso può fare ad altri processi. L'isolamento del profilo separa cookie, archiviazione locale, cronologia ed estensioni. L'isolamento del file system limita i percorsi leggibili e scrivibili. L'isolamento della rete controlla destinazioni, DNS, proxy e portata della rete privata. L'isolamento del calcolo aggiunge un contenitore o un limite della VM. L'isolamento del tenant impedisce al browser, ai log, ai segreti o agli artefatti di un cliente di interferire con il carico di lavoro di un altro.
Separare anche il ciclo di vita dall'isolamento. L'eliminazione di una sessione dopo dieci minuti riduce la persistenza, ma non dimostra che la sessione non possa raggiungere una rete sensibile mentre è attiva. Al contrario, uno spazio locale persistente può essere accettabile per un flusso di lavoro con account attendibili ristretti se il profilo, le autorizzazioni dell'agente e l'ambito dell'attività sono intenzionalmente limitati.
In che cosa differiscono lo stato di accesso e la custodia dei dati?
Un browser persistente locale può mantenere cookie, archiviazione locale, certificati client ed estensioni compatibili vicino all'utente. Ciò elimina il lavoro di accesso ripetuto ma aumenta la conseguenza di un accesso eccessivo: un agente può ereditare più stato dell'account di quanto richiesto dall'attività. Preferisci un profilo di lavoro o uno spazio dedicato, consenti solo i siti richiesti e richiedi la conferma per le azioni irreversibili.
Una sandbox remota viene generalmente avviata in modo pulito, quindi riceve lo stato di archiviazione, un flusso di accesso o una persistenza gestita dal provider. Ciò migliora la riproducibilità ma invia parte dello stato del browser e del traffico a un piano di controllo remoto. Esamina la crittografia, la regione, la conservazione, i registri, gli artefatti di riproduzione, l'accesso dei dipendenti, l'isolamento dei sottoprocessi e il comportamento di eliminazione. Non caricare un profilo personale perché un provider supporta un campo relativo allo stato di archiviazione.
La scadenza della sessione rimane il comportamento dell'applicazione. L'MFA, i controlli dei rischi, l'associazione del dispositivo, le modifiche IP e la rotazione dei cookie possono invalidare entrambi i percorsi. Un agente affidabile rileva una sessione scaduta, si ferma prima di agire sulla pagina sbagliata e restituisce il controllo o segue un flusso di riautenticazione approvato.
In cosa differiscono il controllo umano e il debug?
L'esecuzione visibile locale mette il browser accanto all'utente, il che è utile quando una persona deve ispezionare il contesto, risolvere un passaggio di autenticazione o interrompere immediatamente un'azione non sicura. Uno spazio locale dedicato evita inoltre di mescolare le azioni degli agenti in una scheda quotidiana non correlata.
Un ambiente browser remoto può esporre una superficie di sessione live, un flusso di comandi, registri, registrazioni e riproduzioni. Queste funzionalità possono supportare team distribuiti e debug post-esecuzione, ma la latenza di acquisizione, il controllo degli accessi, la conservazione e la disponibilità regionale rimangono specifici dell'implementazione. Verificali nell’esatto ambiente in cui operi.
In un'esecuzione Airbnb autenticata dal vivo, Claude Code ha utilizzato il percorso ego-browser per verificare l'accesso dall'interfaccia utente visibile, cercare a Tokyo dal 20 al 23 ottobre e due ospiti, applicare il filtro Intera casa, aprire due annunci e confrontare i campi visibili mentre lo spazio dedicato rimaneva sotto il controllo dell'agente. Non ha controllato i cookie di sessione né eseguito operazioni di prenotazione, lista dei desideri, messaggistica o account.
La corsa ha confrontato solo ciò che le due pagine erano visibilmente esposte. L'elenco A mostrava un appartamento servito a JPY 58.188 con una valutazione 4.89 da 577 recensioni. L'elenco B mostrava un'unità in affitto a JPY 43.154 con una valutazione 4.9 su 489 recensioni. Entrambe le pagine utilizzavano la stessa dicitura generica "Cancellazione gratuita per 24 ore", quindi l'agente non ha dedotto termini di cancellazione specifici per data senza accedere al pannello di prenotazione.
Una volta terminato il confronto, l'utente ha selezionato Subentra. Lo stesso spazio e lo stesso annuncio sono rimasti aperti, lo stato è cambiato da L'agente ha il controllo a Hai il controllo e l'azione disponibile è cambiata in Ritorna all'agente. Questa è un'osservazione diretta del trasferimento a livello di interfaccia; non stabilisce come si comporterà ogni sito o azione interrotta.
In che cosa differiscono concorrenza, riproduzione e costo?
Un computer locale ha CPU, memoria, display, blocchi del profilo e capacità di rete limitati. È appropriato per il lavoro interattivo o con bassa concorrenza, ma gli agenti paralleli non devono modificare lo stesso profilo contemporaneamente. I servizi remoti possono fornire molte sessioni isolate e centralizzare le registrazioni, ma le quote, il tempo di avvio, i minuti del browser, il traffico proxy, l'archiviazione e le funzionalità di osservabilità influiscono sui costi.
I confronti dei costi richiedono un'unità corrispondente: attività completata, non solo minuti di navigazione grezzi. Include configurazione, nuovi tentativi, traffico proxy, trasferimento CAPTCHA o MFA, creazione dello stato, archiviazione degli artefatti, riproduzione di sessioni non riuscite e tempo dell'operatore. Non disponevamo di dati di telemetria di fatturazione comparabili per questo articolo, quindi non pubblichiamo un vincitore o una tabella dei prezzi.
Cosa ha mostrato il nostro test di persistenza locale?
Abbiamo utilizzato ego-browser 0.5.0.31 con Chromium 152.0.7977.54 in uno spazio ego (lite) dedicato. Un primo processo Claude Code ha completato il confronto Airbnb in sola lettura e ha consegnato lo Spazio all'utente. Dopo che l'utente ha restituito il controllo, un nuovo processo Claude Code ha ripreso Space 12 e ha ispezionato le schede esistenti senza spostarle, ricaricarle o modificarle.
| Controlla | Risultato osservato |
|---|---|
| Stesso spazio trovato dal nuovo processo | Sì, spazio 12 |
| Scheda dei risultati di ricerca di Tokyo mantenuta | Sì, p1 |
| Due schede dei dettagli dell'elenco mantenute | Sì, p2 e p3 |
| L'elenco visibile è rimasto attivo | Sì, p3 |
| È richiesta la navigazione, il ricaricamento o la modifica della scheda | N |
Questa osservazione stabilisce la continuità tra due processi Claude Code su questa macchina: lo stesso spazio, tre schede, etichette, titoli, URL ed elenco attivo sono rimasti disponibili. Non dimostra l'autenticazione indefinita, la persistenza dopo il riavvio del browser o del dispositivo, la compatibilità con ogni sito Web o il comportamento della sandbox remota.
Cosa ha mostrato l'esecuzione del nostro proxy remoto?
Per un controllo neutrale fuori dal dispositivo, abbiamo lanciato Chromium headless in un runtime Google Colab Linux e aperto la stessa ricerca pubblica a Tokyo per il periodo dal 20 al 23 ottobre, due adulti e intere case. Non sono state fornite credenziali Airbnb. Due corse sono terminate in 17.66 e 16.42 secondi. Entrambi hanno restituito HTTP 200, hanno eseguito il rendering degli elenchi e della mappa, hanno estratto gli stessi cinque distinti collegamenti alle stanze e non hanno registrato segnali di blocco.
Ciò riduce il divario tra le prove precedenti: una VM remota pulita ha completato due volte questo sondaggio anonimo sulla pagina pubblica. Non testa ancora l'isolamento multi-tenant, i segreti gestiti dal provider, la riproduzione della sessione, il live takeover, l'uscita geografica, il riutilizzo dell'account o le garanzie di smontaggio. Ciò richiede un ambiente browser remoto gestito con un account autorizzato e un piano di test congelato separatamente.
Quando dovresti utilizzare un'architettura ibrida?
Utilizzare un ibrido quando lo stesso sistema ha zone di fiducia incompatibili. Indirizza un passaggio dipendente dall'account e visibile all'utente a uno spazio locale dedicato e instrada il rilevamento anonimo, le pagine non attendibili o il lavoro fan-out di grandi dimensioni a sessioni remote usa e getta. Passa solo il risultato minimo tra le zone, ad esempio un URL pubblico o un record normalizzato anziché un intero profilo del browser.
Un router sicuro considera l'attendibilità del target, l'identità richiesta, la sensibilità dei dati, la concorrenza, l'uscita geografica, i requisiti di acquisizione e se un API ufficiale può sostituire il funzionamento del browser. Dovrebbe negare un'attività quando nessun percorso soddisfa la politica piuttosto che scegliere silenziosamente il browser più privilegiato.
Che aspetto ha un'integrazione minima?
Un percorso locale crea uno spazio di lavoro del browser dedicato, esplora una pagina esistente, esegue l'attività delimitata, convalida il risultato e chiude le pagine create dall'agente. Il percorso remoto richiede una sessione al provider, connette un client di automazione, esegue la stessa attività, memorizza solo gli artefatti richiesti e termina la sessione anche in caso di errore.
route = policy.choose({
targetTrust, requiredIdentity, concurrency, takeover
})
if (route === "local") {
runInDedicatedVisibleSpace(task)
} else if (route === "remote") {
session = await sandbox.create({ ttl, egressPolicy })
try { await runTask(session.endpoint) }
finally { await sandbox.terminate(session.id) }
} else {
throw new Error("No safe browser route")
}Il codice di produzione deve inoltre impostare timeout, chiavi di idempotenza, origini consentite, quarantena dei download, ambito segreto, conservazione degli artefatti e un record di controllo che non contenga credenziali non elaborate.
Come si convalida una sandbox del browser?
- Scrivere il modello della risorsa e dell'autore dell'attacco: file host, rete interna, credenziali, un altro tenant, sessioni successive e operatore umano.
- Mappatura separata di processo, profilo, file system, rete, elaborazione, tenant e ciclo di vita del browser.
- Esegui un'attività canary che tenta solo le letture e le scritture di test approvate, quindi dimostra che i percorsi host e le destinazioni vietati rimangono inaccessibili.
- Verifica il comportamento di avvio pulito e persistenza con marcatori non segreti denominati. Conferma che lo smontaggio rimuove effettivamente lo stato previsto.
- Scadenza del test, arresto anomalo, nuovi tentativi, perdita di controllo, popup, download e percorsi di accesso interrotti.
- Convalida l'acquisizione e la revoca in tempo reale con l'utente effettivo e la policy di accesso, non con uno screenshot di marketing.
- Controlla elementi, registri, riproduzioni, backup e supporta l'accesso rispetto alla politica di conservazione.
- Ripeti in una concorrenza realistica e registra il costo delle attività completate solo quando tutti i denominatori sono disponibili.
Dove si adatta ego (lite)?
ego (lite) è un browser locale basato su Chromium, progettato per consentire a persone e agenti AI di lavorare insieme; come categoria di prodotto, è un browser per agenti AI. Non è un agente AI, un'estensione di Chrome, un browser remoto nel cloud o un framework di automazione come Playwright. Puoi usarlo come browser di tutti i giorni, mentre agenti compatibili come Claude Code, Codex, Cursor e Gemini CLI lo controllano tramite ego-browser. ego (lite) è attualmente disponibile su macOS e può importare da Chrome schede, segnalibri, password, estensioni, cookie, sessioni di accesso e profili. Ogni attività dell'agente viene eseguita nel proprio Space, dove puoi osservarla, metterla in pausa o assumerne il controllo in qualsiasi momento.
Per questo ego (lite) è adatto alle attività nel browser che dipendono da una sessione autorizzata, per esempio cercare informazioni, organizzare contenuti o compilare moduli in Gmail, Notion, LinkedIn, strumenti interni o pannelli di amministrazione SaaS a cui hai già effettuato l'accesso. È indicato anche per flussi visibili e interrompibili, come ricerche su più pagine, confronti di prezzi, test del browser e attività più lunghe, oltre che per il lavoro in parallelo: più agenti possono usare Space separati mentre tu continui a navigare nelle tue schede. Poiché il browser viene eseguito in locale, è adatto anche a team e singoli utenti che non vogliono affidare cookie e sessioni di navigazione a un browser cloud in hosting e hanno bisogno che le attività usino la propria rete, VPN o proxy. Scegli invece un sandbox remoto o un'architettura ibrida quando il requisito decisivo è l'isolamento remoto multi-tenant, un gran numero di sessioni usa e getta, l'uscita di rete controllata dal provider o la completa separazione delle pagine non attendibili dal computer locale. Se un'API ufficiale o una normale richiesta HTTP può completare l'attività, il browser potrebbe non essere necessario.
Quali fonti definiscono questo confronto?
Per il limite del processo browser, leggereDesign sandbox di Chromium. Per la separazione a livello di sessione, leggi Playwrightguida all'isolamento del contesto del browser. Per i limiti dell'host e del contenitore, leggere Dockerpanoramica sulla sicurezza del motore. Queste fonti definiscono i livelli di isolamento e le primitive di test. Non dimostrano che un particolare servizio ospitato implementi correttamente ogni confine.
Domande frequenti
La modalità di navigazione in incognito è una sandbox del browser?
La navigazione in incognito modifica principalmente la cronologia locale e la persistenza dell'archiviazione. Di per sé non aggiunge una VM, un limite del tenant, una lista consentita di rete o la protezione da un agente con privilegi eccessivi.
Un sandbox remoto è sempre più sicuro?
N. Può isolare il lavoro dal computer dell'utente, ma la sicurezza dipende comunque dalla separazione degli inquilini, dalla portata della rete, dai segreti, dalla custodia del fornitore, dalla conservazione e dalle azioni consentite dell'agente.
Un browser locale può riutilizzare i miei dati di accesso?
Un profilo locale dedicato o uno stato importato autorizzato può preservare cookie e archiviazione, in base alla politica del sito, alla scadenza, all'AMF e alla compatibilità del prodotto. Utilizzare il profilo più stretto che soddisfa l'attività.
Ogni agente deve essere eseguito in un nuovo browser?
Le nuove sessioni sono utili per lavori non attendibili o ripetibili. Le sessioni persistenti sono giustificate quando la continuità dell'identità fa parte dell'attività e le autorizzazioni sono intenzionalmente limitate.