《Openclaw流行下Agent 沙箱架构:从技术选择到普通人能看懂的安全故事》 Due modalità Immagina di dover assumere un guardiano per proteggere la tua casa. Hai due opzioni: Opzione 1: il guardiano vive a casa tua, ma tiene la cassetta degli attrezzi in una cassaforte. Il guardiano può muoversi e vedere la tua casa, ma non ha la chiave. Opzione 2: il guardiano vive in una cabina all'esterno, e non c'è nulla in casa per lui. Se vuole prendere qualcosa, deve chiedere al tuo maggiordomo. La Browser Use Company (che gestisce milioni di Web Agent) ha scelto l'opzione due. La loro storia, in realtà, riguarda ogni persona che utilizza l'AI.
Due, Come si usa il Browser Inizialmente hanno utilizzato la soluzione uno: l'Agent gira sul proprio server, l'esecuzione del codice avviene in una sandbox isolata. Sembra abbastanza sicuro, giusto? Ma c'è un problema: l'Agent stesso è ancora sul server, può vedere le variabili d'ambiente, le chiavi API, le credenziali del database. E se l'Agent decidesse di "rubare qualcosa"?
Tre, quindi hanno riscritto l'intera architettura: • Agente completamente isolato: ogni Agente funziona nella propria micro-VM Unikraft, l'avvio richiede meno di un secondo • Piano di controllo come custode: tutte le comunicazioni esterne (richiesta LLM, archiviazione file, fatturazione) passano attraverso il piano di controllo, che detiene tutte le credenziali • Sandbox ignara: l'Agente riceve solo tre variabili ambientali - token di sessione, URL del piano di controllo, ID della sessione. Nessuna chiave AWS, nessuna credenziale del database • Discardability: l'Agente è morto? Riavvialo. Stato perso? Il piano di controllo ha il contesto completo. Non ha nulla di cui valga la pena rubare e nessuno stato da mantenere.
Quattro, Dettagli tecnici: micro-VM Unikraft per la produzione (scale-to-zero, sospensione quando inattivo), contenitori Docker per lo sviluppo. Lo stesso immagine ovunque. Prospettiva della persona comune: che cosa c'entra con me? Potresti non sapere cosa siano le "micro-VM" o gli "URL prefirmati", ma quando usi l'AI stai interagendo con questo tipo di architettura.
Cinque, Senso di sicurezza: quando utilizzi un servizio AI per scrivere codice o cercare informazioni, in realtà stanno eseguendo la tua richiesta in una VM isolata. Se l'architettura non è progettata bene (opzione uno), teoricamente quell'AI Agent può vedere tutti i segreti del fornitore del servizio: password del database, chiavi API, dati di altri utenti.
Sei, Costo e velocità: la soluzione due ha un costo - ogni operazione richiede un ulteriore salto di rete. Ma rispetto al tempo di risposta del LLM, questo ritardo è quasi trascurabile. Più importante è che, quando l'Agent è inattivo, la VM è sospesa, il costo è vicino a zero. Privacy dei dati: come vengono memorizzati i tuoi file? La sandbox richiede un URL presigned al piano di controllo e poi carica direttamente su S3. Durante l'intero processo, la sandbox non ha mai visto la chiave AWS. I tuoi dati non verranno divulgati all'Agent.
Sette, Le mie riflessioni: locale vs cloud Il mio setup attuale (OpenClaw + LM Studio + x-reader) è tipicamente "standalone": • Il modello gira in locale (Qwen3.5-35B su RTX 3090) • L'Agent non è isolato (perché è proprio sul tuo computer) • Dati completamente locali Questo in confronto alla soluzione Browser Use: Dimensione Agente singolo locale (noi) Agente isolato in cloud (Browser Use) Privacy I dati non escono dal locale I dati vanno nel cloud, ma l'Agent non può accedere alle chiavi Sicurezza Dipende dalla protezione locale L'Agent è completamente isolato, non c'è nulla da rubare Costo Investimento hardware una tantum Pagamento in base all'uso (scale-to-zero) Scalabilità Limitata dall'hardware locale Scalabilità illimitata, più Agent in parallelo Ritardo Zero latenza di rete Un ulteriore salto di rete (ma trascurabile)
Otto, Il mio giudizio: il futuro sarà un modello misto. • Compiti semplici eseguiti localmente: scrivere uno script, cercare informazioni, organizzare documenti, queste cose possono essere fatte localmente, con buona privacy e velocità. • Compiti complessi nel cloud: quando è necessario eseguire più agenti in parallelo, elaborare grandi quantità di dati e funzionare per lungo tempo, in questo caso un'architettura come Browser Use è più adatta.
Nove, In origine non c'era nulla, da dove viene la polvere? Il tuo Agent non dovrebbe avere nulla di cui valga la pena rubare, né alcuno stato da mantenere. In parole semplici: • Non vale la pena rubare: l'Agent non conosce alcun segreto. Ha bisogno di token per regolare LLM? Quelli forniti dal piano di controllo, usati e poi scartati. Deve salvare file? L'URL prefirmato è temporaneo, scade e diventa nullo. • Non è necessario mantenere: l'Agent è morto? Riavviane uno nuovo. Ricorda il contesto? Il database del piano di controllo ha una registrazione completa. Questo è in realtà l'applicazione dell'architettura zero trust nell'era dell'AI: non fidarti di nessun componente, nemmeno se è il tuo stesso Agent.
Dieci, Come dovrebbe imparare un principiante dell'AI? 1. Scelta degli strumenti AI: quando si utilizzano servizi AI basati su cloud, chiediti: - Se questo agente perde il controllo, cosa può ottenere? Una buona architettura dovrebbe farlo "non sapere nulla". 2. Consapevolezza della privacy: eseguire compiti semplici con AI locale (OpenClaw, LM Studio), i dati sensibili non devono andare nel cloud. Per compiti complessi, utilizzare soluzioni di isolamento basate su cloud, ma è importante sapere che i dati lasceranno il locale. 3. Flusso di lavoro futuro: una persona + più agenti in collaborazione è la tendenza (Karpathy parla di Tab→Agente→Agenti Paralleli→Team di Agenti). Ma ogni agente dovrebbe essere isolato, non dovrebbe "vivere a casa tua".
Undicesimo, Il compromesso tra sicurezza ed efficienza La soluzione di Browser Use non è perfetta: ci sono tre servizi da implementare e ogni operazione richiede un ulteriore salto di rete. Ma rispetto al rischio che "l'Agent rubi tutte le chiavi", questi costi sono giustificabili. Per noi che abbiamo un setup AI locale, la lezione è: • Scenari semplici: continuare a utilizzare la soluzione locale (OpenClaw + LM Studio), buona privacy, costi contenuti • Scenari complessi: in futuro potrebbe essere necessario integrare servizi Agent isolati nel cloud, lasciando ai professionisti il compito di fare il loro lavoro La sicurezza dell'AI non è una questione mistica, ma di design architettonico. Un buon design fa sì che l'Agent "non abbia nulla" - nessun segreto da rubare, nessuno stato su cui fare affidamento.
Dodici, Questo è probabilmente l'aspetto delle future infrastrutture AI: gli agenti sono usa e getta, il piano di controllo è affidabile e i dati degli utenti sono protetti. Per quanto ci riguarda? Continuiamo a utilizzare OpenClaw per eseguire agenti locali, e quando sarà necessario gestire decine o centinaia di agenti in parallelo, allora considereremo di integrare un'architettura come Browser Use. Domani sarà migliore.
1,43K