Cos'è Tex: il semaforo prima dell'azione
Tex è un progetto open-source che introduce un concetto semplice ma poco diffuso nel mondo degli agenti AI: un gate di runtime. Invece di lasciare che un modello linguistico decida da solo cosa fare e registrare tutto a posteriori nei log, Tex si mette in mezzo, nel percorso tra intenzione ed esecuzione, e pronuncia un verdetto per ogni singola azione: PERMIT, ABSTAIN o FORBID.
PERMIT significa via libera, l'azione può procedere. ABSTAIN significa astensione prudente, il sistema dichiara di non avere elementi sufficienti per decidere in sicurezza e chiede una revisione, un approfondimento o un intervento umano. FORBID significa divieto strutturale, l'azione viene bloccata anche se il modello la riteneva opportuna. È questa la differenza fondamentale rispetto a dashboard, monitoraggio di uptime ed errori o audit trail: quei sistemi raccontano dopo cosa è successo, Tex prova a impedire prima che accada l'irreparabile.
Il progetto, pubblicato su GitHub dall'autore MattNardizzi, è pensato per scenari moderni in cui gli agenti non si limitano a rispondere in chat, ma operano tramite strumenti concreti: chiamate a API, server MCP in entrambe le direzioni, automazioni browser, scrittura su file system e database, invio di email e messaggi, operazioni su gestionali e CRM. Con decine di servizi collegati, il rischio non è più solo una risposta sbagliata, ma un'azione sbagliata. Tex vuole essere il pavimento deterministico sotto i piedi dell'agente.
Altro elemento distintivo sono le ricevute. Ogni decisione genera un bundle sigillato con concatenamento hash, riverificabile offline senza dover fidarsi del server che lo ha prodotto. In pratica è possibile dimostrare in un secondo momento cosa è stato chiesto, cosa è stato deciso, con quali regole e in quale sequenza, con una catena che rende evidenti eventuali manomissioni. Per chi lavora con clienti, fornitori e revisori, è una base di trasparenza molto diversa dal semplice file di log.
A cosa serve: casi concreti per founder, PMI e agenzie
Per un founder o una piccola impresa italiana, la domanda giusta non è se Tex sia affascinante dal punto di vista tecnico, ma quali problemi pratici aiuta a contenere. Il primo è l'agente che fa troppo. Un assistente collegato alla casella email, al gestionale o all'e-commerce può inavvertitamente inviare un preventivo sbagliato, stornare un ordine, cancellare documenti, pubblicare un post non approvato o condividere dati personali con un destinatario errato. Un gate che impone un FORBID su intere classi di azioni, ad esempio cancellazioni massive, esportazioni di anagrafiche o pagamenti sopra una soglia, riduce la superficie di danno.
Il secondo caso è l'agente che si fida troppo. Gli agenti moderni leggono contenuti non affidabili: pagine web, documenti caricati dai clienti, descrizioni di tool esterni, skill scaricate, risposte di altri agenti. Da lì possono nascere prompt injection, istruzioni nascoste e comportamenti manipolati. Tex non sostituisce uno scanner preventivo dei contenuti, ma aggiunge un controllo al momento dell'uso: anche se il contenuto è ambiguo, l'azione sensibile può essere fermata o messa in attesa.
Il terzo caso è tipico delle agenzie. Un'agenzia marketing che usa agenti per pubblicare campagne, un'agenzia software che lascia agli agenti attività di deploy o migrazione dati, uno studio che automatizza fatturazione e scadenze: in tutti questi contesti il cliente finale chiede garanzie. Poter dire che esiste una policy esplicita, versionata, che vieta certe operazioni e produce evidenze verificabili, è un argomento commerciale e contrattuale, oltre che tecnico. Non elimina la responsabilità umana, ma la rende gestibile.
Infine c'è il tema della sperimentazione controllata. Molte PMI vogliono provare agenti autonomi ma temono di dare loro chiavi e permessi reali. Un gate in modalità affiancata, prima in sola osservazione e poi con blocco attivo, permette di partire in sandbox, misurare quante azioni sarebbero state bloccate e capire dove le policy sono troppo strette o troppo larghe, senza esporre dati di produzione.
Come funziona: policy, recognizer, decisioni e blocco eBPF
Il flusso dichiarato dall'autore è lineare. L'agente non esegue direttamente il tool, ma dichiara un'intenzione strutturata: quale operazione vuole fare, su quale risorsa, con quali parametri e in quale contesto. Tex intercetta questa intenzione prima dell'esecuzione e la sottopone a una pipeline di valutazione.
Al centro ci sono policy leggibili e recognizer specializzati. Le policy descrivono cosa è vietato, cosa richiede cautela e cosa è libero, ad esempio divieto di scrittura fuori da certe directory, divieto di invio verso domini esterni, limiti di importo, vincoli su orari e ruoli. I recognizer analizzano la richiesta per riconoscere pattern rischiosi, combinazioni pericolose di parametri, contesti anomali o sequenze sospette. Il risultato non è un punteggio vago, ma una delle tre decisioni previste, con motivazione allegata alla ricevuta.
L'esecuzione della decisione avviene su due livelli. Il primo è a livello applicativo, come sidecar dell'orchestratore: se il verdetto è PERMIT, la chiamata procede verso il tool reale; se è ABSTAIN, viene congelata e instradata verso revisione; se è FORBID, viene negata e registrata. Il secondo livello, più ambizioso, è a livello kernel tramite eBPF e moduli di sicurezza Linux. In questo caso il divieto non è solo una raccomandazione rispettata dal codice collaborativo, ma un diniego imposto dal sistema operativo, con errore di permesso che blocca anche tentativi di aggiramento dal processo controllato.
Le ricevute hash-chained completano il quadro. Secondo quanto descritto nel README, ogni bundle contiene intenzione, decisione, regole applicate e collegamenti crittografici al bundle precedente, così da poter riverificare l'intera sequenza offline. L'autore dichiara tempi di valutazione molto bassi nell'ordine di pochi millisecondi per i casi semplici e intorno ai 18 millisecondi per i casi complessi sulla propria macchina di test nel giugno 2026, oltre a una demo pubblica. Questi numeri vanno letti come indicazioni dell'autore sulla propria configurazione, non come garanzie sul proprio hardware, e l'efficacia reale contro tecniche di elusione non è verificabile dalla sola documentazione.
Per la prova tecnica, il repository propone un avvio rapido in Python con ambiente virtuale, installazione delle dipendenze e script dimostrativo, oltre a documenti di riproduzione e sfida pensati per testare il sistema in lettura, senza fornire segreti reali. È l'approccio corretto per una valutazione prudente: copia isolata, nessun collegamento a sistemi di produzione, analisi statica prima di qualsiasi esecuzione.
Perché conta: dalla chatbot all'agente che agisce
Il passaggio degli ultimi due anni è chiaro: siamo passati da chatbot che rispondono a agenti che agiscono. Con il protocollo MCP e le integrazioni bidirezionali, un agente può leggere il gestionale, scrivere nel CRM, interrogare documenti interni, pilotare un browser e richiamare altri agenti. La potenza cresce, ma cresce anche la possibilità di errore a cascata. I controlli tradizionali, come monitoraggio errori, allarmi di disponibilità e revisione umana a campione, restano necessari ma non bastano più, perché intervengono quando il danno è già avvenuto.
Tex rappresenta un cambio di paradigma: governance deterministica invece di sola osservazione. Deterministica significa che la regola è scritta, versionata e applicata allo stesso modo indipendentemente dall'umore del modello, dalla formulazione del prompt o dalla lingua usata per convincerlo. Se la policy dice che l'agente vendite non può esportare l'intero archivio clienti, quel divieto vale anche se un testo malevolo nascosto in una pagina web gli ordina di farlo. È un pavimento, non un suggerimento.
Per il contesto italiano questo è rilevante per tre motivi. Il primo è la protezione dei dati: con il Regolamento europeo sulla protezione dei dati e l'attenzione del Garante, impedire esportazioni massive o condivisioni improprie è molto meglio che doverle notificare dopo. Il secondo è il nuovo quadro europeo sull'intelligenza artificiale, che spinge verso tracciabilità, supervisione umana e gestione del rischio per i sistemi più impattanti. Ricevute verificabili e decisioni spiegate aiutano a costruire fascicoli tecnici credibili. Il terzo è la fiducia commerciale: una PMI che affida a un fornitore processi critici vuole vedere non solo che l'AI funziona, ma che non può oltrepassare certi confini.
Va detto con onestà che Tex non risolve da solo la sicurezza agentica. Va affiancato a igiene preventiva dei contenuti e dei tool, a gestione rigorosa di credenziali e permessi minimi, a revisione umana per le azioni ad alto impatto e a test continui di robustezza. ABSTAIN è utile solo se esiste davvero qualcuno o qualcosa che gestisce la coda delle astensioni in tempi ragionevoli, altrimenti diventa un collo di bottiglia. E il blocco a livello kernel richiede competenze Linux avanzate e una valutazione attenta dei rischi operativi.
Dove trovarlo, licenza e come valutarlo con prudenza
Il codice è pubblicato su GitHub all'indirizzo github.com/MattNardizzi/tex. I metadati API riportano una licenza Apache-2.0, indicazione utile per un riuso anche commerciale, ma che va sempre confermata leggendo il file LICENSE nel repository prima di qualsiasi adozione, perché i metadati da soli non sono una verifica legale. La documentazione include descrizione dell'architettura, esempi e materiali per riprodurre i test e mettere alla prova il gate con scenari avversariali.
Per una PMI o un'agenzia senza un team di ricerca dedicato, il percorso consigliato è in tre passi. Prima, studio a tavolino: leggere README, esempi di policy e formato delle ricevute, e chiedersi quali tre o cinque divieti strutturali avrebbero davvero senso per la propria attività. Poi, prova in laboratorio isolato: clonare una copia in una macchina di test scollegata dai dati reali, creare l'ambiente virtuale Python, eseguire lo script di avvio rapido senza inserire chiavi o dati clienti, e osservare quante azioni di prova vengono permesse, sospese o vietate. Solo infine, integrazione graduale come sidecar in sola osservazione accanto all'orchestratore esistente, per confrontare le decisioni del gate con quelle che un revisore umano avrebbe preso.
I limiti da tenere presenti sono quelli tipici di ogni progetto emergente: affermazioni di performance legate all'hardware dell'autore, copertura dei recognizer tutta da misurare sul proprio dominio e in italiano, robustezza del modulo eBPF da validare da specialisti, maturità complessiva da valutare leggendo issue, test automatici e frequenza di aggiornamento. Nessuna di queste cautele toglie valore all'idea di fondo.
In sintesi, Tex merita attenzione perché sposta il baricentro dalla domanda posso fidarmi del modello alla domanda posso vincolare ciò che il modello può fare. Per founder e PMI che vogliono usare agenti AI su processi reali senza rinunciare a controllo ed evidenze, è una direzione concreta da studiare, provare in sicurezza e seguire nel tempo.