Chainguard lancia Workspaces e Checks per proteggere gli agenti di programmazione basati sull’IA

Un agente di programmazione basato sull’IA può scrivere una correzione utile e, nel frattempo, causare un incidente di sicurezza. Potrebbe installare una dipendenza compromessa, seguire istruzioni incorporate in contenuti non attendibili oppure eseguire un comando con credenziali che gli concedono un accesso molto più ampio di quello richiesto dall’attività. Man mano che i team impiegano più agenti in parallelo, proteggere il codice che producono è solo una parte del problema.

Chainguard affronta questa esposizione più ampia con tre annunci ad Assemble London: Workspaces, ambienti isolati per sviluppatori e agenti di programmazione; Checks, un motore di verifica progettato per essere eseguito nel ciclo di sviluppo degli agenti; e l’ampliamento delle protezioni di Libraries, che ora coprono ulteriori linguaggi di programmazione e la correzione delle vulnerabilità.

Le novità rispondono a tre domande a cui le aziende devono sempre più spesso trovare una risposta: dove viene eseguito un agente, come viene verificato il suo lavoro e quale software esterno può introdurre nell’organizzazione. Workspaces e Checks vengono lanciati in versione beta, mentre le nuove offerte di Libraries per Go e .NET entrano in accesso anticipato.

Definire un confine per ogni agente di programmazione

Chainguard Workspaces assegna a ogni sviluppatore e agente una microVM remota separata. L’ambiente sincronizza l’albero di lavoro locale dello sviluppatore, consentendogli di continuare a usare il proprio editor e il flusso di lavoro Git mentre l’esecuzione avviene lontano dal suo computer. Gli ambienti separati permettono inoltre a più agenti di tentare modifiche in parallelo senza condividere lo stesso ambiente di lavoro.

La distinzione è importante perché le funzionalità utili di un agente — eseguire comandi, installare pacchetti e accedere a servizi — possono anche diventare punti di ingresso per una compromissione. Una regola inserita nelle istruzioni dell’agente presuppone che l’agente la rispetti. Un confine imposto dall’ambiente di esecuzione può limitare ciò che accade anche quando il modello prende una decisione sbagliata.

Secondo l’annuncio, le credenziali reali vengono inserite al di fuori dell’ambiente di lavoro. Gli strumenti che richiedono una credenziale su disco ricevono un sostituto crittografato e di breve durata. Le policy facoltative sul traffico in uscita limitano le connessioni verso destinazioni approvate, riducendo la possibilità che una dipendenza compromessa o un agente manipolato tramite prompt invii dati altrove.

Questi controlli affrontano rischi diversi. L’isolamento hardware separa i carichi di lavoro; la gestione intermediata delle credenziali impedisce all’agente di accedere ai segreti riutilizzabili; le policy di rete limitano le destinazioni con cui può comunicare. La loro efficacia dipende comunque dalle autorizzazioni e dalle destinazioni approvate dall’organizzazione. L’isolamento non rende innocua ogni azione autorizzata.

Gli ambienti utilizzano Chainguard OS Packages e verificano le dipendenze rispetto al file di lock durante l’esecuzione. L’offerta OS Packages già esistente di Chainguard fornisce pacchetti sottoposti a manutenzione continua, li compila a partire dal codice sorgente e include distinte base del software. Questo contesto chiarisce l’approccio dell’azienda: estendere le fondamenta software controllate fino all’ambiente in cui vengono eseguiti gli agenti.

Workspaces genera inoltre registri firmati che documentano l’ambiente, le modifiche al codice e i risultati dei controlli. Per i team che si occupano di sicurezza, questi registri offrono un modo per verificare che cosa ha fatto un agente, senza affidarsi esclusivamente al suo resoconto della sessione.

Portare la verifica nel ciclo di lavoro dell’agente

La generazione del codice può essere rapida, mentre il percorso verso un codice verificato resta lento. Un agente apporta una modifica, la invia all’integrazione continua, aspetta che venga predisposto un esecutore e poi riceve una notifica di errore quando il contesto di lavoro è già cambiato. Ripetere questo processo con molti agenti può allungare le code e duplicare le attività di configurazione.

Chainguard Checks integra la verifica in questo ciclo sotto forma di chiamata a uno strumento. Se usato insieme a Workspaces, la sessione dell’agente viene sospesa mentre vengono eseguiti i controlli, per poi riprendere con i registri strutturati degli errori nel proprio contesto. Il flusso di lavoro previsto è iterativo: apportare una modifica, eseguire i controlli, esaminare gli errori e riprovare prima di consegnare il risultato.

Le istantanee precaricate contengono dipendenze già installate e vengono ricreate quando cambia il file di lock. Ogni fase del flusso di lavoro viene eseguita in una microVM isolata a livello hardware. L’annuncio descrive inoltre l’inserimento di credenziali di breve durata, dal lato host, nelle richieste in uscita e policy dichiarative per l’accesso alla rete.

Un’esecuzione completata con esito positivo produce un’attestazione firmata che collega l’ambiente, il risultato dei test e il commit. Secondo Chainguard, i controlli di integrazione successivi possono verificare questa prova e accettare il risultato senza ripetere la stessa suite di test.

È utile distinguere tra trasmettere una prova e limitarsi a trasmettere l’affermazione di un agente secondo cui i test sono stati superati. Un’attestazione può stabilire quali controlli sono stati eseguiti su quale commit e in quale ambiente. Non può dimostrare che i test abbiano coperto tutti i comportamenti importanti o che una modifica approvata soddisfi ogni requisito di sicurezza. I team hanno comunque bisogno di test adeguati, policy di verifica affidabili e revisioni nei casi in cui sia necessario esercitare il proprio giudizio.

Chainguard afferma che il sistema restituisce i risultati in pochi secondi e riduce i calcoli ridondanti. I materiali di lancio non presentano benchmark convalidati in modo indipendente che dimostrino un miglioramento universale della velocità o dei costi in tutti i repository.

Proteggere le dipendenze integrate dagli agenti

Il terzo annuncio amplia Chainguard Libraries, il catalogo gestito e gli endpoint per le dipendenze dei linguaggi open source. Il servizio esistente è progettato per integrarsi con i gestori di artefatti e i flussi di lavoro di sviluppo, offrendo informazioni sulla provenienza e distinte base software firmate per i pacchetti realizzati da Chainguard.

Il nuovo endpoint per Go include la scansione di malware e greyware, criteri configurabili per i pacchetti e la correzione delle vulnerabilità CVE. L’endpoint per .NET offre un’alternativa all’uso diretto di NuGet, con scansione e controlli basati su criteri. Entrambi sono in accesso anticipato.

Chainguard sta inoltre aggiungendo la correzione delle vulnerabilità CVE per JavaScript e Go, comprese le correzioni retroportate per le vulnerabilità di gravità critica e alta. La retroportazione è importante quando un team non può passare subito a una versione principale più recente senza apportare modifiche all’applicazione o svolgere test approfonditi. Può ridurre l’esposizione mentre si pianifica l’aggiornamento più ampio.

Per Java e Python, l’azienda afferma che Athena, la sua coalizione di settore, fornirà artefatti corretti per le vulnerabilità individuate dai modelli di IA all’avanguardia il giorno in cui tali vulnerabilità diventano pubbliche. Si tratta di una promessa relativa alla risposta al momento della divulgazione pubblica, non di una garanzia che non possano esistere vulnerabilità non divulgate.

Un sondaggio mostra perché affidarsi solo all’applicazione delle patch è sempre più difficile

Insieme ai prodotti, Chainguard pubblica The AI Exploit Gap, un sondaggio commissionato a Wakefield Research. Le risposte sono state raccolte a settembre 2026 da 1.300 responsabili della cybersicurezza in nove mercati. Gli intervistati ricoprivano almeno ruoli di livello direttivo e lavoravano generalmente in organizzazioni con almeno 500 dipendenti; la soglia minima era di 250 dipendenti a Singapore e negli Emirati Arabi Uniti/Arabia Saudita.

Nel sondaggio, il 54% ha dichiarato che le proprie organizzazioni lasciano consapevolmente senza patch vulnerabilità di gravità alta o critica almeno talvolta, e il 93% ha espresso preoccupazione sulla capacità di correggere abbastanza rapidamente gli exploit basati sull’IA. Circa il 76% ha riferito di aver subito, nell’anno precedente, un attacco basato sull’IA confermato o sospetto.

Quest’ultima cifra comprende sia gli incidenti confermati sia i sospetti. Non va interpretata come una misura verificata in modo indipendente degli attacchi causati dall’IA. Più in generale, si tratta di resoconti e aspettative degli intervistati, non di dati di telemetria che stabiliscano con quale frequenza abbia successo una particolare tecnica di attacco.

I risultati operativi sono rivelatori. Tra le aziende con un fatturato di almeno 1 miliardo di dollari, il 66% ha riferito di lasciare senza patch vulnerabilità di gravità alta o critica almeno talvolta, contro il 27% delle aziende con un fatturato inferiore a 250 milioni di dollari. Le organizzazioni più grandi hanno citato compromessi aziendali, come le interruzioni e la concorrenza tra le priorità dei prodotti. La differenza riguarda quindi sia la capacità di distribuire le modifiche sia quella di individuare le vulnerabilità.

Più autonomia richiede controlli più verificabili

I tre lanci di Chainguard delineano un approccio coerente: limitare l’ambiente di esecuzione, consentire agli agenti verifiche rapide e riconducibili alla fonte e governare le dipendenze che utilizzano. Ciascuno affronta una parte diversa dello stesso flusso di lavoro di sviluppo.

La prova pratica sarà verificare se questi controlli si integrano con repository reali, integrazioni di servizi e criteri di rilascio senza trasformarsi in un ulteriore collo di bottiglia. Le fasi beta e di accesso anticipato lasciano ancora questo lavoro da svolgere. La direzione, tuttavia, è chiara: man mano che gli agenti di programmazione acquisiscono la capacità di agire, le aziende hanno bisogno di controlli di sicurezza che restino applicabili e verificabili durante tutto il lavoro.