💻 computer science

Evidence-Bound Gateway-Path Provenance for Third-Party LLM Inference

Questo articolo propone un'architettura di gateway per LLM vincolata alle evidenze che utilizza un piano di esecuzione attestato per verificare e firmare crittograficamente tutte le decisioni di instradamento, fallback e streaming, consentendo così ai client di rilevare e prevenire in modo indipendente violazioni delle policy, sostituzioni di instradamento e manipolazioni di stream da parte di operatori di gateway terzi.

Autori originali: Fei Wang, Zebai Tian

Pubblicato 2026-06-23

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Fei Wang, Zebai Tian

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.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

Il Problema: L'Intermediario "Scatola Nera"

Immagina di voler ordinare una torta personalizzata da una pasticceria, ma non vuoi trattare direttamente con il pasticciere. Quindi, assumi un servizio di consegna (il Gateway) per gestire l'ordine. Dici al servizio di consegna: "Per favore, prendi una torta al cioccolato dalla Pasticceria A."

Nel mondo attuale dell'IA, questo servizio di consegna è un "Third-Party LLM Gateway". Si trova tra te e le grandi aziende di IA (come OpenAI, Anthropic, ecc.).

Il Problema della Fiducia:
Il problema è che una volta che il tuo ordine lascia le tue mani, il servizio di consegna ha il controllo totale. Potrebbero:

Sostituire la pasticceria e ordinare da una più economica e di qualità inferiore senza avvisarti.
Cambiare la tua richiesta in "Torta alla vaniglia" prima di inviarla alla pasticceria.
Consegnare una torta comprata al supermercato sostenendo che sia stata fatta su misura.
Cambiare la fattura in seguito, dicendo che hai ordinato una torta a piani gigante quando ne hai ordinata solo una piccola.

Poiché il servizio di consegna scrive la ricevuta e controlla il camion, non hai modo di dimostrare che abbiano imbrogliato. Devi solo fidarti di loro.

La Soluzione: La "Cassaforte Sigillata e Testimoniata"

Questo articolo propone un nuovo modo per gestire questi servizi di consegna utilizzando una Cassaforte Sicura (chiamata Attested Gateway Runtime o AGR) e un sistema di Notaio.

Ecco come funziona il loro nuovo sistema, passo dopo passo:

1. La Cassaforte Sigillata (L'AGR)

Invece di far gestire l'ordine al servizio di consegna in un ufficio aperto, mettono l'elaborazione dell'ordine all'interno di una cassaforte di vetro ultra-tecnologica e indistruttibile (un Ambiente di Esecuzione Fidato, o TEE).

La Regola: Solo questa specifica cassaforte può aprire il tuo ordine sigillato, leggere ciò che hai scritto, decidere quale pasticceria utilizzare e parlare con la pasticceria.
L'Ostacolo: Il manager del servizio di consegna (il "Business Plane") può vedere il camion che si muove e i pacchi che vengono caricati, ma non può vedere dentro la cassaforte. Non può cambiare l'ordine o sbirciare la torta mentre viene preparata.

2. Il Controllo del Notaio (Remote Attestation)

Prima di inviare il tuo ordine, non ti limiti a fidarti che la cassaforte esista. Chiedi il sigillo di un Notaio (Remote Attestation).

La cassafolta ti mostra una carta d'identità digitale che prova: "Io sono la cassaforte corretta, non manomessa, e sto eseguendo l'esatta versione del software che hai approvato."
Se il servizio di consegna prova a sostituire la cassaforte con una falsa, il sigillo del Notaio non corrisponderà e tu non invierai il tuo ordine.

3. La "Catena di Prove" (La Ricevuta)

Una volta che la cassaforte ha elaborato la tua richiesta e ottenuto la torta (la risposta dell'IA), non te la consegna e basta. Crea una ricevuta digitale a prova di manomissione (Inference Evidence Chain).

Questa ricevuta è firmata dalla cassaforte stessa.
Prova che: "Io sono la cassaforta. Ho ricevuto la tua specifica richiesta. Mi è stato permesso di andare alla Pasticceria A. Ho ricevuto la risposta dalla Pifica A. Ti ho consegnato esattamente questo testo."
Se il servizio di consegna prova a sostituire la torta o a cambiare la ricevuta, la firma si rompe e la ricevuta diventa invalida. Saprai immediatamente che qualcosa non va.

Cosa Fa Realmente Questo Sistema (e Cosa Non Fa)

Cosa risolve:

Niente più sostituzioni nascoste: Sai esattamente quale modello di IA è stato utilizzato.
Niente più modifiche segrete: Il servizio di consegna non può cambiare segretamente il tuo prompt o la risposta.
Niente più fatture false: Il registro di ciò che è accaduto è firmato dalla cassaforta, non dal manager del servizio.
Sicurezza Integrata (Fail-Safe): Se la cassaforte viene manomessa o se la prova manca, il sistema smette di funzionare (fail-closed) invece di darti una risposta falsa.

Cosa NON risolve (I Limiti dell'Articolo):

Non ferma il Pasticcere: Se la pasticceria (il fornitore di IA) decide di darti una torta cattiva o una ricetta pericolosa, la cassaforte non può fermarla. La cassaforte prova solo che il percorso di consegna è stato onesto, non che il pasticcere sia onesto.
Non nasconde i tempi: Il servizio di consegna può comunque vedere quanto tempo il camion è rimasto sulla strada o quanto è grande il pacco, anche se non può vedere cosa c'è dentro.
Non ferma gli attacchi DoS: Se il servizio di consegna decide semplicemente di non guidare il tuo camion, può comunque farlo.

I Risultati della "Prova su Strada"

Gli autori hanno costruito un prototipo funzionante (un "prototipo in Rust") per testare questa idea.

Hanno testato il sistema con un fornitore di IA "mock" (finto) e uno reale (GPT).
Velocità: Era molto veloce. I passaggi di sicurezza aggiuntivi (controllare la cassaforte e firmare la ricevuta) hanno aggiunto solo una quantità minima di tempo (millisecondi), che è quasi impercettibile.
Sicurezza: Quando hanno cercato di "hackerare" il sistema sostituendo i modelli, nascondendo i fallback o cambiando la ricevuta, il sistema ha rilevato ogni singolo tentativo e lo ha rifiutato.

In Sintesi

Questo articolo introduce un modo per rendere i gateway di IA di terze parti onesti per progettazione. Invece di chiederti di fidarti dell'azienda che gestisce il gateway, costringe il gateway a provare, con la matematica crittografica, di aver seguito le regole esattamente.

Immaginalo come un contratto sigillato e notarile per ogni singola interazione con l'IA. Non devi fidarti dell'intermediario; devi solo fidarti della matematica e dell'hardware che firma la ricevuta.

Sintesi Tecnica: Provenienza del Percorso del Gateway Vincolata da Evidenze per l'Inferenza LLM di Terze Parti

1. Definizione del Problema

I gateway per i Large Language Model (LLM) di terze parti sono diventati infrastrutture critiche per le applicazioni che utilizzano molteplici fornitori di LLM esterni. Questi sistemi gestiscono il routing, la selezione del modello, i meccanismi di fallback, lo streaming e la fatturazione. Tuttavia, esiste un fondamentale confine di fiducia: l'operatore del gateway controlla sia la mediazione del percorso di inferenza sia l'autorialità dei record che descrivono tale percorso.

Nelle implementazioni convenzionali, sebbene il protocollo Transport Layer Security (TLS) protegga i salti di rete, il gateway termina le richieste del client in chiaro. Ciò consente al gateway di:

Leggere i prompt e riscrivere le richieste verso l'upstream.
Sostituire endpoint o modelli senza la conoscenza del client.
Alterare le risposte in streaming o iniettare contenuti.
Falsificare i record di utilizzo, fatturazione o provenienza.

I client che ricevono solo una risposta e un log redatto dal gateway non possono distinguere tra una mediazione onesta e una sostituzione occulta del modello, un fallback non dichiarato, una riscrittura dell'endpoint o una manipolazione dello stream. Questo rischio è amplificato nei sistemi agentici, dove il testo restituito può innescare chiamate a strumenti (tool calls) o modifiche al codice. Il problema centrale non è semplicemente chi può leggere il prompt, ma chi può redigere il record del percorso del gateway.

2. Metodologia: Architettura Vincolata da Evidenze

Il documento propone un'architettura di Gateway Vincolato da Evidenze (Evidence-Bound Gateway) che separa il piano di business controllato dall'operatore da un piano di esecuzione attestato remotamente. Il componente principale è l'Attested Gateway Runtime (AGR), che opera all'interno di un Ambiente di Esecuzione Fidato (TEE - Trusted Execution Environment).

Componenti Architetturali Chiave

Piano di Business (Business Plane): Gestisce l'autenticazione del client, l'applicazione delle quote, l'inoltro del traffico e il logging. Inoltra richieste cifrate opache ma non può decifrare le richieste o accedere alle chiavi dello stream.
Attested Gateway Runtime (AGR): Il piano di esecuzione critico per la sicurezza che gira all'interno di un TEE (ad esempio, AWS Nitro Enclaves). È l'unico componente autorizzato a:
- Decifrare le richieste del client.
- Applicare le policy di routing e di fallback specifiche per ogni richiesta.
- Costruire le chiamate verso i fornitori di LLM.
- Cifrare gli stream di risposta.
- Firmare le Catene di Evidenza di Inferenza (IEC - Inference Evidence Chains).

Flusso del Protocollo

Registri e Attestazione: Un'autorità di rilascio firma un registro di misurazioni (measurements) e policy approvate. I client verificano questo registro e richiedono un'attestazione fresca dall'AGR. L'AGR fornisce una "quote" hardware che vincola la sua misurazione, l'hash della policy e le chiavi di cifratura/firma delle evidenze.
Contratti che Portano la Policy (Policy-Carrying Contracts): I client inviano richieste cifrate contenenti un Contratto di Inferenza (IC - Inference Contract) che restringe la policy globale per una specifica richiesta (ad esempio, modelli consentiti, archi di fallback). L'AGR calcola la policy effettiva ( $P_{eff} = P \cap IC$ ).
Esecuzione Sicura: L'AGR decifra la richiesta, valida la policy, seleziona la rotta/endpoint, chiama il fornitore upstream. Cifra lo stream di risposta e mantiene un impegno (commitment) rotante sui chunk cifrati.
Generazione di Evidenze: L'AGR firma una Catena di Evidenza di Inferenza (IEC). Questo oggetto vincola:
- L'attestazione del runtime e l'identità.
- L'hash della policy e del contratto.
- Le decisioni di routing e di fallback.
- L'identità dell'endpoint osservato (verifica TLS).
- I commitment delle trascrizioni dello stream cifrate (StreamEv).
- I metadati di completamento.
Verifica: Il client verifica l'IEC rispetto all'identità del runtime attestato e ricalcola il commitment dello stream per garantire che il ciphertext ricevuto corrisponda all'evidenza firmata.

3. Contributi Principali

Il documento presenta quattro contributi primari:

Identificazione del Problema: Identifica il problema del confine di fiducia multi-autorità nei gateway LLM di terze parti, dove il routing, il fallback, l'ammissione dell'endpoint e l'autorialità delle evidenze sono concentrati in un unico servizio controllato dall'operatore.
Architettura: Presenta un'architettura a piani separati che sposta la decifrazione, l'applicazione della policy, la costruzione dell'upstream e la firma delle evidenze in un runtime attestato (AGR), preservando al contempo le funzioni del piano di business.
Meccanismi: Introduce i contratti di inferenza che portano la policy e le catene di evidenza di inferenza che legano l'attestazione del runtime, la policy specifica per richiesta, le decisioni di rotta e le trascrizioni degli stream cifrati in una provenienza verificabile.
Implementazione e Valutazione: Implementa un prototipo in Rust su AWS Nitro Enclaves e valuta gli overhead dei meccanismi, l'applicazione del routing e i comportamenti di "fail-closed".

4. Risultati Sperimentali

Gli autori hanno valutato il sistema utilizzando un prototipo in Rust con mock provider locali ed endpoint GPT reali.

Overhead: In un ambiente mock deterministico locale (concorrenza 16), il gateway vincolato da evidenze (B2) ha mostrato una latenza p95 di 38,72 ms.
Performance Nitro Enclave: Quando il runtime è stato posizionato in un Nitro Enclave (B3), la latenza p95 è aumentata leggermente a 46,2 ms (circa 1,1x rispetto al runtime locale), con il throughput che manteneva il 95% della baseline locale. L'overhead è stato dominato dal trasporto, non dalle operazioni crittografiche.
Costi delle Evidenze: Per una trascrizione di 100 chunk, la costruzione e il ricalcolo di StreamEv sono costati rispettivamente circa 130 µs e 120 µs (p95). La firma e la verifica dell'IEC sono avvenute nell'ordine dei decimi di microsecondo.
Validazione Fail-Closed: Il sistema ha respinto con successo i tentativi di manomissione in tutti gli scenari di controllo negativo, inclusi:
- Manomissione di attestazione/registro (PCR, nonce, modifica del registro).
- Violazioni dell'integrità del canale (manomissione di chiavi/ciphertext).
- Sostituzione di rotta e fallback (scambio di modelli, omissione di fallback).
- Violazioni dei vincoli dell'endpoint.
- Riscrittura dei metadati dell'evidenza e manipolazione della trascrizione dello stream (cancellazione, riordinamento, replay).
- Avvelenamento del gateway (le chiamate a tool iniettate sono state respinte).

5. Significato e Dichiarazioni

Il documento afferma che questa architettura stabilisce l'autenticità della provenienza del percorso del gateway. Permette ai client di verificare che:

La richiesta sia stata mediata da un runtime specifico e misurato.
Il routing, il fallback e la selezione dell'endpoint siano stati conformi alla policy firmata.
La trascrizione dello stream cifrata consegnata corrisponda al commitment firmato.
L'evidenza non sia stata falsificata o trasferita da un contesto di richiesta differente.

Ambito e Limitazioni:
Gli autori dichiarano esplicitamente ciò che il sistema non dichiara di fare:

Non nasconde i metadati del traffico (tempi, dimensione dei pacchetti, frequenza).
Non previene il Denial of Service (DoS).
Non prova che il fornitore LLM a monte abbia eseguito il modello corretto o generato contenuti sicuri (il fornitore rimane fuori dal TCB - Trusted Computing Base).
Non protegge contro fornitori LLM malevoli, contesti RAG avvelenati o violazioni di policy a livello di agente.
Si basa sull'affidabilità della piattaforma TEE, della radice di attestazione e del processo di firma del rilascio.

La significatività risiede nello spostamento del modello di fiducia: i client non devono più fidarsi dell'operatore del gateway per quanto riguarda sia la mediazione del percorso che la redazione dei record. Al contrario, si affidano a evidenze crittografiche legate a un runtime misurato, garantendo che routing non autorizzati, fallback nascosti, manipolazioni dello stream e record di fatturazione falsificati vengano rilevati e rifiutati.