🤖 AI

Certified Purity for Cognitive Workflow Executors: From Static Analysis to Cryptographic Attestation

Questo documento introduce un'architettura di purezza certificata che rafforza la governance dei flussi di lavoro cognitivi sostituendo le convenzioni runtime con confini strutturali mediante compilazione WebAssembly ristretta, certificati di purezza crittografici e attestazione remota, dimostrando così matematicamente l'eliminazione dei bypass avversari mantenendo al contempo un sovraccarico runtime trascurabile.

Autori originali: Alan L. McCann

Pubblicato 2026-05-06

📖 5 min di lettura🧠 Approfondimento

CC0 1.0

Autori originali: Alan L. McCann

Articolo originale dedicato al pubblico dominio sotto CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di gestire una cucina ad alto rischio dove un team di chef (agenti AI) prepara pasti complessi (flussi di lavoro cognitivi) per ospiti VIP. Le regole sono severe: gli chef possono pianificare il pasto e scrivere gli ingredienti di cui hanno bisogno, ma è rigorosamente vietato toccare effettivamente il fornello, aprire il frigorifero o chiamare il corriere. Solo lo Chef Capo (la "Pipeline di Governance") è autorizzato a compiere tali azioni.

Per molto tempo, la cucina si è affidata a una regola semplice: "Fidati degli chef di seguire le regole". I manager della cucina esaminavano i libri delle ricette degli chef (analisi statica) per verificare se avessero scritto istruzioni vietate. Se la ricetta sembrava pulita, allo chef era permesso lavorare.

Il Problema: La falla del "Trucco Magico"
Il documento spiega che questo sistema basato sulla "fiducia nella ricetta" presenta un difetto fatale. Uno chef determinato e astuto potrebbe usare trucchi magici per aggirare le regole senza scriverli nel libro delle ricette. Sulla specifica piattaforma culinaria utilizzata (chiamata BEAM/Erlang), uno chef potrebbe:

Fingere di essere qualcun altro: Chiamare una funzione per nome nell'ultimo istante, nascondendo il fatto che sta chiamando uno strumento pericoloso.
Scrivere nuove regole al volo: Digitare un nuovo comando mentre cucina, riscrivendo di fatto la propria ricetta a metà pasto.
Assumere una guardia del corpo: Caricare uno strumento segreto e pre-scritto (un "NIF") che può fare qualsiasi cosa, incluso aprire il frigorifero.
Inviare un corriere: Generare una persona separata fuori dalla cucina per andare a prendere gli ingredienti.
Sostituire il libro delle ricette: Caricare un libro delle ricette completamente diverso e pericoloso mentre si cucina.

Poiché questi trucchi avvengono mentre lo chef sta lavorando, esaminare il libro delle ricette in precedenza (analisi statica) non può individuarli. È come cercare di fermare un mago controllando le sue tasche prima dello spettacolo; potrebbe avere una carta nascosta che estrarrà più tardi.

La Soluzione: La Cucina della "Purezza Certificata"
Questo documento propone una nuova progettazione radicale della cucina che rende questi trucchi magici fisicamente impossibili, non solo vietati dalle regole.

1. La Nuova Cucina (Sandbox WebAssembly)
Invece di lasciare che gli chef lavorino nella cucina aperta, ora lavorano all'interno di una scatola di vetro trasparente e sigillata.

Nessun Trucco Magico: All'interno di questa scatola, gli strumenti per "nascondersi", "riscrivere" o "assumere guardie del corpo" semplicemente non esistono. La scatola è costruita in modo che l'unico modo per uscire sia attraverso un'unica porta bloccata.
La Lista Bianca: La scatola possiede solo un elenco specifico di strumenti che può utilizzare (come una calcolatrice, un blocco note e un "modulo di richiesta"). Non può toccare il fornello o il frigorifero. Se uno strumento non è nell'elenco, la scatola letteralmente non ha la maniglia per esso.

2. Il Badge d'Identità (Certificato di Purezza)
Prima che uno chef entri in cucina, deve ottenere un badge speciale.

La Prova: Un'autorità fidata esamina il codice dello chef (il "binario") e verifica che utilizzi solo gli strumenti consentiti.
Il Sigillo: Firmano il badge con un sigillo crittografico (come un timbro di cera). Questo sigillo dimostra che questa specifica versione del codice dello chef è pulita.
Anti-Manomissione: Se lo chef tenta di modificare il proprio codice anche leggermente (per aggiungere uno strumento segreto), il sigillo si rompe. Il badge diventa invalido. Non è possibile prendere un badge pulito dallo Chef A e darlo a uno Chef B modificato.

3. La Guardia di Sicurezza (Cancello Runtime)
Quando uno chef arriva alla porta della cucina, una guardia di sicurezza controlla il badge.

Il Controllo: La guardia verifica il sigillo, controlla che il codice corrisponda al badge e conferma che gli strumenti elencati siano ancora nella lista "consentita".
Il Risultato: Se il badge è valido, lo chef entra. Se non lo è, viene respinto immediatamente. Questo accade ogni singola volta prima che lo chef inizi a cucinare.

4. Il Passaporto Inter-Cucina (Attestazione Remota)
Cosa succede se lo Chef A lavora nella Cucina A, ma deve assumere lo Chef B dalla Cucina B?

Lo Chef B porta un "Passaporto" (un registro di attestazione) che dimostra di essere stato controllato dalla propria guardia di sicurezza della cucina e che la sua cucina segue le stesse regole severe.
La Cucina A può leggere questo passaporto e fidarsi dello Chef B senza bisogno di vedere il codice sorgente dello Chef B o firmare un contratto. È una prova di fiducia leggibile dalla macchina.

Perché Questo è Importante (I Risultati)
Il documento dimostra che questo sistema funziona matematicamente:

Nessuna Falla: Poiché i "trucchi magici" (classi di aggiramento) sono strutturalmente assenti dalla nuova cucina, uno chef astuto non può letteralmente eseguirli. Non è che vengano catturati; è che non possono accadere.
Veloce: Controllare il badge richiede meno di un battito di ciglia (circa 40 microsecondi). Il tempo aggiuntivo che aggiunge alla preparazione di un pasto è inferiore allo 0,4% del tempo necessario ad aspettare un camion delle consegne.
Senza Fiducia: Non devi fidarti dello chef, del manager della cucina o dell'altra cucina. Devi solo fidarti della matematica dietro il sigillo e della progettazione della scatola di vetro.

In Sintesi
Il documento sposta la governance da un cartello "Per favore non rubare" (che si basa sul fatto che le persone seguano le regole) a un muro "Non puoi fisicamente rubare" (che si basa sulla struttura dell'edificio). Trasforma una promessa in una garanzia matematica, assicurando che gli agenti AI possano pianificare e pensare, ma non possano mai agire segretamente al di fuori delle regole.

Sintesi Tecnica: Purezza Certificata per gli Esecutori dei Flussi di Lavoro Cognitivi

1. Il Problema: Il Divario di Purezza nei Flussi di Lavoro Cognitivi

I sistemi di flusso di lavoro cognitivo (che orchestrano inferenza AI, utilizzo di strumenti e ragionamento) operano sempre più in domini ad alto rischio. Lavori precedenti (McCann [2026e]) hanno stabilito un'architettura di governance a tre livelli che garantisce Completezza della Governance, Completezza della Provenienza e l'Impossibilità di Effetti Non Governati. Tuttavia, questi teoremi di sicurezza si basavano su un presupposto critico: il Vincolo del Modulo Puro, che richiede che i moduli esecutori non possano eseguire effetti di I/O e possano restituire solo direttive dichiarative.

Nell'implementazione precedente, questo vincolo era imposto tramite analisi statica del grafo di importazione dei moduli sulla macchina virtuale BEAM (Erlang/OTP). Sebbene più forte della governance basata su convenzioni, questo meccanismo è insufficiente contro aggiramenti avversari. Le funzionalità dinamiche del BEAM permettono cinque distinte classi di aggiramento che l'analisi statica non può prevenire in modo affidabile:

Dispatch Dinamico: Utilizzo di :erlang.apply/3 per invocare funzioni arbitrarie senza importazioni statiche.
Valutazione del Codice: Utilizzo di Code.eval_string/1 per eseguire codice arbitrario a runtime.
Funzioni Implementate Nativamente (NIF): Caricamento di librerie condivise con accesso illimitato al sistema.
Port: Avvio di processi esterni tramite :erlang.open_port/2.
Caricamento Dinamico dei Moduli: Caricamento di bytecode arbitrario a runtime tramite :code.load_binary/3.

A causa del Teorema di Rice, nessuna analisi statica può decidere la proprietà semantica non banale di "nessun effetto di I/O" per tutti i programmi possibili. Una sovrastima corretta rifiuterebbe la maggior parte del codice Elixir idiomatico legittimo. Questo crea un divario di purezza: il modello formale assume la purezza, ma il meccanismo di applicazione (analisi statica) non può garantire strutturalmente tale proprietà contro un avversario determinato.

2. Metodologia: Dalla Rilevazione alla Prevenzione Strutturale

Questo articolo propone un'Architettura di Purezza Certificata che converte il vincolo del modulo puro da una convenzione imposta dall'analisi a un limite di capacità strutturale imposto dall'ambiente di esecuzione. La metodologia si basa su quattro meccanismi fondamentali:

A. Target di Compilazione Restretto (WebAssembly)

Gli esecutori sono compilati in un target WebAssembly (WASM) ristretto. Il modello di capacità di WASM è sfruttato per eliminare strutturalmente tutte e cinque le classi di aggiramento del BEAM:

Nessun Dispatch Dinamico: WASM manca di istruzioni per risolvere le chiamate di funzione tramite nomi di stringhe/atom a runtime; le chiamate sono limitate a indici statici in una tabella di funzioni.
Nessuna Valutazione del Codice: WASM esegue bytecode precompilato; non esiste alcun meccanismo per generare o caricare nuovo codice a runtime.
Nessuna NIF/Port: I moduli WASM vengono eseguiti in una VM sandboxata senza accesso ai file system host, alle librerie condivise o all'avvio di processi.
Nessun Caricamento Dinamico: L'istanziazione del modulo è controllata interamente dall'host; i moduli non possono caricare altri moduli.

B. La Whitelist delle Funzioni Host ( $W$ )

Il modulo WASM può invocare solo funzioni dichiarate esplicitamente nella sua sezione di importazione. Queste importazioni sono limitate a una Whitelist ( $W$ ) finita ed enumerata:

$W_{data}$ : Operazioni dati pure (gestione della memoria, manipolazione delle stringhe, aritmetica, serializzazione JSON, letture del contesto).
$W_{dir}$ : Costruttori di direttive (funzioni che costruiscono strutture dati che rappresentano effetti intenzionali, ad esempio directive_http_request, ma non li eseguono).
Esclusione: Le importazioni WASI (WebAssembly System Interface), che concedono capacità di effetto, sono esplicitamente escluse.

C. Certificati di Purezza

Un Certificato di Purezza è un artefatto di prova crittografico che vincola un binario esecutore alla sua classificazione di purezza.

Struttura: Contiene l'hash SHA-256 del binario esecutore, l'hash della prova di purezza (elenco delle importazioni + classificazione) e una firma Ed25519 su questi hash.
Integrità: A causa della resistenza alle collisioni di SHA-256 e dell'inaffalsabilità di Ed25519, un certificato non può essere trasferito a un artefatto modificato.

D. Cancello di Verifica a Runtime

Prima che un esecutore entri nella pipeline di governance, un Cancello di Verifica esegue:

Verifica della Firma: Convalida la firma Ed25519.
Vincolo dell'Artefatto: Conferma che l'hash del binario corrisponda al certificato.
Derivazione Indipendente della Prova: Analizza la sezione di importazione del binario WASM ex novo e verifica che corrisponda alla prova di purezza rivendicata rispetto alla whitelist corrente.
Convalida della Classificazione: Assicura che tutte le importazioni siano classificate come pure.

Solo gli esecutori che superano questo cancello vengono istanziati. Questo cancello agisce come precondizione strutturale, garantendo che nessun esecutore privo di un certificato di purezza valido possa essere eseguito.

3. Contributi Chiave

Modello di Minaccia Formale: Una caratterizzazione rigorosa delle cinque classi di aggiramento del BEAM e dei limiti teorici dell'analisi statica (Teorema di Rice) in questo contesto.
Purezza Strutturale per Costruzione: Una prova (Teorema 4.5) che la compilazione verso il target WASM ristretto soddisfa il vincolo del modulo puro per costruzione, indipendentemente dal contenuto del codice dell'esecutore.
Eliminazione degli Aggiramenti: Prove formali (Teorema 5.5) che ciascuna delle cinque classi di aggiramento del BEAM è strutturalmente impossibile nell'ambiente WASM ristretto.
Attestazione Crittografica: Uno schema per Certificati di Purezza e Record di Attestazione Remota che abilita la verifica portabile e inter-organizzativa della purezza degli esecutori senza accesso al codice sorgente.
Definizione della Base di Calcolo Fiduciaria (TCB): Una definizione esplicita dei cinque componenti richiesti per la garanzia (runtime WASM, funzioni host, whitelist, cancello di verifica, interprete delle direttive), riducendo la superficie di fiducia dal codice dell'esecutore illimitato a un insieme limitato e auditabile.
Livelli di Fiducia Graduali: Un'architettura di implementazione che supporta tre livelli (Purezza Verificata, Analisi Statica, Sperimentale) per consentire un'adozione incrementale.

4. Risultati e Valutazione

L'architettura è stata valutata su quattro esecutori implementati (basati su Rust, compilati in WASM) eseguiti su un processore Apple serie M con il backend JIT Wasmtime.

Latenza di Verifica: Il cancello di verifica richiede 39–42 µs (mediana) per gli esecutori di produzione. Con la memorizzazione nella cache basata su hash, il costo ammortizzato si avvicina a zero per invocazioni ripetute.
Sovraccarico a Runtime: L'intero ciclo di pianificazione (istanziazione, esecuzione, deserializzazione) si completa in 256–398 µs. Questo rappresenta un sovraccarico <0,4% su una richiesta HTTP di 100 ms e <0,05% su una chiamata LLM tipica di 800 ms.
Determinismo: Non sono state osservate divergenze su 40 invocazioni ripetute con input identici, confermando la natura deterministica dell'ambiente di esecuzione WASM.
Dimensione del Certificato: I certificati sono compatti (~1,3 KB), ben entro i budget di larghezza di banda.
Correttezza: Tutti gli esecutori hanno prodotto le forme di direttiva attese e il sistema ha mantenuto output byte-identici tra le esecuzioni.

5. Significato e Affermazioni

L'articolo rivendica un cambiamento fondamentale nello status epistemologico delle garanzie di governance:

Dalla Rilevazione alla Prevenzione: Gli approcci precedenti si basavano sulla rilevazione di pattern di aggiramento noti tramite analisi statica. Questa architettura previene l'aggiramento rendendo strutturalmente assenti le capacità di produzione di effetti.
Rafforzamento dei Teoremi Esistenti: I teoremi di sicurezza di McCann [2026e] (Completezza della Governance, Completezza della Provenienza, Nessun Effetto Non Governato) rimangono formalmente identici. Tuttavia, il loro presupposto fondante è scaricato meccanicamente piuttosto che assunto. La garanzia poggia ora sulle proprietà matematiche del modello di capacità di WASM e sui primitivi crittografici (SHA-256, Ed25519) piuttosto che sui limiti di un analizzatore statico.
Fiducia Portabile: Convertendo le prove di purezza locali in record di attestazione portabili, l'architettura abilita la composizione della governance inter-organizzativa, consentendo all'Organizzazione A di verificare crittograficamente la purezza degli esecutori dell'Organizzazione B senza revisione del codice sorgente.

L'articolo nota esplicitamente che questo non è una prova meccanizzata nel senso di Rocq o Lean (riservata alla logica di governance sottostante nelle carte complementari), ma una garanzia strutturale verificata a runtime. Il contributo è la riduzione della superficie di fiducia da "tutto il codice dell'esecutore" a una piccola Base di Calcolo Fiduciaria esplicitamente definita.