The Pulse
Plimsoll segnala quattro livelli di isolamento per il codice scritto dagli agenti
Plimsoll segnala il livello di isolamento di ogni esecuzione e consente a chi invia la richiesta di fissare un minimo che il provider deve soddisfare prima che il codice venga inviato. La versione v0.21.0 si concentra sulle risposte associa
AI.info Team · Scritto con l’IA ·
Plimsoll descrive quattro livelli di isolamento per l’ambiente in cui viene eseguito il codice scritto dagli agenti: processo, container, kernel e macchina virtuale. Il servizio sandbox open source segnala il livello di ogni esecuzione e chi invia la richiesta può fissare un minimo; se un provider non è in grado di soddisfarlo, Plimsoll rifiuta il lavoro prima di inviare il codice. La sua ultima versione elencata, v0.21.0, è stata pubblicata il 9 ottobre.
Quattro livelli, con un minimo fissato da chi invia la richiesta
I livelli distinguono protezioni sostanzialmente diverse. Plimsoll classifica il proprio provider WebAssembly eseguito all’interno del processo al livello processo: non offre alcuna barriera a livello di sistema operativo e il progetto mette in guardia dall’usarlo per codice ostile. Un container Docker che usa il runtime predefinito runc condivide il kernel dell’host; l’uso di gVisor porta il livello segnalato a kernel. Il progetto supporta anche provider basati su macchine virtuali, tra cui il servizio di E2B basato su Firecracker e Docker Cloud Sandboxes.
Una richiesta può specificare il livello minimo accettabile. Se il provider attivo non lo raggiunge, Plimsoll restituisce un errore di isolamento insufficiente e indica che non è stato eseguito alcun codice. Il client Go ufficiale verifica di nuovo il livello segnalato quando arriva il risultato, così un’applicazione può rifiutare un’esecuzione che non soddisfa il minimo configurato.
La versione v0.21.0 rende più rigorosa la tracciabilità delle esecuzioni
La versione del 9 ottobre si concentra sull’associazione delle risposte alle richieste a cui si riferiscono e su rifiuti più chiari. Ciascuno dei client ufficiali Go, Python e TypeScript invia un ID della richiesta; il daemon restituisce quell’ID insieme alla risposta e i client rifiutano una risposta se l’ID manca o non corrisponde. Secondo le note di rilascio, la modifica affronta un possibile problema in cui un proxy potrebbe riproporre il rifiuto di una richiesta per un’altra richiesta, facendo sembrare che una chiamata non sia stata eseguita.
La versione contrassegna inoltre come «non inviati» alcuni errori che si verificano prima che la richiesta raggiunga il gestore di Plimsoll. La distinzione conta quando il codice può avere effetti esterni: Plimsoll avverte che un errore privo di tale indicazione potrebbe essersi verificato dopo l’inizio dell’esecuzione e che non è sicuro riprovare automaticamente. La versione 0.21.0 chiude inoltre una sessione che nessuna richiesta ha preso in carico dopo il suo primo timeout di inattività, anziché lasciarla aperta per tutta la sua durata prevista.
Le credenziali restano fuori dalla sandbox
Per l’accesso autorizzato alle API, Plimsoll usa un broker esterno alla sandbox. Una concessione limita un’esecuzione a determinate route di una sola API; il broker verifica chi ha effettuato la richiesta e la route, poi aggiunge una credenziale specifica per l’esecuzione. Il codice scritto dagli agenti non riceve quella credenziale, l’indirizzo dell’API né un accesso generale alla rete, e un’esecuzione senza concessione non ha accesso alla rete.
Il repository descrive questi controlli come misure di protezione integrate nel daemon e nei client. Non equivalgono a un’attestazione hardware: secondo il progetto, ogni livello segnalato si basa sulla configurazione del daemon, sulle informazioni fornite dal provider e sui controlli all’avvio, non su una prova crittografica del software in esecuzione. Questo limita ciò che il livello può attestare riguardo alla macchina su cui avviene un’esecuzione.
Questa impostazione trasforma l’isolamento da un’affermazione generica in un valore che un’applicazione può esaminare e vincolare per ogni richiesta. La protezione dipende però dal provider, dalla sua configurazione e da come l’applicazione gestisce i rifiuti e gli errori dall’esito incerto. L’avvertimento del repository è concreto: l’esempio al livello processo non ha alcuna barriera a livello di sistema operativo, mentre chi cerca una separazione più forte deve configurare un provider che la offra.