Anthropic Simon ha testato smolvm, ma la sandbox necessita ancora di un control plane

Il ricercatore di Anthropic Simon Willison ha testato smolvm rispetto a un obiettivo impegnativo: eseguire in sicurezza Python e JavaScript non attendibili, senza abusi di rete, filesystem o risorse. L’esperimento ha incontrato subito un conflitto. Claude Code for web operava all’interno di un guest Firecracker, mentre smolvm richiedeva l’accesso alla virtualizzazione hardware che il guest non esponeva.

Questo insuccesso non ha dimostrato che smolvm fosse insicuro. Ha mostrato che valutare una microVM all’interno di un’altra macchina virtuale con restrizioni può fallire ancora prima che inizino i test di sicurezza. La distinzione è importante per i team che valutano script forniti dagli utenti, programmi generati dall’AI o trasformazioni automatizzate dei dati.

Le note di ricerca sulla sandbox evidenziano anche una lacuna ingegneristica più ampia. Un solido confine basato su macchine virtuali è solo una parte di un servizio sicuro di esecuzione del codice. Gli operatori necessitano comunque di scadenze, contabilizzazione delle risorse, preparazione dei file, controlli sull’output, monitoraggio e pulizia attorno a tale confine.

smolvm offre diversi elementi utili. Il networking è disabilitato per impostazione predefinita, i workload ricevono kernel guest separati e i valori di CPU e memoria sono configurabili. Tuttavia, queste funzionalità non creano automaticamente un servizio di produzione per codice ostile.

La vera competizione non è quindi smolvm contro Docker, o Python contro JavaScript. È la promessa dell’isolamento con un solo comando contro i controlli operativi necessari per un’esecuzione multiutente affidabile.

Il test è fallito prima che venisse eseguito il codice non attendibile

Il primo risultato è stato un problema di compatibilità dell’ambiente, non un’evasione dalla sandbox né un limite di risorse non rispettato.

Willison ha chiesto a un modello Anthropic operante tramite Claude Code for web di esaminare smolmachines come sandbox rapida. Il workload proposto era concreto: eseguire codice fornito dagli utenti per attività quali la trasformazione di dati strutturati.

Quel codice richiedeva confini rigorosi. Non doveva avere accesso alla rete, poteva accedere soltanto a file designati, consumare memoria limitata e fermarsi dopo un intervallo definito dall’operatore. Un ciclo infinito, come while true, non doveva occupare risorse di calcolo indefinitamente.

Il modello poteva fare ricerca sul progetto e progettare test. Non poteva avviare le macchine smolvm necessarie per eseguirli. Secondo il resoconto di Willison, l’ambiente Claude Code era già un guest Firecracker basato su Linux.

smolvm utilizza la virtualizzazione assistita dall’hardware tramite hypervisor specifici per piattaforma. Su Linux, ciò significa normalmente KVM, l’interfaccia del kernel che espone a un virtual-machine monitor le funzionalità di virtualizzazione del processore. Un guest cloud con restrizioni spesso non dispone del dispositivo /dev/kvm necessario per avviare un altro guest accelerato dall’hardware.

Questo è il problema della virtualizzazione annidata. Una macchina virtuale può ospitarne un’altra solo quando la piattaforma esterna espone le funzionalità del processore e l’accesso ai dispositivi necessari. Molte sandbox gestite li nascondono intenzionalmente.

La limitazione crea un insolito paradosso di test. Claude Code for web era isolato anche perché veniva eseguito all’interno di una microVM. Quell’isolamento gli ha impedito di avviare la diversa microVM che gli era stato chiesto di valutare.

Durante quel tentativo, nessun workload di attacco significativo in Python o JavaScript ha raggiunto smolvm. Il test non ha prodotto misurazioni indipendenti di latenza di avvio, applicazione dei limiti di memoria, saturazione della CPU, isolamento dei file o comportamento di terminazione.

Questa evidenza mancante dovrebbe orientare ogni conclusione. Sarebbe inaccurato affermare che l’esercizio abbia convalidato smolvm come servizio sicuro di esecuzione. Sarebbe altrettanto inaccurato considerare l’avvio bloccato come prova contro l’isolamento guest di smolvm.

Il risultato identifica invece un prerequisito di distribuzione. Un team deve eseguire smolvm su un host fisico compatibile o su una macchina virtuale che consenta la virtualizzazione annidata.

Il modello di sicurezza di smolvm ufficiale identifica KVM come backend Linux. Supporta inoltre l’Hypervisor framework di Apple e Windows Hypervisor Platform nei rispettivi sistemi operativi.

Questo design multipiattaforma facilita lo sviluppo locale. Non rende però smolvm eseguibile all’interno di ogni sandbox per agenti, worker di integrazione continua o ambiente serverless esistente.

Per l’esperimento anthropic simon, questa è la prima importante inversione. Lo stesso livello di isolamento che proteggeva l’agente di ricerca ha anche impedito all’agente di testare un secondo livello di isolamento.

Anthropic Simon ha evidenziato il control plane mancante

smolvm può fornire un confine VM, ma l’applicazione che lo circonda deve decidere quando il codice inizia, cosa riceve e quando termina.

Il progetto descrive smolvm come uno strumento da riga di comando per macchine virtuali Linux isolate e portabili. Ogni workload viene eseguito con il proprio kernel guest tramite libkrun, un virtual-machine monitor progettato per workload leggeri.

Questa architettura crea un confine predefinito più robusto rispetto a un normale container. Un container convenzionale condivide normalmente il kernel host, anche quando namespace nascondono processi, networking e mount. Un guest smolvm riceve un kernel separato dietro un confine hypervisor.

La distinzione riduce l’esposizione diretta al kernel host. Non elimina la necessità di non fidarsi di tutto ciò che opera nel guest. La documentazione di smolvm afferma esplicitamente che gli operatori dovrebbero trattare root nel guest come non attendibile.

La sua postura di rete predefinita corrisponde all’obiettivo di Willison. L’accesso di rete è opt-in, quindi una macchina avviata senza l’opzione di networking non dovrebbe ricevere normale connettività in uscita. Sono disponibili allowlist degli host quando un’applicazione richiede un egress con ambito ristretto.

Anche l’esposizione del filesystem è esplicita. Le directory host diventano visibili solo quando l’operatore le monta. Questo rende possibile un modello basato su directory di staging per i job di trasformazione.

Un servizio di esecuzione potrebbe copiare gli input designati in una directory temporanea. Potrebbe montare tale directory in sola lettura, fornire una posizione di output scrivibile separata e scartare entrambe dopo aver convalidato i risultati.

Tuttavia, la limitazione documentata di smolvm è importante. La sua interfaccia per i volumi monta directory, non singoli file. Un servizio che promette l’accesso a “solo file designati” deve quindi creare una directory isolata contenente esattamente quei file.

Il servizio deve anche difendere questa fase di staging. Dovrebbe rifiutare link simbolici, file di dispositivo insoliti, permessi inattesi e percorsi che escono dalla directory prevista. Il confine della VM non può correggere un processo imprudente di preparazione dei file lato host.

La configurazione della memoria è disponibile tramite l’opzione --mem o uno Smolfile, la configurazione dichiarativa delle macchine di smolvm. Il valore predefinito documentato è 8 GiB, con memoria presentata tramite un balloon virtio elastico.

L’allocazione elastica migliora l’utilizzo dell’host perché l’host non assegna immediatamente l’intero importo configurato. Non dovrebbe essere confusa con il controllo di ammissione tra molti job ostili.

Se un servizio avvia numerosi guest con allocazioni ottimistiche, la domanda aggregata può comunque sovraccaricare l’host. Lo scheduler necessita di un modello di capacità separato che copra memoria, CPU virtuali, storage e numero di macchine concorrenti.

La configurazione della CPU presenta una distinzione simile. Assegnare una CPU virtuale limita l’esecuzione parallela nel guest. Non garantisce automaticamente che il programma riceva soltanto un numero fisso di secondi di CPU.

Un ciclo infinito a thread singolo può consumare per sempre la CPU virtuale assegnata. L’hypervisor contiene il ciclo, ma un supervisore esterno deve imporre una scadenza e terminare la macchina.

I sistemi di produzione necessitano normalmente sia di policy basate sul tempo reale sia di policy basate sulle risorse. Un timeout di tempo reale gestisce blocchi, processi in attesa e programmi in deadlock. La contabilizzazione della CPU rileva workload che consumano calcolo senza fare progressi.

Il supervisore deve rimanere esterno al guest. Il codice in esecuzione nella macchina non dovrebbe controllare il timer, il segnale di terminazione o la decisione finale di pulizia. Altrimenti, il workload può tentare di disabilitare il proprio guardrail.

Ecco perché l’espressione “sandbox per codice non attendibile” può nascondere due prodotti distinti. Uno è il motore di isolamento. L’altro è il control plane che pianifica e supervisiona in sicurezza quel motore.

Il test anthropic simon mirava al comportamento dell’intero prodotto. L’interfaccia pubblica di smolvm fornisce principalmente il motore di isolamento e la configurazione a basso livello necessaria per costruirlo.

Una microVM cambia il confine, non il modello di minaccia

La virtualizzazione hardware migliora il contenimento, ma ogni capacità inoltrata deliberatamente nel guest diventa parte della superficie di attacco.

smolvm utilizza libkrun VMM per avviare macchine virtuali leggere. Il guest riceve il proprio kernel, mentre l’host mantiene il controllo sull’hardware virtuale e sui dispositivi esposti.

Questo design affronta una preoccupazione centrale relativa ai container. I container isolano i workload utilizzando funzionalità del kernel, ma i processi ostili interagiscono comunque con lo stesso kernel host attraverso chiamate di sistema consentite. Una vulnerabilità del kernel può quindi minacciare il confine del container.

I sistemi microVM spostano quel confine verso l’esterno. Il codice ostile incontra dapprima un kernel guest e dispositivi virtuali. Raggiungere l’host richiede generalmente di attraversare il confine del virtual-machine monitor o dell’hypervisor.

AWS ha sviluppato le microVM Firecracker attorno a un principio simile per workload serverless. Firecracker combina la virtualizzazione KVM con un modello di dispositivi deliberatamente ridotto, limitando l’hardware emulato non necessario.

smolvm non è semplicemente un wrapper per Firecracker. La sua documentazione attuale descrive backend libkrun su macOS, Linux e Windows. Tuttavia, entrambi gli approcci collocano ogni workload dietro un kernel guest separato.

Questa separazione è rilevante quando un sistema AI scrive codice in autonomia. Il codice generato può contenere comportamenti distruttivi accidentali, attacchi alle dipendenze, sonde per credenziali o payload deliberati copiati da dati non attendibili.

Una funzionalità di trasformazione dei dati affronta lo stesso rischio anche senza AI. Un utente potrebbe inviare codice Python che analizza il filesystem, crea ripetutamente processi, alloca memoria fino al fallimento o tenta connessioni in uscita.

JavaScript non è automaticamente più sicuro. I programmi Node.js possono leggere file, avviare sottoprocessi, aprire socket, caricare estensioni native ed esaurire la memoria quando tali capacità restano disponibili.

Le restrizioni a livello di linguaggio da sole diventano spesso fragili, perché le librerie standard espongono funzionalità ampie. Le dipendenze transitive possono inoltre introdurre codice nativo o percorsi di accesso inattesi.

Un guest Linux completo consente agli sviluppatori di eseguire normali pacchetti Python e Node.js senza riscriverli per un runtime specializzato. Questa compatibilità è uno dei motivi per cui le microVM restano interessanti.

Il compromesso è un ambiente guest più ampio. Il servizio deve fornire un kernel, un’immagine runtime, librerie e dispositivi virtuali. Ogni componente gestito incide su patching, riproducibilità e base di calcolo attendibile.

La documentazione di smolvm indica come componenti attendibili il sistema operativo host, il backend hypervisor, libkrun, smolvm e l’account host che invoca il servizio. Una compromissione in questi livelli può indebolire il confine promesso.

La documentazione avverte anche del forwarding esplicito di capacità. Una directory montata espone il suo contenuto. Abilitare il networking amplia i servizi raggiungibili. Inoltrare un agente SSH consente ai processi guest di richiedere firme finché il socket rimane disponibile.

Quelle sono funzionalità ragionevoli per macchine di sviluppo. Normalmente dovrebbero rimanere disabilitate in un servizio che esegue invii anonimi o ostili.

L'accesso alla GPU richiede ancora più cautela. smolvm supporta interfacce che coinvolgono risorse GPU condivise dell'host o processi sul lato host. La sua documentazione afferma che il remoting CUDA non dovrebbe essere considerato un isolamento GPU multi-tenant rafforzato.

Questa limitazione non influisce su un semplice job Python di conversione dati. Illustra la regola più ampia: le funzionalità di comodità possono oltrepassare il netto confine del guest che rende attraente l'architettura di base.

Per i carichi di lavoro ostili, il profilo più sicuro è intenzionalmente noioso. Nessuna rete, nessuna credenziale inoltrata, nessun servizio host, nessuna GPU, input minimi in sola lettura e un'area di output usa e getta.

La VM dovrebbe essere distrutta dopo ogni job. Riutilizzare una macchina rischia di trasferire file modificati, processi, cache o stato nascosto nell'esecuzione dell'utente successivo.

Le immagini portabili possono contribuire a stabilire runtime coerenti. smolvm usa immagini OCI, basate sul formato immagine OCI, quindi gli operatori possono preparare ambienti Python o Node.js usando uno standard di packaging familiare.

La compatibilità delle immagini non stabilisce la fiducia nelle immagini. Un servizio di produzione necessita comunque di digest fissati, registri controllati, gestione delle vulnerabilità e un processo per ricostruire i runtime dopo gli aggiornamenti di sicurezza.

I limiti delle risorse richiedono più di flag per CPU e memoria

La difesa più difficile contro “while true” non è l'isolamento, ma una terminazione affidabile in ogni modalità di errore.

Un'impostazione della memoria fornisce al guest un limite massimo per la RAM visibile. Quando un programma supera tale capacità, il kernel guest può attivare il proprio comportamento di esaurimento della memoria. Questo contiene una forma di abuso delle risorse.

L'host deve comunque osservare ciò che accade in seguito. Il guest potrebbe terminare un solo processo, smettere di rispondere o impiegare molto tempo a recuperare memoria. Il servizio non può presumere che ogni errore di memoria produca un risultato pulito.

Un runner rigoroso dovrebbe classificare gli esiti. Successo, eccezione dell'utente, esaurimento della memoria, timeout, superamento del limite di output, errore interno della sandbox e rifiuto per capacità dell'host sono eventi distinti.

Questa classificazione è importante per utenti e operatori. Uno script di trasformazione con sintassi non valida non dovrebbe sembrare un'interruzione dell'infrastruttura. Una macchina che non riesce ad avviarsi non dovrebbe consumare il margine di tentativi di un utente.

I limiti della CPU richiedono diversi livelli. Il guest può ricevere un numero limitato di CPU virtuali. I controlli dell'host, come cgroups, possono quindi regolare il processo VMM rispetto agli altri carichi di lavoro.

Un supervisore delle scadenze dovrebbe terminare l'intera VM allo scadere dell'intervallo consentito. Terminare solo il processo Python o Node.js di primo livello non è sufficiente perché il programma può creare processi figli o processi in background.

La terminazione deve prevedere anche un'escalation. Il supervisore può prima richiedere uno spegnimento graduale, quindi arrestare il processo VMM se il guest non risponde. Dovrebbe verificare che i processi correlati e le risorse temporanee siano scomparsi.

Anche l'output è una risorsa. Un programma può stampare indefinitamente, creare enormi file di risultati o generare dati profondamente annidati che consumano memoria del parser dopo la fine dell'esecuzione.

Il servizio necessita di limiti in byte per output standard, errore standard e file generati. Dovrebbe trasmettere in streaming o troncare i log senza memorizzare contenuti illimitati nella memoria dell'applicazione.

Le quote di archiviazione dovrebbero applicarsi al livello scrivibile del guest e a ogni directory di output esportata. Altrimenti, un input minuscolo può produrre dati sufficienti a riempire il filesystem dell'host.

Anche il numero di processi conta. Una fork bomb crea processi più velocemente di quanto un operatore umano possa reagire. Il kernel guest necessita di limiti sui processi, mentre l'host dovrebbe vincolare il VMM e i suoi processi di supporto.

Un programma ostile può anche sfruttare il tempo senza saturare una CPU. Potrebbe dormire per sempre, attendere input assenti o creare un deadlock. Per questo le scadenze basate sul tempo reale rimangono obbligatorie.

Il tempo dovrebbe essere misurato dal piano di controllo esterno. Un guest può modificare il proprio orologio o interferire con i processi watchdog interni. Il timer monotono dell'host fornisce una fonte più affidabile.

L'esportazione dei file deve avvenire solo dopo la fine dell'esecuzione. L'host dovrebbe ispezionare tipi, dimensioni, percorsi e conteggi dei file prima di spostare i risultati nell'archiviazione durevole.

Per le comuni trasformazioni dei dati, un contratto di output più ristretto può ridurre il rischio. Il runner potrebbe accettare un documento JSON, un file CSV o un archivio con limiti definiti invece di un albero di directory arbitrario.

Un servizio dovrebbe anche limitare la complessità degli input prima di avviare la macchina. Gli archivi compressi possono espandersi ben oltre le dimensioni di caricamento, mentre formati malevoli possono colpire parser esterni al guest.

La sequenza sicura inizia quindi prima di smolvm. Convalidare e preparare gli input, creare una macchina nuova, applicare limiti di runtime, arrestare la macchina, ispezionare gli output, quindi distruggere lo stato temporaneo.

Anche l'osservabilità appartiene all'esterno del guest. Gli operatori necessitano di identificatori delle macchine, digest delle immagini, orari di avvio e arresto, classificazioni di uscita, picchi di risorse e stato della pulizia.

Per impostazione predefinita, questi record dovrebbero evitare di memorizzare dati sensibili degli utenti. I log possono diventare un altro canale di fuga quando gli script stampano record di input, credenziali o contenuti proprietari.

Nessuno di questi requisiti nega il valore di smolvm. Definiscono il lavoro circostante necessario per trasformare le sue primitive di basso livello in un servizio affidabile.

Docker, WebAssembly e sandbox ospitate restano in competizione

smolvm occupa una posizione intermedia utile, offrendo la normale compatibilità Linux con una separazione più forte rispetto a un container con kernel condiviso.

Docker rimane il punto di partenza più semplice per molti team di ingegneria. Immagini, registri, strumenti di build e sistemi di orchestrazione supportano già i flussi di lavoro con container su larga scala.

I container possono applicare namespace, capability, filtri seccomp, filesystem in sola lettura e limiti cgroup. Questi controlli possono essere appropriati quando i carichi di lavoro sono attendibili o solo moderatamente rischiosi.

Il kernel condiviso rimane la preoccupazione centrale per codice pienamente ostile. Una vulnerabilità di escape nel kernel host o nel runtime dei container può esporre altri carichi di lavoro e dati dell'host.

smolvm modifica questa esposizione assegnando un kernel guest separato a ogni macchina. Accetta inoltre immagini OCI, riducendo parte dell'attrito di migrazione per i team con ambienti Python o Node.js esistenti.

Tuttavia, le piattaforme di container dispongono di livelli maturi di pianificazione e policy. La documentazione di sicurezza di smolvm afferma che lo strumento standalone non è di per sé un piano di controllo multiutente rafforzato.

Un team che sostituisce i container con smolvm deve evitare di perdere salvaguardie operative durante il passaggio. Un isolamento più forte al di sotto di uno scheduler più debole può comunque produrre un servizio inaffidabile.

WebAssembly segue un'altra strada. Un runtime WebAssembly parte da un modello di capability vincolato, poi concede esplicitamente funzioni come l'accesso a file o rete.

Questo approccio può creare un'interfaccia più piccola per carichi di lavoro compatti di trasformazione. Supporta inoltre un avvio rapido e un'integrazione precisa in un'applicazione.

La compatibilità è il compromesso. I pacchetti Python e Node.js standard possono aspettarsi chiamate di sistema Linux, estensioni native, sottoprocessi o comportamenti runtime non disponibili in un ambiente WebAssembly limitato.

Un team che controlla il linguaggio di trasformazione potrebbe accettare tali vincoli. Un servizio che promette ampia compatibilità con Python e JavaScript li incontrerà rapidamente.

Le sandbox di codice ospitate offrono una terza strada. I fornitori raggruppano ciclo di vita delle macchine, timeout, policy di rete, archiviazione e API in servizi gestiti.

Questo può ridurre i tempi di implementazione. Trasferisce però codice e dati sensibili a un altro operatore, introduce dipendenze dal servizio e limita il controllo sul design di isolamento sottostante.

L'hosting autonomo di smolvm mantiene il runtime sotto l'amministrazione dell'acquirente. Rende inoltre l'acquirente responsabile dell'irrobustimento dell'host, degli aggiornamenti di sicurezza, della pianificazione della capacità, del monitoraggio e della risposta agli incidenti.

La scelta dovrebbe dipendere dal carico di lavoro, non dalla moda. Un valutatore di espressioni vincolato non necessita di un guest Linux completo. Un pacchetto Python complesso con dipendenze native probabilmente sì.

Per le trasformazioni una tantum, l'avvio della microVM deve restare contenuto rispetto alla durata del job. smolvm afferma che i carichi di lavoro impacchettati possono avviarsi in meno di 200 millisecondi, ma le misurazioni indipendenti dovrebbero coprire gli host e le immagini esatti dell'acquirente.

I benchmark dovrebbero includere il recupero a freddo delle immagini, la creazione della macchina, l'avvio del runtime, la preparazione degli input, l'esecuzione, la convalida degli output e la distruzione. Misurare solo il tempo di avvio del guest sottostima la latenza percepita dall'utente.

I team dovrebbero anche testare la densità. Un guest veloce dice poco su un host che esegue centinaia di invii simultanei sotto pressione di memoria.

La questione competitiva è quindi più ampia della forza dell'isolamento. Include compatibilità, comportamento all'avvio, maturità della pianificazione, onere operativo e conseguenze di un escape riuscito.

smolvm merita una valutazione perché combina carichi di lavoro Linux familiari con un confine VM. Il tentativo anthropic simon mostra che tale valutazione deve avvenire su un'infrastruttura capace di esporre le funzionalità di virtualizzazione richieste.

Tre test decideranno se smolvm è pronto

Le prossime prove utili devono provenire da test su carichi di lavoro ostili, non da un'altra checklist di funzionalità.

Il primo segnale è un test riproducibile su un host bare-metal compatibile o con virtualizzazione annidata. Dovrebbe eseguire sia suite Python sia JavaScript attraverso lo stesso supervisore esterno.

Queste suite dovrebbero includere loop infiniti, esaurimento della memoria, fork bomb, output sovradimensionato, sonde del filesystem, sonde di rete, processi figli ritardati e spegnimenti anomali del guest. Ogni caso necessita di un esito previsto.

Un risultato positivo rafforzerebbe l'ipotesi che smolvm possa fungere da motore di isolamento per job di trasformazione. Ripetuti fallimenti di pulizia o terminazioni incoerenti la indebolirebbero.

Il secondo segnale è l'applicazione esplicita e documentata del ciclo di vita. Un runner di riferimento dovrebbe mostrare come imporre scadenze basate sul tempo reale, controlli CPU a livello host, limiti di memoria, quote di output e distruzione completa della macchina.

I flag di configurazione non sono sufficienti. Il test dovrebbe verificare il comportamento quando il guest ignora le richieste di spegnimento, riempie lo spazio di archiviazione e lascia indietro processi discendenti.

Questo segnale colmerebbe il divario tra le primitive VM di smolvm e il servizio che Willison voleva originariamente esaminare. Senza di esso, ogni adottante deve progettare autonomamente il supervisore critico.

Il terzo segnale è una revisione della sicurezza secondo un modello di minaccia dichiarato. La revisione dovrebbe identificare i componenti host attendibili, il comportamento dei file montati, l'applicazione della rete, la provenienza delle immagini e le ipotesi multi-tenant.

La documentazione esistente di smolvm fornisce già informazioni utili. Indica che le release attualmente non dispongono di firme e attestazioni di provenienza, sebbene la verifica del checksum sia disponibile quando è possibile scaricare il relativo file.

Questa informazione offre agli addetti alla valutazione una domanda concreta sulla supply chain. Un operatore di produzione necessita di un metodo controllato per acquisire, verificare, fissare e aggiornare il binario smolvm e le immagini guest.

Una valutazione dovrebbe anche distinguere l'esecuzione locale per un solo utente dal multi-tenancy ostile. Uno sviluppatore che esegue codice generato su un laptop affronta conseguenze diverse rispetto a un servizio pubblico che accetta invii anonimi.

Nessuna sandbox può trasformare codice arbitrario in un carico di lavoro privo di rischi. L'obiettivo pratico è un contenimento a più livelli, capability controllate, consumo di risorse limitato e recupero rapido quando uno strato fallisce.

Il modello di distribuzione più promettente usa smolvm come uno strato all'interno di tale sistema. Un servizio host convalida gli input, crea un guest usa e getta, nega l'accesso alla rete, applica scadenze, controlla gli output e distrugge l'ambiente.

Per i team che sviluppano workflow di IA, la lezione va oltre l'esecuzione del codice. Qualsiasi sistema che consenta a un modello di agire su informazioni locali necessita di confini espliciti su ciò che il modello può leggere, scrivere e conservare.

Una base di conoscenza consultabile può aiutare gli ingegneri a conservare risultati dei test, modelli di minaccia e conclusioni sugli incidenti. Non può sostituire l'isolamento in fase di esecuzione, ma può rendere più semplice sottoporre a verifica le decisioni di sicurezza.

L'esperimento anthropic simon dovrebbe quindi essere considerato una valutazione incompleta, con un primo risultato utile. smolvm non ha potuto essere eseguito nell'ambiente Claude Code scelto perché la sandbox esterna non consentiva l'accesso alla virtualizzazione.

Il passo successivo non è allentare quella sandbox esterna. È ripetere la valutazione su un host dedicato e compatibile, con un supervisore esterno e una suite di test avversari pubblicata.

Il vostro servizio sarebbe comunque in grado di fermare ogni job, conservare solo gli output approvati e ripulire completamente l'ambiente quando il guest diventa ostile? Se questa risposta non è stata misurata, la sandbox non è pronta per il codice degli utenti.