Da OpenClaw ad Agentor: Costruire AI Agents Sicuri in Rust

Siamo stati incaricati di effettuare un audit di sicurezza di un framework open-source di AI agents. Il cliente voleva la garanzia che la propria infrastruttura di agenti -- che gestiva dati sensibili attraverso molteplici provider LLM -- soddisfacesse gli standard richiesti per un deployment enterprise. Quello che è iniziato come un incarico di sicurezza di routine è diventato il catalizzatore per costruire qualcosa di completamente nuovo. Il framework aveva buone intenzioni, era popolare su GitHub e attivamente mantenuto. Ma più scavavamo in profondità, più diventava chiaro: i problemi non erano bug da correggere. Erano decisioni architetturali incorporate nelle fondamenta.

Cosa abbiamo trovato: I limiti dei framework di agenti basati su Python

Il framework che abbiamo auditato seguiva un pattern comune nell'ecosistema degli agenti basati su Python. Gli agenti eseguivano strumenti generando sottoprocessi o chiamando funzioni direttamente all'interno dello stesso processo Python. Non c'era sandboxing: uno strumento con un bug o un'iniezione di prompt malevola poteva accedere al filesystem, effettuare richieste di rete o leggere variabili d'ambiente contenenti API key. In uno dei nostri test, abbiamo dimostrato che un prompt attentamente costruito poteva far sì che un agente esfiltrasse credenziali archiviate in memoria da un altro agente in esecuzione nello stesso processo.

L'overhead del runtime aggravava i problemi di sicurezza. Il Global Interpreter Lock di Python significava che l'orchestrazione multi-agente era fondamentalmente single-threaded. I tempi di avvio a freddo variavano da 2 a 5 secondi a seconda dell'albero delle dipendenze. Il consumo di memoria per un singolo agente con un set modesto di strumenti si aggirava sui 200-400MB: gestibile per una demo, proibitivo quando si eseguono decine di agenti in produzione. E ogni riavvio dell'agente ricaricava l'intera catena di dipendenze perché Python non ha il concetto di compilazione ahead-of-time per questo tipo di carico di lavoro.

Le implicazioni per la conformità normativa sono state la preoccupazione finale. La tipizzazione dinamica significava che i dati che fluivano attraverso la pipeline dell'agente non avevano garanzie a tempo di compilazione sulla loro forma o contenuto. Informazioni personali identificabili potevano passare attraverso middleware di logging senza essere rilevate perché non c'era enforcement a livello di tipi. Raggiungere la conformità GDPR richiedeva di avvolgere ogni punto di accesso ai dati in controlli runtime: controlli facili da dimenticare, impossibili da applicare sistematicamente e invisibili all'analisi statica. Per un'organizzazione certificata ISO 27001 come la nostra, raccomandare questo framework per l'uso in produzione non era un'opzione.

La decisione: Costruire da zero in Rust

Il nostro primo istinto è stato contribuire con patch upstream. Abbiamo redatto una proposta per un livello di sandbox, isolamento della memoria tra agenti e un sistema di passaggio messaggi tipizzato. Ma più definivamo l'ambito delle modifiche, più diventava chiaro che non stavamo proponendo miglioramenti: stavamo proponendo una riscrittura. L'architettura a plugin del framework presupponeva l'accesso diretto alla memoria tra componenti. Il modello di esecuzione degli strumenti era costruito attorno al sistema di import di Python. Aggiungere isolamento a posteriori avrebbe rotto ogni estensione esistente e vanificato lo scopo dell'ecosistema.

Abbiamo scelto Rust per ragioni che andavano oltre il seguire una tendenza. Il nostro team aveva trascorso due anni scrivendo smart contract per la blockchain Stellar usando Soroban: contratti in Rust che compilano in WASM e vengono eseguiti in un ambiente sandboxed. Comprendevamo il modello di ownership di Rust, il suo ecosistema async e, cosa cruciale, la sua capacità di compilare in WebAssembly. Ogni proprietà di cui avevamo bisogno per un framework di agenti sicuro -- sicurezza della memoria senza garbage collection, astrazioni a costo zero, pulizia deterministica delle risorse e un target di compilazione WASM -- Rust le forniva nativamente.

La decisione non è stata presa alla leggera. Rust ha una curva di apprendimento più ripida di Python, l'ecosistema per il tooling IA è più giovane e la velocità di sviluppo nelle prime settimane è stata più lenta. Ma stavamo costruendo un'infrastruttura destinata a funzionare in produzione per anni, gestendo dati sensibili in settori regolamentati. L'investimento iniziale in correttezza avrebbe generato dividendi ogni giorno in cui il sistema avesse funzionato senza un incidente di sicurezza.

Architettura di Agentor: 13 crate, una missione

Agentor è strutturato come un workspace Rust con 13 crate, ciascuno con una singola responsabilità e confini ben definiti. Non è un monolite suddiviso in cartelle: ogni crate compila indipendentemente, ha la propria suite di test ed espone un'API pubblica attraverso il sistema di moduli di Rust. Le dipendenze tra crate sono esplicite e applicate dal compilatore. Se un crate non necessita di accesso al filesystem, semplicemente non dipende da std::fs, e nessuna astuzia a runtime può cambiare questo.

• agentor-core -- Gestione del ciclo di vita dell'agente, routing dei messaggi e definizioni dei trait che ogni altro crate implementa. È la spina dorsale: definisce cos'è un agente, come comunicano gli agenti e come il sistema orchestra flussi di lavoro multi-agente.
• agentor-runtime -- Il runtime async basato su Tokio che gestisce l'esecuzione degli agenti, i limiti delle risorse e lo shutdown graceful. Gestisce la backpressure, la prioritizzazione dei task e assicura che nessun agente possa privare gli altri di CPU o memoria.
• agentor-providers -- Livello di astrazione dei provider LLM con supporto per OpenAI, Anthropic e modelli locali attraverso un trait unificato. Cambiare provider richiede di modificare un valore di configurazione, non di riscrivere codice.
• agentor-tools -- Framework di definizione ed esecuzione degli strumenti con type checking a tempo di compilazione. Ogni strumento dichiara i propri input, output e permessi richiesti come tipi Rust.
• agentor-mcp -- Implementazione completa del Model Context Protocol, che consente agli agenti Agentor di interoperare con qualsiasi sistema compatibile MCP.
• agentor-sandbox -- Il livello di isolamento WASM. Ogni esecuzione di strumento avviene all'interno di un'istanza WASM sandboxed con grant di capability espliciti.
• agentor-cli -- Interfaccia a riga di comando per creare, eseguire e gestire progetti di agenti. Scaffolda nuovi progetti, esegue server di sviluppo locale e gestisce i deployment.
• agentor-codegen -- Pipeline di generazione codice con trasformazioni AST-aware, coordinamento multi-file e verifica della compilazione integrata.
• agentor-config -- Gestione della configurazione con default sensibili all'ambiente, gestione dei segreti e validazione.
• agentor-telemetry -- Logging strutturato, tracing distribuito e raccolta metriche con compatibilità OpenTelemetry.
• agentor-auth -- Autenticazione e autorizzazione per la comunicazione agente-agente e agente-servizio.
• agentor-storage -- Gestione dello stato persistente con backend pluggabili (SQLite, PostgreSQL, in-memory).
• agentor-testing -- Utility di test, provider mock e snapshot testing per i comportamenti degli agenti.

WASM Sandbox: Sicurezza per design

Il livello sandbox è la decisione architetturale che differenzia Agentor da ogni alternativa basata su Python. Quando un agente invoca uno strumento -- che si tratti di leggere un file, effettuare una richiesta HTTP o eseguire codice generato -- quello strumento viene eseguito all'interno di un'istanza WASM isolata. L'istanza non ha accesso al filesystem dell'host, non ha capacità di rete e non condivide memoria con altri strumenti o con il processo host. L'accesso a qualsiasi risorsa deve essere esplicitamente concesso attraverso un sistema di capability definito al momento del deployment.

Ogni istanza WASM viene eseguita con limiti di memoria configurabili e timeout di esecuzione. Se uno strumento tenta di allocare più memoria di quella consentita, l'istanza viene terminata: non l'agente, non il runtime, solo quella singola invocazione dello strumento. Se uno strumento supera il suo timeout di esecuzione, viene eliminato in modo pulito con output diagnostico completo. Questo è fondamentalmente diverso dall'approccio di Python di generare sottoprocessi e sperare che si comportino bene. In Agentor non c'è speranza: le restrizioni sono applicate dal runtime WASM a livello di istruzione.

L'impatto pratico è significativo. Nel framework che abbiamo auditato, un attacco di iniezione di prompt che causava l'esecuzione di codice arbitrario da parte di uno strumento poteva compromettere l'intero sistema. In Agentor, lo stesso attacco resta contenuto in un'istanza WASM sandboxed senza capability: può computare, ma non può comunicare, persistere o accedere a nulla al di fuori del suo sandbox. Il raggio d'impatto di qualsiasi incidente di sicurezza si riduce da 'compromissione totale del sistema' a 'un'invocazione di strumento ha restituito un errore.'

Ottimizzato per la generazione di codice

Questo è il nucleo del perché Agentor esiste e di ciò che lo rende diverso dai framework che trattano la generazione di codice come un semplice strumento in più. Agentor è stato costruito da zero per essere il runtime della generazione di codice guidata dall'IA: non generazione di testo che capita di produrre codice, ma una pipeline strutturata che comprende il codice come un artefatto di prima classe con sintassi, semantica e dipendenze.

La pipeline inizia con lo sviluppo guidato da specifiche. Prima che un agente generi una singola riga di codice, produce una specifica strutturata: i file da creare o modificare, le interfacce che devono implementare, le dipendenze che richiedono e i test che valideranno la correttezza. Questa specifica non è un suggerimento: è un contratto che la pipeline di generazione applica. Se il codice generato non corrisponde alla spec, la pipeline lo rifiuta prima che raggiunga il filesystem.

Il coordinamento dell'output multi-file è dove la maggior parte degli strumenti di generazione di codice fallisce. Generare una singola funzione è semplice. Generare un modulo con cinque file che si importano a vicenda, implementano interfacce condivise e devono compilare insieme è un ordine di grandezza più difficile. Il crate codegen di Agentor mantiene un grafo delle dipendenze di tutti i file in un batch di generazione, assicura che gli import si risolvano correttamente tra i file e valida che l'output completo compili come un'unità prima di scrivere qualsiasi cosa su disco.

Le trasformazioni AST-aware sostituiscono la sostituzione di testo ingenua che la maggior parte dei framework utilizza. Quando Agentor modifica codice esistente, analizza il sorgente in un albero sintattico astratto, applica trasformazioni a livello semantico e rigenera il sorgente. Questo significa che aggiungere un metodo a una classe non rompe la formattazione, inserire un import non duplica uno esistente e rinominare una funzione aggiorna tutti i siti di chiamata. La differenza tra sostituzione di testo e trasformazione AST è la differenza tra uno strumento cerca-e-sostituisci e un compilatore: uno dei due comprende il codice.

La pipeline di testing integrata chiude il ciclo. Ogni ciclo di generazione segue la stessa sequenza: generare, compilare, testare, iterare. Se il codice generato non compila, Agentor cattura gli errori del compilatore, li rimanda all'LLM con il contesto rilevante e richiede una versione corretta, automaticamente, senza intervento umano. Se il codice compila ma i test falliscono, l'output dei test segue lo stesso loop di feedback. Questo ciclo genera-compila-testa-itera tipicamente converge in 2-3 iterazioni, e ogni iterazione beneficia dell'architettura zero-copy di Rust che minimizza l'overhead del passaggio di codebase grandi tra le fasi della pipeline.

Protocollo MCP: Interoperabilità universale dell'IA

Il Model Context Protocol sta diventando lo standard per l'interoperabilità dei sistemi IA, e Agentor lo implementa come cittadino di prima classe attraverso il crate agentor-mcp. Qualsiasi agente Agentor può esporre le proprie capability come strumenti MCP, consumare strumenti da server MCP esterni e partecipare a flussi di lavoro multi-sistema senza codice di integrazione custom. Questo significa che un agente di generazione codice Agentor può utilizzare strumenti forniti da un plugin IDE, un sistema CI/CD o un servizio di deployment cloud, tutto attraverso lo stesso protocollo, con le stesse garanzie di sicurezza applicate dal livello sandbox.

Il supporto MCP significa anche che le organizzazioni possono adottare Agentor in modo incrementale. Flussi di lavoro IA esistenti costruiti su altri framework possono chiamare agenti Agentor attraverso MCP senza sostituire la propria infrastruttura attuale. Man mano che i team acquisiscono fiducia nelle caratteristiche di sicurezza e performance, possono migrare carichi di lavoro aggiuntivi al proprio ritmo. Non è richiesta una migrazione big-bang: Agentor è stato progettato per coesistere.

Conformità senza compromessi

Come azienda certificata ISO 27001, abbiamo costruito Agentor con la conformità normativa come vincolo di progettazione, non come un'aggiunta successiva. Ogni decisione architetturale è stata valutata rispetto ai requisiti dei framework normativi all'interno dei quali operano i nostri clienti.

• GDPR -- Il flusso dei dati attraverso la pipeline dell'agente è tracciato a livello di tipi. I campi PII sono contrassegnati con il sistema di tipi di Rust, e qualsiasi tentativo di loggare, serializzare o trasmettere PII senza redazione esplicita viene intercettato a tempo di compilazione. Il sandbox assicura che gli strumenti non possano accedere a dati per i quali non hanno ricevuto permesso esplicito.
• ISO 27001 -- Controlli di accesso, logging di audit e contenimento degli incidenti non sono moduli opzionali: sono integrati nel runtime. Ogni azione dell'agente viene loggata con integrità crittografica, ogni invocazione di strumento viene registrata con i propri grant di capability, e gli eventi di sicurezza attivano il contenimento automatico attraverso il livello sandbox.
• DPGA (Digital Public Goods Alliance) -- Agentor è progettato per soddisfare gli standard open-source per i beni pubblici digitali, con governance trasparente, documentazione accessibile e deployment indipendente dalla piattaforma attraverso WASM.

Il contrasto con il framework che abbiamo auditato è netto. Raggiungere la conformità GDPR in quel sistema basato su Python richiedeva l'aggiunta di middleware runtime ad ogni confine dei dati, senza enforcement del compilatore e senza garanzia di completezza. In Agentor, la conformità è strutturale: se il codice compila, le regole di gestione dei dati sono applicate.

Performance: Rust vs Python

Siamo attenti con i benchmark perché possono essere fuorvianti. Questi numeri provengono dalla nostra suite di test interna che esegue lo stesso flusso di lavoro dell'agente -- un task di generazione codice che legge una specifica, genera tre file, li compila, esegue i test e itera una volta -- sullo stesso hardware.

• Tempo di avvio a freddo -- Agentor: 38ms. Il framework Python: 3.2 secondi. Questo conta quando si eseguono agenti on-demand in ambienti serverless dove ogni avvio a freddo è un utente in attesa.
• Footprint di memoria -- Agente Agentor con set completo di strumenti: 42MB. Agente Python equivalente: 380MB. Una riduzione di 9x che si traduce direttamente in risparmio sui costi dell'infrastruttura quando si opera su scala.
• Agenti concorrenti -- Agentor su una macchina a 4 core: oltre 200 agenti in esecuzione simultanea con scaling lineare del throughput. Il framework Python: 12-15 agenti prima che il GIL diventi il collo di bottiglia.
• Suite di test -- 483 test, zero blocchi unsafe, zero utilizzi di unwrap() nel codice di produzione. Ogni percorso di errore è gestito esplicitamente.
• Overhead del sandbox WASM -- Aggiungere l'isolamento sandbox a un'invocazione di strumento costa circa 1.2ms per invocazione. La garanzia di sicurezza dell'isolamento completo per meno di due millisecondi di latenza è un compromesso che accettiamo senza esitazione.

Il numero più significativo non è un singolo benchmark: è il tempo totale di wall-clock per un ciclo completo di generazione di codice. Agentor completa il loop genera-compila-testa-itera in circa il 40% del tempo impiegato dal framework Python, principalmente perché l'overhead tra le fasi della pipeline si misura in microsecondi anziché in centinaia di millisecondi. Quando si eseguono migliaia di questi cicli al giorno, quella differenza si accumula in ore di tempo risparmiato e costi API LLM significativamente inferiori grazie a meno token sprecati.

Cosa ci aspetta

Agentor è in sviluppo attivo, e la nostra roadmap riflette le priorità che sentiamo dagli early adopter e dal nostro stesso utilizzo interno.

• Integrazione con language server -- Integrazione profonda con VS Code e altri IDE attraverso il Language Server Protocol, consentendo agli agenti di generazione codice di Agentor di operare come assistenti di codifica intelligenti con contesto completo del progetto.
• Orchestrazione distribuita degli agenti -- Esecuzione multi-nodo degli agenti con distribuzione automatica del lavoro, tolleranza ai guasti e replicazione dello stato per deployment su scala enterprise.
• Editor visuale delle pipeline -- Uno strumento basato su browser per progettare flussi di agenti visivamente, con composizione drag-and-drop di strumenti, provider e pattern di orchestrazione.
• Supporto linguaggi esteso -- Le trasformazioni AST-aware attualmente supportano Rust, TypeScript e Python. Stiamo aggiungendo Go, Java e C# per coprire i linguaggi enterprise più comuni.
• Release open-source -- Stiamo preparando Agentor per il rilascio pubblico sotto una licenza open-source permissiva. I crate core, la documentazione e i progetti esempio saranno disponibili su GitHub.

Quello che è iniziato come un audit di sicurezza è diventato la base di come costruiamo sistemi alimentati dall'IA in Xcapit. Agentor non è solo un framework che vendiamo ai clienti: è il framework che usiamo internamente per il nostro sviluppo di AI agents, i nostri flussi di generazione di codice e i nostri deployment critici per la conformità. Ogni miglioramento che apportiamo è testato in battaglia nel nostro ambiente di produzione prima di raggiungere chiunque altro.

La lezione di questo percorso è una che continuiamo a reimparare nell'ingegneria del software: quando la base è sbagliata, nessuna quantità di patch la sistemerà. A volte la decisione responsabile è ricominciare da capo con i vincoli giusti, il linguaggio giusto e l'architettura giusta. Agentor è la nostra risposta alla domanda che non potevamo risolvere con le patch: come si costruiscono AI agents che siano abbastanza sicuri, veloci e affidabili per i sistemi che contano di più?