Selvedge ed esecuzione con prove concrete
Una sandbox non è una prova
Eseguire codice non fidato è una di quelle idee che in riunione sembrano valide perché nessuno ha ancora scritto il rapporto sull'incidente. Lascia che l'agente chiami uno strumento. Lascia che il plugin trasformi un file. Lascia che il modulo del partner elabori i dati. Mettilo in una sandbox. Perfetto. Il codice non può uscire. Tutti annuiscono. Poi il revisore chiede cosa ha fatto davvero il codice dentro la sandbox, e all'improvviso la stanza scopre che il contenimento non è la stessa cosa dell'evidenza.
Una sandbox risponde a una domanda: il carico di lavoro è rimasto dentro il confine? Questo è necessario. Ma non basta. La domanda più difficile è cosa è successo durante l'esecuzione. Quale artefatto è stato eseguito? Quale policy è stata applicata? Quali capacità sono state richieste? Quali chiamate all'host sono state consentite o negate? Quanto fuel, memoria e tempo ha consumato? Cosa ne è uscito? L'esecuzione può essere riprodotta senza fidarsi della macchina originale? Se le risposte vivono nei log e nella fiducia, il sistema ha un costume, non una traccia di audit.
Selvedge esiste per colmare quel vuoto. La pagina lo chiama il livello di trascrizione dell'esecuzione per codice non fidato: AION dimostra il ragionamento, Ledger registra gli eventi di sistema e Selvedge cattura l'esecuzione. L'implementazione segue quella struttura. Il workspace è un progetto Rust 2024 con crate per digest core e limiti delle risorse, motori di esecuzione, backend Wasmtime e Kera, determinismo, host WASI e Kera, policy, verifica AION, CLI, MCP, registry, runner, daemon, audit e superfici SDK guest. La promessa pubblica è volutamente semplice: Selvedge esegue codice non fidato sotto esecuzione deterministica, applicazione delle policy e disciplina di verifica.
La distinzione utile è piccola e brutale. Una sandbox dice che il codice non è uscito. Selvedge è progettato per dire cosa ha fatto il codice.
La trascrizione non è un log
I log sono utili per gli esseri umani che stanno già facendo debug. Sono meno utili quando la domanda è se un'esecuzione può essere verificata in seguito da qualcuno che non si fidava dell'host originale. Una riga di log può mancare, essere riordinata, filtrata, troncata, riformattata o spiegata via. Una trascrizione deve far parte del contratto di esecuzione.
Il core di Selvedge definisce digest SHA3-256, tipi di errore, validazione dei percorsi, token di autenticazione e limiti condivisi delle risorse. Il README descrive le trascrizioni con hash di bytecode, impostazioni, stdout, stderr, output, memoria e globali, oltre al consumo di fuel e ai conteggi delle chiamate all'host. La pagina descrive ogni chiamata all'host inclusa in una catena SHA3-256 e il risultato avvolto in una busta di prova in stile AION con sigillo Ed25519. Questa è la differenza tra un sistema che dice fidati di me e un sistema che dice ecco il pacchetto.
C'è una sana dose di paranoia in quel design. Il digest dell'artefatto nomina il codice. Il digest delle impostazioni nomina il profilo deterministico. La trascrizione nomina ciò che ha attraversato il confine dell'host. La busta firmata rende visibile ogni manomissione. La verifica offline significa che il runtime originale non è l'unico testimone. Questa è la parte che molte storie sulle sandbox saltano perché è meno divertente che mostrare un plugin in esecuzione in una demo. Le demo raramente chiedono chi ha modificato il log di audit. I revisori sì.
Anche il default deny ha bisogno di ricevute
Defaultdeny è una buona postura e uno slogan pessimo se si ferma alla slide. La policy Selvedge dà i denti allo slogan. Il crate della policy definisce le capacità WASM come clock, random, filesystem, network, environment, stdio, process e custom. Trasporta i limiti delle risorse per memoria, dimensione dei file, conteggio delle istruzioni e tempo. Convalida gli invarianti, rifiuta le capacità duplicate, fornisce errori strutturati e mappa i guasti nel vocabolario comune dei fault Dweve. Il runner applica poi i limiti delle risorse alla configurazione di esecuzione prima che il workload parta.
Questo significa che la policy non è un questionario a cui si risponde dopo l'esecuzione. È un input per l'esecuzione. Se il workload chiede tempo, casualità, filesystem, network, environment o accesso ai processi, quella richiesta deve superare la policy. Se consuma troppo fuel, memoria o tempo di clock, l'esecuzione termina come un guasto controllato. Se una policy è incoerente, dovrebbe fallire prima che l'artefatto inizi a fare qualcosa di interessante. Molto noioso. Molto utile. La noia è come ci teniamo i weekend.
Il punto importante è che le decisioni della policy non sono separate dalle prove. Una sandbox può consentire o negare una categoria ampia e lasciare comunque una traccia di audit sottile. Selvedge è costruita sull'idea che ogni decisione di gate e ogni lettura delle risorse appartenga alla storia dell'esecuzione. È questo che la rende utile per gli strumenti degli agenti, l'esecuzione di plugin di terze parti, l'inferenza Kera, i workload regolamentati e il codice dei partner. Il lavoro può essere non attendibile. Le prove non dovrebbero esserlo.
Il determinismo è dove l'host smette di improvvisare
Il replay è facile da promettere e difficile da mantenere. L'host ha un clock. L'host ha casualità. Il comportamento NaN in virgola mobile può essere scomodo. La SIMD può differire tra architetture. Filesystem, variabili d'ambiente e stato dei processi sono modi eccellenti per introdurre il nondeterminismo in posti dove nessuno se lo aspetta. Se vuoi il replay, devi rimuovere o controllare queste fonti prima che diventino scuse.
Selvedge rende l'esecuzione deterministica il default. Il README descrive un clock virtuale fissato all'epoca 2024-01-01, casualità ChaCha20 con seed, metering del fuel, generazione del transcript e canonicalizzazione dei NaN. Dice anche che il rilevamento SIMD è il più veloce ma solo per la stessa architettura, mentre disabilitare la SIMD è la via completamente portabile tra piattaforme. Quest'ultima parte conta perché il determinismo non è una preghiera. È una decisione di configurazione e architettura, e a volte il compromesso onesto è la velocità per la portabilità.
Il runner usa di default il backend Wasmtime con esecuzione deterministica abilitata. Kera è l'altro backend, pensato per Graph IR e workload di reti neurali binarie. Questa divisione ha senso. WASM è il percorso generale per i componenti non attendibili. Kera è il percorso per i grafi AI. Entrambi richiedono la stessa disciplina circostante: policy prima dell'esecuzione, impostazioni deterministiche, transcript dopo l'esecuzione e prove attorno al risultato.
Perché gli agenti rendono tutto questo meno opzionale
I sistemi di agenti rendono di nuovo di moda l'esecuzione di codice non fidato, una frase che dovrebbe far drizzare la schiena a ogni addetto alla sicurezza. Un modello richiede una chiamata a uno strumento. Un plugin esegue una trasformazione. Uno script helper generato tocca dei dati. Uno strumento di un partner arriva tramite MCP. Il modello non ha scritto lo strumento, lo strumento potrebbe non essere revisionato con la stessa cura del codice di produzione, e l'utente si aspetta comunque che il sistema spieghi cosa è successo. Buona fortuna se l'unica risposta è una cartella di log e sensazioni.
Selvedge ha una superficie server MCP per gli strumenti degli agenti, una CLI per flussi di lavoro in stile build, verify, run e replay, un demone per l'esecuzione a lunga durata, pooling dei runner e cache warming, crate per client e server di registry, e un SDK guest. Il punto non è che ogni superficie sia uguale. Il punto è che la forma delle prove dovrebbe essere confrontabile. Che un carico di lavoro entri come componente WASM, grafo Kera, strumento agente o job di servizio, l'esecuzione dovrebbe concludersi con qualcosa di verificabile.
Le prestazioni sono un compromesso, non un incantesimo
La pagina di Selvedge include i numeri di benchmark dal file BENCHMARKS.md del repository: il cold start è il vantaggio principale, il percorso a caldo è più sfumato, Kera JIT ha una buona storia per i grafi già caldi, e Wasmtime vanilla mantiene ancora alcuni percorsi a caldo con chiamate ripetute. Questo è il modo giusto di parlarne. Il lavoro sui runtime è pieno di compromessi. Se un modello a componenti produce una trascrizione e una busta di prove, ha costi diversi rispetto al percorso minimo indispensabile. Se il cold start è il tuo problema, quel percorso di prove può aiutare. Se il carico di lavoro è una chiamata ripetuta serrata senza bisogno di overhead di trascrizione, la risposta può essere diversa. Molto scomoda, la realtà. Si rifiuta di essere un dépliant.
La versione articolata della storia delle prestazioni è quindi semplice: scegli il runtime in base al carico di lavoro. Non usare una busta di prove come pozione magica di velocità. Usala quando il costo di non avere prove riproducibili è più alto dell'overhead. Per strumenti agente, elaborazione di dati regolamentata, plugin di terze parti ed esecuzioni in cui in seguito una persona chiederà cosa è successo, quel costo è spesso reale.
Cosa rivedere prima di usarlo
Prima, decidi se ti serve contenimento, prove, o entrambi. Se il carico di lavoro è fidato e interno, Selvedge potrebbe essere più macchinario del necessario. Se il carico di lavoro è non fidato, fornito da partner, attivato da modello o soggetto a revisione, la trascrizione inizia a guadagnarsi il suo posto.
Secondo, rivedi la policy. Quali capacità sono consentite? Quali sono negate? Quali sono i limiti di fuel, memoria e tempo? La modalità deterministica è richiesta o solo permissiva? L'accesso a filesystem e rete è abbastanza ristretto? La policy è versionata insieme all'artefatto? Se la policy vive in una wiki e l'esecuzione vive da un'altra parte, il progetto sta già andando alla deriva.
Terzo, testa il replay come comportamento di prodotto. Non aspettare una revisione per scoprire se la busta si verifica offline. Esegui lo stesso artefatto, la stessa policy e gli stessi input due volte. Confronta le trascrizioni. Prova capacità negate. Rompi il checksum. Cambia il seed. Disabilita SIMD se l'identità cross-platform conta. I test fastidiosi sono il punto.
La lezione
Selvedge non è una sandbox più carina. È un livello di prove di esecuzione. Esegue artefatti WASM e Kera, parte da default deny, vincola le risorse, controlla gli input deterministici, trasforma l'esecuzione in trascrizioni tramite hash, e avvolge i risultati in una busta di prove che può essere controllata in seguito. Questa è una promessa diversa da "il codice è rimasto nel suo angolo".
Man mano che i sistemi di IA chiamano più strumenti, eseguono più helper generati e accettano più componenti di terze parti, quella distinzione smette di essere accademica. La domanda non sarà solo se il carico di lavoro sia sfuggito. La domanda sarà cosa ha fatto, con quale policy, con quali input, producendo quali output, e se qualcun altro possa riprodurre quella rivendicazione.
Una sandbox è un muro. Selvedge cerca di esserne anche il testimone.