AEX: Non-Intrusive Multi-Hop Attestation and Provenance for LLM APIs

Il paper propone AEX, un'estensione di attestazione non intrusiva per le API dei LLM che, tramite un oggetto firmato, lega in modo verificabile le richieste client alle risposte o ai flussi di output, garantendo l'integrità della provenienza anche in scenari di trasformazione o streaming.

L'essenziale

Immagina di ordinare una pizza da un ristorante molto famoso tramite un'app. Tu invii l'ordine ("voglio una pizza margherita"), ma quando arriva, c'è un dubbio: è davvero la pizza che hai ordinato? O il cameriere l'ha scambiata? O forse qualcuno l'ha modificata per strada?

Nel mondo dell'Intelligenza Artificiale (LLM), succede qualcosa di simile. Le persone chiedono cose alle "macchine intelligenti" via internet, ma non hanno mai la certezza assoluta che la risposta ricevuta sia quella generata esattamente per la loro domanda, senza essere stata manomessa da intermediari o da server non autorizzati.

Ecco cosa propone questo documento, chiamato AEX, spiegato in modo semplice:

1. Il Problema: "La Pizza Sospetta"

Oggi, molte aziende usano l'Intelligenza Artificiale tramite "API" (sono come i canali di comunicazione digitali). C'è un problema: a volte, tra te e il cervello dell'AI, passano molti intermediari (come gateway, filtri di sicurezza, o persino servizi non ufficiali chiamati "Shadow APIs").
Questi intermediari potrebbero:

• Cambiare la tua domanda senza dirtelo.
• Modificare la risposta dell'AI.
• Far passare una risposta generata da un modello diverso da quello che dici di usare.

Fino ad ora, non c'era un modo semplice per dire: "Aspetta, questa risposta è stata firmata digitalmente dal creatore originale e corrisponde esattamente alla mia domanda".

2. La Soluzione: AEX (Il "Sigillo di Sicurezza" Digitale)

Gli autori propongono AEX, che è come un sigillo di sicurezza digitale che si attacca alla risposta dell'AI.

Immagina che ogni risposta dell'AI arrivi in una scatola di cartone. AEX non cambia il contenuto della scatola (la pizza o la risposta dell'AI), ma aggiunge un biglietto di garanzia firmato appiccicato sopra.

Questo biglietto dice tre cose fondamentali:

1. Chi l'ha fatto: "Io, il server ufficiale, ho firmato questa risposta."
2. Per chi l'ha fatta: "Ho risposto esattamente alla domanda che mi hai fatto tu (o a una versione modificata in modo sicuro e approvato)."
3. Cosa è successo lungo la strada: "Se qualcuno ha cambiato la domanda o la risposta in modo autorizzato (come un filtro di sicurezza), ce l'ha scritto qui, firmato da loro."

3. Come Funziona (Le Analogie)

A. La "Firma" sulla Domanda (Binding)

Quando chiedi qualcosa all'AI, AEX crea un'impronta digitale unica della tua domanda. Se qualcuno cambia anche solo una virgola nella tua domanda mentre viaggia su internet, la "firma" non corrisponderà più e il sistema dirà: "Attenzione! Qualcuno ha manomesso la richiesta!".

• Analogia: È come se scrivessi la tua ricetta su un foglio di carta speciale. Se qualcuno prova a strappare un pezzo o a cambiare un ingrediente, la carta si rompe e si vede subito.

B. La "Catena di Custodia" (Provenance)

A volte, la risposta passa attraverso più stazioni. Immagina che l'AI scriva la risposta, poi un filtro di sicurezza la controlli, e infine un gateway la invii a te.
AEX permette di creare una catena di firme.

• L'AI firma: "Ecco la risposta grezza".
• Il filtro firma: "Ho controllato che non ci siano insulti, ecco la versione pulita".
• Il gateway firma: "Ecco la versione finale che ti mando".
  Tu, alla fine, puoi vedere tutta la catena di firme e sapere che nessuno ha agito di nascosto. Se manca una firma o è falsa, l'allarme scatta.

C. Il "Flusso" (Streaming)

Spesso l'AI non ti dà la risposta tutta insieme, ma la scrive parola per parola (come un messaggio che appare a caratteri scorrevoli).
AEX è intelligente: può firmare ogni singola "parola" o "frase" mentre arriva.

• Scenario 1 (Flusso originale): Se l'AI ti manda la risposta parola per parola senza interruzioni, AEX ti dice: "Stai ricevendo esattamente quello che l'AI sta scrivendo in tempo reale".
• Scenario 2 (Flusso modificato): Se un intermediario prende la risposta, la riorganizza o la cambia, AEX smette di dire "è tutto in tempo reale" e ti mostra invece: "Ecco la storia completa di come questa risposta è stata trasformata da A a B". Non ti inganna facendoti credere che sia il flusso originale se non lo è.

4. Cosa NON fa AEX (I Limiti)

È importante capire cosa AEX non è:

• Non è un giudice di verità: Se l'AI dice che "la Terra è piatta", AEX ti garantisce solo che quella è la risposta che l'AI ha dato alla tua domanda. Non ti dice se la risposta è scientificamente corretta.
• Non è un controllo del cervello: Non ti dice quale modello esatto di AI è stato usato (potrebbe essere un modello "clone"), ma ti dice che la risposta è stata generata da chi ha firmato il messaggio.
• Non è magico: Se chi firma il messaggio è un truffatore, allora la firma non serve a nulla. Devi fidarti di chi ha il potere di firmare.

In Sintesi

AEX è come un sistema di tracciamento postale digitale per le conversazioni con l'Intelligenza Artificiale.
Prima, quando ricevevi una risposta, potevi solo sperare che fosse autentica. Con AEX, ricevi una prova matematica che collega la tua domanda alla risposta finale, tenendo traccia di chiunque l'abbia toccata lungo il percorso, garantendo che non ci siano stati "furto" o "manomissioni" nascoste.

È uno strumento per rendere l'uso dell'AI più trasparente e sicuro, specialmente quando si tratta di dati sensibili o decisioni importanti.

Sommario tecnico

1. Il Problema: La Fragilità del Confine API negli LLM

L'accesso ai Large Language Models (LLM) ospitati avviene prevalentemente tramite API remote. Tuttavia, il confine di queste API offre prove dirette limitate sul fatto che l'output restituito corrisponda effettivamente alla richiesta visibile al client.

• Evidenze recenti: Audit su "shadow API" (endpoint non ufficiali o intermediari) hanno rivelato che il 45,83% degli endpoint fallisce la verifica dell'impronta digitale (fingerprinting) e mostra deviazioni nell'utilità fino al 47,21% rispetto al comportamento dichiarato.
• Limiti delle soluzioni esistenti: Approcci come il fingerprinting, i test di uguaglianza del modello (MET), l'inferenza verificabile e l'attestazione TEE (Trusted Execution Environment) rispondono a domande diverse (es. "quale modello è in esecuzione?" o "l'ambiente è sicuro?") ma non forniscono una prova diretta e verificabile online del legame tra una specifica richiesta client e la risposta specifica ricevuta.
• La sfida: Come aggiungere una prova verificabile, non intrusiva e online a un'API JSON esistente che garantisca l'integrità della transazione (richiesta-risposta) e la provenienza dell'output, anche in presenza di middleware fidati che modificano richieste o risposte?

2. Metodologia: Il Protocollo AEX

AEX (Attestation EXtension) è un'estensione di protocollo progettata per essere non intrusiva. Non modifica la semantica del corpo della richiesta o della risposta JSON, ma aggiunge un oggetto di attestazione firmato a livello superiore (attestation).

Principi Fondamentali

• Rappresentazione: AEX opera su oggetti JSON semantici, non sui byte di trasporto grezzi. Utilizza lo JSON Canonicalization Scheme (JCS) per garantire una rappresentazione byte invariante (indipendente da spazi bianchi o ordine dei campi) prima della crittografia.
• Firma: Utilizza firme Ed25519 e hash SHA-256.
• Immutabilità del Payload: Il campo attestation viene rimosso prima di calcolare gli hash del contenuto commerciale, permettendo al payload di rimanere un oggetto JSON standard.

Meccanismi Chiave

1. Commitment delle Richieste:

   • Il client può scegliere la modalità di vincolo della richiesta (full, top_level_exclude, top_level_include).
   • La modalità top_level_include è cruciale: vincola anche l'assenza di certi campi, prevenendo l'iniezione silenziosa di campi da parte di middleware non autorizzati.
   • Supporto per richieste trasformate: Se un intermediario fidato modifica la richiesta (es. aggiunta di prompt di sistema), AEX genera un request-transform receipt firmato che collega il commitment originale a quello effettivo, creando una catena di fiducia.

2. Integrità dello Streaming:

   • AEX distingue due modalità di prova per lo streaming, che non possono essere mescolate:
     • Source-stream prefix mode: Per flussi non trasformati. Permette checkpoint parziali (prefissi verificati) e un attestato terminale che sigilla l'intera catena hash dei chunk.
     • Complete-output lineage mode: Per flussi trasformati (es. aggregati, re-incapsulati, o filtrati). Non offre prove di prefisso; invece, fornisce una catena di lineage che collega l'output completo originale (firmato dal provider sorgente) all'output finale consegnato al client tramite una serie di output-transform receipts.

3. Provenienza dell'Output (Lineage):

   • Utilizza un modello di receipt (ricevuta) firmato per tracciare le trasformazioni fidate dell'output (es. un gateway che converte uno stream in un oggetto JSON singolo, o che redige contenuti sensibili).
   • Ogni nodo nella catena di provenienza specifica esplicitamente la modalità di output (stream vs non_stream), prevenendo ambiguità nel calcolo degli hash.

3. Contributi Principali

Il paper presenta cinque contributi fondamentali:

1. Formulazione del problema: Identifica l'urgenza pratica di un'attestazione al confine API basata sulle evidenze delle shadow API.
2. Progettazione di AEX: Un'estensione non invasiva che include commitment per richieste, output completi, modalità di vincolo esplicite e metadati di provenienza consapevoli della modalità di output.
3. Nuovi meccanismi di protocollo:
   • Una catena hash a doppio ancoraggio per lo streaming.
   • Una catena esplicita di trasformazione della richiesta per intermediari fidati.
   • Un modello di ricevuta per l'output sorgente e la trasformazione dell'output.
4. Analisi di sicurezza e privacy: Posiziona AEX rispetto a firme di messaggi HTTP, framework di provenienza (in-toto, DSSE), attestazione TEE e audit degli LLM.
5. Prototipo e Validazione: Un'implementazione di riferimento in TypeScript con test di conformità automatizzati e micro-benchmark.

4. Risultati e Validazione

• Prototipo: È stato sviluppato un prototipo TypeScript che simula un ambiente con gateway, proxy fidati (che riscrivono richieste/risposte) e provider.
• Test di Conformità: Sono stati eseguiti 29 test unitari e 25 test di integrazione che coprono:
  • Vincoli di richiesta e modalità di binding.
  • Catene di trasformazione richiesta e output.
  • Verifica di checkpoint nello streaming e attestati terminali.
  • Stati di fallimento strutturati (es. tampered, truncated, request_mismatch).
• Benchmark: I micro-benchmark locali mostrano un overhead trascurabile.
  • In un caso non streaming, il tempo di verifica del gateway è di circa 0.5 ms.
  • In scenari di streaming con trasformazioni fidate, il tempo di verifica rimane sotto 1.5 ms.
  • L'overhead è dominato dai ritardi simulati nello streaming, non dalla crittografia.

5. Significato e Implicazioni

AEX non cerca di provare la "verità" fattuale di un'output o l'identità esatta del modello (compiti per fingerprinting o TEE), ma si concentra su un'affermazione più ristretta e realistica: "Un emittente fidato ha firmato il legame tra una specifica richiesta e una specifica risposta (o catena di output)."

• Deployabilità: Essendo non intrusivo, AEX può essere adottato incrementalemente su API esistenti (come quelle compatibili con OpenAI) senza modificare il codice del client o del modello.
• Gestione della Fiducia: Permette di distinguere chiaramente tra:
  • Manipolazioni non autorizzate (rilevate come tampering).
  • Modifiche fidate e documentate (tracciate tramite catene di receipt firmate).
• Sicurezza: Risolve il problema del "mutamento silenzioso" (silent mutation) da parte di middleware, fornendo un meccanismo per rendere esplicite le trasformazioni accettate.
• Limiti: AEX non sostituisce l'attestazione TEE né prova l'assenza di prompt nascosti o retrieval privati. La fiducia rimane fondata sulla corretta gestione delle chiavi pubbliche degli emittenti (issuer).

In conclusione, AEX offre un livello di attestazione transazionale pratico e interoperabile per l'ecosistema degli LLM, colmando il divario tra la necessità di integrità dei dati e la realtà delle architetture distribuite con middleware fidati.