Sicurezza IA per Architettura | RAG Air-Gapped in Rust | Lexiane

La sicurezza di un sistema IA in produzione non si riduce a un elenco di misure applicate dopo il deployment. È la conseguenza di un insieme di decisioni architetturali prese a monte — sul linguaggio, sui confini del sistema, sulla gestione della memoria, sulle superfici di esposizione. Queste decisioni determinano ciò che un attaccante può raggiungere, ciò che il sistema può lasciar trapelare, e ciò che un revisore può verificare.

Lexiane è stato progettato con questa logica: ogni proprietà di sicurezza è garantita meccanicamente dal compilatore, verificata da un test automatizzato in integrazione continua, oppure resa fisicamente impossibile dall’architettura. Non esistono proprietà di sicurezza che si basano esclusivamente su convenzioni di sviluppo o sulla vigilanza individuale dei team.

---

Il panorama delle minacce specifiche ai sistemi RAG

I sistemi RAG introducono vettori di attacco che non esistono nei sistemi software tradizionali. L’OWASP ha pubblicato nel 2023, aggiornato nel 2025, un riferimento delle dieci categorie di rischio prioritarie per le applicazioni LLM — l’OWASP LLM Top 10. Tra le più critiche per un sistema di elaborazione documentale:

LLM01 — Iniezione di prompt. Un attaccante inserisce in una richiesta istruzioni destinate ad aggirare le politiche del sistema, a esfiltrare dati, o a produrre contenuti non conformi. In un sistema RAG esposto a utenti non completamente affidabili — agenti esterni, utenti interni con diritti limitati —, questo vettore è il più frequentemente sfruttato.

LLM06 — Divulgazione di informazioni sensibili. Il modello linguistico può produrre risposte che incorporano dati presenti nel contesto recuperato, inclusi dati personali o informazioni riservate che l’utente richiedente non dovrebbe vedere. In un corpus multi-utente, l’assenza di controllo degli accessi a livello di recupero crea questo rischio in modo sistematico.

LLM02 — Gestione non sicura degli output. Gli output del LLM sono utilizzati senza validazione sufficiente — in interfacce web (XSS), in chiamate di sistema, o ritrasmessi ad altri sistemi senza filtraggio. Gli output di un LLM sono dati non affidabili e devono essere trattati come tali.

LLM09 — Eccessiva fiducia negli output del modello. Un sistema che accetta e trasmette le risposte del LLM senza verificare il loro ancoraggio nelle fonti documentali apre la strada alla disinformazione operativa — risposte false presentate con la stessa apparenza di affidabilità delle risposte corrette.

A queste minacce specifiche agli LLM si aggiungono le minacce classiche amplificate dalla complessità degli stack IA: vulnerabilità di memoria introdotte dalle dipendenze C/C++ sottostanti ai framework Python, supply chain del software, superficie di attacco estesa dai processi secondari e dalle chiamate di rete.

Lexiane affronta ciascuna di queste categorie — con meccanismi distinti, verificabili e documentati.

---

Sicurezza della memoria: ciò che Rust esclude strutturalmente

La classe di vulnerabilità che Python e C++ non possono eliminare

Le vulnerabilità legate alla gestione della memoria — buffer overflow, use-after-free, double free, puntatore nullo deferenziato, race condition di memoria — costituiscono storicamente la maggioranza delle vulnerabilità di sicurezza critiche nei sistemi software. Google ha documentato nel progetto Android che l’adozione di Rust come linguaggio di sistema ha ridotto del 68% le vulnerabilità legate alla memoria in cinque anni. Microsoft ha stimato che il 70% dei CVE critici nei suoi prodotti ha origine in errori di gestione della memoria.

I framework RAG Python si basano su librerie C e C++ per le loro operazioni intensive — PyTorch, NumPy, i parser nativi, le librerie di compressione. Queste dipendenze ereditano tutte le classi di vulnerabilità dei linguaggi non memory-safe. Una vulnerabilità in una dipendenza transitiva — invisibile nel codice Python superficiale — può compromettere l’intero sistema.

Ciò che il compilatore Rust garantisce

Rust elimina per costruzione, a livello di compilatore, le intere categorie di bug di memoria menzionate sopra:

• Assenza di puntatori nulli deferenziati — i valori opzionali sono espressi tramite Option<T>, il cui trattamento esaustivo è richiesto dal compilatore.
• Assenza di use-after-free — il sistema di proprietà di Rust garantisce che una risorsa liberata non possa più essere acceduta. Questa proprietà è verificata staticamente, senza analisi dinamica.
• Assenza di data race — il sistema di tipi di Rust garantisce l’esclusione mutua tra accessi concorrenti mutabili. Una data race è un errore di compilazione, non una race condition scoperta in produzione.
• Assenza di overflow aritmetico non controllato — in modalità debug, gli overflow vengono rilevati e causano un panic. In modalità release, il comportamento è definito e configurabile — mai un comportamento indefinito sfruttabile.

#![forbid(unsafe_code)] sul perimetro certificato

Rust permette di scrivere codice “unsafe” — blocchi in cui le garanzie del compilatore sono sospese, necessari per interagire con interfacce C o con il sistema. Questa funzionalità è una botola: in una codebase senza disciplina, può reintrodurre le vulnerabilità che Rust dovrebbe eliminare.

Il nucleo certificato di Lexiane (vectrant-core) porta la direttiva #![forbid(unsafe_code)]. Questa direttiva non è una convenzione — è applicata dal compilatore. Nessuno sviluppatore può introdurre un blocco unsafe nel perimetro certificato, nemmeno inavvertitamente, nemmeno sotto pressione di scadenze. Il compilatore rifiuta il codice prima che il binario esista.

Nel dicembre 2023, la CISA (Cybersecurity and Infrastructure Security Agency) ha pubblicato “The Case for Memory Safe Roadmaps”, raccomandando esplicitamente l’adozione di linguaggi memory-safe — incluso Rust — per i sistemi critici. Il Dipartimento della Difesa americano e la Casa Bianca hanno emesso raccomandazioni convergenti. Lexiane soddisfa queste indicazioni per architettura.

---

Riduzione della superficie di attacco

Un binario, non un ecosistema

Ogni dipendenza esterna è un potenziale vettore di attacco. Un sistema Python in produzione espone una superficie di attacco estesa: l’interprete Python, i pacchetti installati tramite pip, le librerie di sistema condivise caricate dinamicamente, i processi secondari (server Ollama, API Redis, worker Celery). Un attaccante che compromette una dipendenza — tramite una vulnerabilità zero-day o un attacco alla supply chain — può compromettere l’intero sistema.

Lexiane si compila in un binario statico autonomo. Non carica librerie condivise a runtime. Non risolve dipendenze all’avvio. Non scarica codice esterno durante l’esecuzione. La superficie di attacco è delimitata dal binario stesso — un perimetro fisso, verificabile, riproducibile.

Sicurezza della supply chain

Gli attacchi alla supply chain del software — compromissione di un pacchetto open-source per iniettare codice malevolo nelle applicazioni che ne dipendono — sono in costante aumento. L’indice PyPI ha subito numerosi incidenti di questo tipo negli ultimi anni.

Lexiane affronta questo rischio con due meccanismi complementari:

Zero dipendenze vendor nel nucleo certificato. Il modulo vectrant-core — il cuore del sistema — non contiene alcuna dipendenza verso un editore terzo. Questo vincolo è verificato da un test automatizzato che fallisce alla compilazione se una dipendenza esterna viene introdotta. La regressione è impossibile senza essere immediatamente rilevata.

Compilazione con Ferrocene. Ferrocene è la versione qualificata del compilatore Rust sviluppata da Ferrous Systems — qualificata ISO 26262 ASIL D e IEC 61508 SIL 4. Compilare Lexiane con Ferrocene permette di stabilire una catena di fiducia completa per la certificazione: dal codice sorgente, al compilatore, fino al binario deployato. Un attaccante che volesse introdurre codice malevolo dovrebbe compromettere il compilatore stesso — la cui qualificazione impone una tracciabilità rigorosa.

Assenza di processi secondari

I framework RAG Rust alternativi — Swiftide, Rig — richiedono un server di inferenza esterno per la generazione di testo: un processo Ollama, un endpoint OpenAI, o un server vLLM. Questo server secondario è un componente di rete indipendente: la sua superficie di attacco si aggiunge a quella del framework RAG, e le comunicazioni tra i due componenti creano un canale potenzialmente intercettabile.

Lexiane incorpora l’inferenza LLM (Mistral.rs) e gli embedding (Candle) nello stesso binario. In configurazione locale, non c’è processo secondario, nessuna comunicazione di rete interna, nessun canale inter-processo da proteggere.

---

Sicurezza specifica ai sistemi IA

Difesa contro l’iniezione di prompt

La porta InputGuardrail di Lexiane implementa uno strato di validazione delle richieste in ingresso prima che raggiungano la pipeline di recupero o il modello linguistico. I pattern di iniezione di prompt — istruzioni nascoste nella richiesta, tentativi di aggirare le politiche del sistema, escalation dei privilegi tramite manipolazione del prompt — vengono rilevati e bloccati in questa fase.

Questo meccanismo opera a monte della pipeline: una richiesta bloccata dall’InputGuardrail non genera alcun embedding, non innesca alcun recupero, e non sollecita alcun LLM. Non c’è costo computazionale associato alle richieste malevole bloccate, e nessun rischio che il loro contenuto influenzi il comportamento del modello.

Controllo degli output del modello

La porta OutputGuardrail valida la risposta prodotta prima della trasmissione all’utente. Tre categorie di rischio vengono affrontate:

Fuga di dati sensibili. Il LLM può incorporare nella sua risposta dati presenti nel contesto recuperato — inclusi dati personali che l’utente non avrebbe dovuto vedere, o informazioni riservate provenienti da documenti accessibili tramite il meccanismo di recupero. L’OutputGuardrail rileva queste fughe e le blocca prima della trasmissione.

Contenuto tossico o non conforme. Le risposte che violano le politiche di contenuto definite dall’organizzazione — contenuto discriminatorio, istruzioni pericolose, contenuto fuori perimetro — vengono intercettate prima di raggiungere l’utente.

Risposte non ancorate. Il FaithfulnessChecker verifica che la risposta prodotta sia effettivamente supportata dalle fonti recuperate. Una risposta che estrapola al di là del contesto fornito — ovvero un’allucinazione — viene rilevata e può innescare un’astensione o una segnalazione.

Controllo degli accessi a livello documentale

La porta AccessControl implementa un filtraggio dei risultati di recupero basato sui diritti dell’utente richiedente. Questo filtraggio opera prima della generazione: i documenti a cui l’utente non ha accesso non vengono trasmessi al LLM come contesto.

Questa posizione nella pipeline è critica. Un controllo degli accessi che si applica solo sull’interfaccia — mascherando alcune risposte nell’UI — lascia che dati sensibili attraversino il modello linguistico. Un LLM che ha ricevuto un documento riservato nel suo contesto può rivelarne il contenuto in modo indiretto, anche se la risposta finale sembra non farvi riferimento. Lexiane taglia questo vettore alla fonte.

Due modelli di controllo degli accessi sono supportati:

• RBAC (Role-Based Access Control) — i diritti di accesso sono definiti dal ruolo dell’utente nell’organizzazione.
• ABAC (Attribute-Based Access Control) — i diritti di accesso sono definiti da attributi contestuali: classificazione del documento, reparto proprietario, livello di sensibilità, data di pubblicazione.

Il gate di pertinenza come difesa contro la disinformazione operativa

Il RelevanceGateStage valuta il punteggio di fiducia globale del contesto recuperato prima della generazione. Al di sotto della soglia configurata, il sistema si astiene dal generare una risposta e lo segnala esplicitamente.

Questo comportamento di astensione è una misura di sicurezza operativa: in un ambiente decisionale — medico, legale, industriale, di intelligence —, una risposta mal fondata presentata con la stessa apparenza di una risposta affidabile è più pericolosa dell’assenza di risposta. Lexiane preferisce la trasparenza sull’insufficienza alla produzione di una risposta non supportata.

---

Protezione dei dati

Il filtro PII come barriera di prima linea

Il filtro PII opera a monte dell’intera pipeline di elaborazione documentale — prima di qualsiasi embedding, prima di qualsiasi indicizzazione, prima di qualsiasi chiamata al LLM. I dati personali rilevati nei documenti ingeriti sono trattati secondo politiche configurabili: mascheramento tipizzato, eliminazione, hash crittografico.

L’audit trail registra, per ogni documento, le categorie di dati personali rilevate e le politiche applicate. Questo registro costituisce la prova tecnica del trattamento conforme — utilizzabile nell’ambito di un controllo GDPR.

La residenza dei dati come garanzia fisica

In configurazione air-gapped, i dati non lasciano il perimetro perché l’architettura lo rende fisicamente impossibile — non perché un contratto lo vieti. Il binario non dispone di alcuna interfaccia di rete attiva verso l’esterno. Non ci sono flussi da monitorare, nessun impegno contrattuale da verificare: la proprietà è meccanica.

Questa distinzione — garanzia architetturale versus garanzia contrattuale — è fondamentale per le organizzazioni i cui dati sono soggetti a un requisito di localizzazione rigoroso: difesa, intelligence, sanità, settore pubblico soggetto a riferimenti di cloud sovrano.

---

Audit e forensica

Una catena SHA-256 inviolabile

Ogni azione della pipeline è registrata in una catena di audit crittografica: ogni voce è firmata dall’hash SHA-256 della precedente. Qualsiasi modifica retroattiva di un record — eliminazione di un accesso, alterazione di un timestamp, modifica di una politica applicata — rompe la catena ed è matematicamente rilevabile.

In caso di incidente di sicurezza, questa catena permette una ricostruzione forense completa: chi ha avuto accesso a cosa, in quale momento, con quale risultato, secondo quale politica di filtraggio. L’indagine non dipende dalla disponibilità di log applicativi che potrebbero essere stati alterati o eliminati. La catena è la prova.

Eventi registrati:

Evento	Dati registrati
Documento ingerito	Identificatore, hash del contenuto, timestamp, collezione
Dati personali rilevati	Categorie, politica applicata, posizione nel documento
Richiesta utente	Identificatore utente, testo della richiesta, timestamp
Documenti recuperati	Identificatori, punteggi di pertinenza, accesso concesso o negato
Risposta prodotta	Hash della risposta, fonti citate, punteggio di fedeltà
Guardrail attivato	Tipo di guardrail, motivo del blocco, identificatore utente

Assenza di canali di fuga tramite i log

Un vettore di fuga di dati comunemente trascurato nei sistemi IA è la registrazione applicativa: dati sensibili presenti nelle richieste o nelle risposte che finiscono in chiaro nei log di sistema. Lexiane vieta per convenzione di sviluppo l’uso di println!() nell’intero codice di produzione. Qualsiasi emissione di log passa attraverso il framework tracing, con livelli di verbosità controllabili e filtri di strutturazione. Questa proprietà è verificata in integrazione continua.

---

Ciò che il vostro team di sicurezza può verificare

La sicurezza di Lexiane non si basa su affermazioni. Ogni proprietà è verificabile nel codice sorgente, negli artefatti di build, o dimostrabile tramite ispezione del binario.

Proprietà di sicurezza	Meccanismo di verifica
Assenza di codice unsafe nel nucleo	#![forbid(unsafe_code)] — ispezione del codice sorgente
Assenza di unwrap() / panic!() in produzione	Test automatizzato in CI — risultato verificabile nella suite di test
Zero dipendenze vendor nel nucleo	Test automatizzato alla compilazione — vectrant-core/Cargo.toml ispezionabile
Integrità dell’audit trail	Proprietà crittografica SHA-256 — verificabile algoritmicamente
Filtraggio PII prima dell’indicizzazione	Posizione nella pipeline — ispezionabile nell’ordine degli stage di ingestione
Controllo degli accessi prima della generazione	Posizione della porta AccessControl nella pipeline — ispezionabile nell’assemblaggio
Assenza di println!()	Verificabile tramite grep sull’intero codice sorgente
Validazione statica della configurazione	Proprietà dell’assemblatore — ispezionabile nei test di assemblaggio
Nessuna chiamata di rete in modalità air-gapped	Ispezionabile nella configurazione degli adattatori attivi

---

Domande frequenti dei team di sicurezza e CISO

Avete effettuato un pentest su Lexiane? I risultati di un audit di sicurezza esterno sono disponibili su richiesta nell’ambito di una discussione qualificata. Le proprietà meccaniche descritte in questo documento — assenza di codice unsafe, superficie di attacco ridotta al binario, catena di audit inviolabile — sono verificabili indipendentemente dal vostro team di sicurezza o da un prestatore di vostra scelta.

Lexiane è conforme al riferimento OWASP LLM Top 10? L’architettura di Lexiane affronta direttamente le categorie LLM01 (iniezione di prompt tramite InputGuardrail), LLM02 (validazione degli output tramite OutputGuardrail e FaithfulnessChecker), LLM06 (filtraggio PII e AccessControl prima della generazione), e LLM09 (gate di pertinenza e astensione). La valutazione completa della conformità OWASP per il vostro deployment specifico rimane da effettuare in base al vostro contesto.

Come gestire i segreti — chiavi API, token — nella configurazione? Lexiane segue la convenzione api_key_env: i campi di configurazione referenziano il nome della variabile d’ambiente contenente la chiave, mai la chiave stessa. I segreti non transitano nei file di configurazione TOML. Vengono iniettati tramite variabili d’ambiente all’avvio — compatibili con i gestori di segreti standard (Vault, Kubernetes Secrets, AWS Secrets Manager).

Qual è la politica di gestione delle dipendenze e dei CVE? Le dipendenze del progetto sono soggette a un audit di sicurezza automatizzato (cargo audit) in integrazione continua. I CVE rilevati nelle dipendenze attivano un avviso immediato. Il numero di dipendenze attive è mantenuto il più basso possibile — ogni dipendenza aggiunta è una decisione deliberata, non un effetto collaterale.

È possibile deployare Lexiane in un ambiente con un firewall applicativo (WAF)? Sì. L’API REST di Lexiane è un’API HTTP standard, compatibile con tutti i WAF sul mercato. In configurazione air-gapped, la questione del WAF si applica solo ai flussi interni — Lexiane stesso non avvia alcun flusso di rete in uscita.

Come isolare i diritti di accesso tra più team che utilizzano lo stesso deployment Lexiane? La porta AccessControl permette una segmentazione dei diritti a livello documentale. I documenti ingeriti possono essere etichettati con attributi di classificazione (RBAC o ABAC), e i diritti di accesso vengono verificati al recupero — prima che il contesto venga trasmesso al modello. Più team possono condividere la stessa infrastruttura senza che i loro corpus documentali si mescolino nelle risposte.

---

Avviamo la conversazione sul vostro modello di minaccia.

La sicurezza di un sistema IA si costruisce su un’analisi delle minacce propria al vostro contesto: il vostro settore, il vostro modello di accesso utente, la vostra infrastruttura di deployment, e i vostri requisiti regolatori. Non proponiamo valutazioni generiche.

Proponiamo uno scambio strutturato con un team che conosce i vettori di attacco specifici ai sistemi RAG, i vincoli degli ambienti regolamentati, e le prove che l’architettura di Lexiane permette di fornire ai vostri team di sicurezza.

Cosa potete aspettarvi:

• Una risposta entro 48 ore lavorative
• Un interlocutore tecnico che conosce l’OWASP LLM Top 10, i vincoli degli ambienti classificati, e i requisiti di certificazione
• Una mappatura onesta di ciò che l’architettura di Lexiane copre — e di ciò che rimane di vostra responsabilità

→ Contattaci

Nessun impegno commerciale. Una discussione di sicurezza.

---

Riferimenti citati in questo documento: — OWASP LLM Top 10, versione 1.1 (2023), aggiornamento 2025 — owasp.org/www-project-top-10-for-large-language-model-applications — CISA, “The Case for Memory Safe Roadmaps”, dicembre 2023 — Google, “Memory Safe Languages in Android 13”, Android Security Blog — NIST AI Risk Management Framework 1.0, gennaio 2023 — Regolamento (UE) 2016/679 (GDPR)