Sicurezza degli LLM: quando ridurre i costi significa aumentare la superficie d’attacco

Tutti i processi stanno adottando modelli basati sull’intelligenza artificiale per incrementare la produttività e potenziare i risultati.

Chi porta in produzione un sistema basato su Large Language Model (LLM) si scontra presto con il costo elevato dei modelli di frontiera: far girare GPT-4 o un modello di pari livello su grandi volumi di richieste diventa rapidamente insostenibile.

La letteratura ha risposto a questo problema con una soluzione ormai diventata uno standard de facto: un’architettura multi-modello disaccoppiata che consente di ottenere risparmi fino al 98% a parità di accuratezza.

Ciascun layer introdotto per risparmiare aumenta anche la superficie d’attacco, più a livello di progettazione che a causa di difetti di implementazione.

Ecco le cinque classi di minacce e una checklist di contromisure per ogni
layer.

La tensione fra efficienza e sicurezza

Le cinque classi di minacce sono:

• la key collision nel semantic caching (CacheAttack),
• il leak e il timing side-channel della KV-cache,
• l’indirect prompt injection nel RAG,
• il tool poisoning e i rischi di supply-chain in MCP,
• e la manipolazione del control plane in router e cascade (forced downgrade, denial-of-wallet, backdoor tramite preference data).

Dall’analisi emerge una tensione strutturale tra efficienza e sicurezza: il conflitto tra locality e collision-resistance è irriducibile, e i controlli compensativi devono essere previsti già in fase di progettazione.

L’ottimizzazione dei costi dei LLM: le superfici d’attacco

Il problema dell’ottimizzazione dei costi dei Large Language Model di frontiera ha portato a un’architettura ormai standard. Un sistema multi-modello disaccoppiato, solitamente suddiviso in cinque layer.

All’ingresso, un gateway (o abstraction layer) disaccoppia l’applicazione dai modelli, evitando che resti vincolata a un singolo fornitore.

Un router o una LLM cascade smista ogni richiesta al modello più economico che sia ancora adeguato e passa al livello successivo solo quando la risposta non lo è più.

Un layer di RAG (retrieval-augmented generation) recupera i pochi documenti pertinenti, evitando di saturare il context window.

Un caching su più livelli evita invece di ricalcolare risposte già prodotte.

Alla base, come soluzione di ripiego o come exit strategy per evitare il lock-in dal vendor, ci sono i modelli open-weight self-hosted.

Le ottimizzazioni

I risparmi documentati sono consistenti:

• FrugalGPT dichiara di poter ridurre i costi fino al 98%, mantenendo la stessa accuratezza;
• RouteLLM taglia l’85% della spesa, garantendo il 95% della qualità di GPT-4; GPTCache rende le risposte fino a dieci volte più veloci in caso di hit della cache.

C’è però un aspetto che la narrazione sull’efficienza tende a ignorare: ogni strato aumenta la superficie d’attacco a livello di progettazione, dove nessuna patch può intervenire.

È quindi opportuno esaminare l’architettura dei componenti dal punto di vista della sicurezza.

Ottimizzazione LLM e superfici d’attacco di ogni componente

Nella tabella seguente è possibile visualizzare le caratteristiche di ottimizzazione e la superficie d’attacco di ciascun componente.

MCP e gateway: la supply chain dei tool

Lo strato più esterno, il gateway che neutralizza il lock-in insieme all’ecosistema di tool esposti tramite il Model Context Protocol (MCP), rappresenta anche il fronte della supply chain più recente e meno sorvegliato.

L’attacco tipico a questo layer è il tool poisoning: istruzioni malevole annidate nei metadati dei tool, che il modello legge per orchestrarne l’uso e di cui si fida in modo implicito.

Un’analisi lo classifica come la vulnerabilità client-side più diffusa e impattante dell’ecosistema.

Uno studio cross-entity (Li & Gao, 2026) ha esaminato oltre 67.000 server MCP su sei registry pubblici, rilevando la presenza diffusa di server hijacking e invocation manipulation, riconducibili allo scarso vetting dei registry stessi.

I framework di governance attuali, dal NIST AI RMF alla ISO/IEC 42001, non coprono ancora questi vettori nel dettaglio.

Router e LLM cascade: manipolare la scelta del modello

Il router, insieme alla variante a cascata, favorisce il modello più potente solo quando la risposta del modello economico non è soddisfacente e, di conseguenza,mdecide quale modello è più adeguato.

Questa scelta costituisce un piano di controllo a sé stante, e attaccarla è cosa diversa dal degradare l’output di un singolo modello.

Il paper “Rerouting LLM Routers” mostra che un utente malevolo può alterare l’LLM selezionato senza alterare la risposta o addirittura migliorandola.

Due direzioni per la manipolazione

La manipolazione avviene in due direzioni.

Verso il basso, forzare l’instradamento al modello debole porta la query sul percorso meno protetto, dove i guardrail sono più fragili e il jailbreak più facile.

Verso l’alto, l’escalation forzata al modello costoso lascia intatta la risposta e sposta il costo sul provider: si tratta di un denial-of-wallet, dimostrato in black-box dall’attacco Route to Rome tramite l’ottimizzazione di suffissi adversarial, e, nella versione a cascata, dal Forced Deferral Attack, che abbassa deliberatamente la confidence del modello debole per costringere il sistema a rimandare la risposta.

La lacuna

Il punto debole comune del layer è il segnale che governa l’allocazione. Nelle cascate, la confidence o la self-verification del modello economico stabilisce se accettare la risposta o passare al livello successivo; manometterla altera l’intera logica, sia forzando escalation inutili sia facendo accettare risposte economiche errate.

Il vettore pre deployment

Esiste inoltre un vettore che precede il deployment: i router addestrati su preferenze umane, come quelli di RouteLLM che imparano dalle valutazioni del Chatbot Arena, ereditano la manipolabilità di tali dati.

Lo studio “Life-Cycle Routing Vulnerabilities of LLM Router” documenta come un avversario possa iniettare una backdoor inviando valutazioni malevole, e come la soggettività dei giudizi renda difficile individuare l’avvelenamento.

RAG: il Retrieval abbatte il confine tra dati e istruzioni

Il RAG è stato inserito per contenere i costi e per evitare il degrado dei contesti lunghi, il fenomeno lost in the middle documentato da Liu et al., per cui il modello “perde” l’informazione collocata a metà del context.

Recupera solo i chunk pertinenti e li passa al modello. Tuttavia, questi chunk provengono da fonti esterne e potenzialmente ostili e vengono inseriti nel prompt.

Si tratta dello scenario descritto nel principale paper sull’indirect prompt injection.

L’indirect prompt injection

In “Not what you’ve signed up for”, si dimostra che le applicazioni LLM-integrated sfumano il confine tra dati e istruzioni: il modello, infatti, non riesce a distinguere in modo affidabile il “contenuto da elaborare” dal “comando da eseguire”.

Inserendo un payload in un contenuto destinato a essere recuperato, come una pagina web o un documento indicizzato, l’attaccante può ottenere l’esecuzione da remoto senza dover toccare direttamente il sistema, come dimostrato su applicazioni reali.

In un’architettura che prevede l’uso di un RAG, il rischio principale è rappresentato dal retrieval, in quanto è il canale attraverso il quale il contenuto non attendibile entra nel prompt.

Le contromisure, come lo spotlighting, il sandboxing e la separazione esplicita tra istruzioni e dati recuperati, devono essere previste già in fase di progettazione, quando il RAG viene introdotto.

Semantic caching: la locality è il contrario della collision-resistance

Il layer di caching serve a ridurre il numero di query al modello. Il semantic caching conserva le coppie query-risposta e, quando arriva una domanda semanticamente vicina a una già vista, restituisce la risposta salvata senza interrogare l’LLM.

La chiave di indicizzazione è, di fatto, un fuzzy hash costruito sull’embedding della query, e il problema nasce proprio da lì. Un hash crittografico robusto punta all’avalanche effect per rendere le collisioni computazionalmente difficili.

La chiave di un semantic cache fa l’opposto, e deve farlo: la sua locality, ovvero il mappare input vicini su chiavi vicine, è ciò che massimizza l’hit rate e, di conseguenza, il risparmio.

Tuttavia, “input diversi che collassano sulla stessa chiave” è la definizione operativa di collisione.

La stessa proprietà che genera il risparmio apre la vulnerabilità e il meccanismo è strutturato in questo modo. In “From Similarity to Vulnerability”, Zhang et al. formalizzano questo trade-off e concludono che il semantic caching è vulnerabile a livello di progetto.

CacheAttack

L’attacco automatizzato black-box degli autori, CacheAttack, raggiunge un hit rate dell’86% nell’hijacking delle risposte e riesce a indurre comportamenti malevoli nei sistemi agentici, mostrando una buona trasferibilità tra diversi modelli di embedding.

È stato validato su servizi in produzione, nello specifico AWS Bedrock e Azure API Management.

Uno studio indipendente, intitolato “When Cache Poisoning Meets LLM Systems”, giunge alle stesse conclusioni attraverso il cache poisoning e osserva che le difese anti-adversarial-prompting esistenti non sono in grado di intercettarlo.

L’attacco è più complesso di un semplice overwrite. Spesso l’attaccante non inietta una risposta falsa, ma forza una collisione di chiave in modo che alla query della vittima venga servita una risposta legittima destinata a tutt’altra richiesta.

L’output è autentico e il sistema non registra alcuna anomalia, pertanto non viene attivato alcun controllo. In un chatbot informativo, ciò si traduce in un degrado della qualità; in un workflow agentico che esegue azioni non reversibili, come un pagamento o l’invio di un messaggio, ciò compromette l’integrità con un impatto operativo diretto.

Ne consegue dunque una regola pratica: la cache condivisa deve essere considerata come una memoria non affidabile.

Prompt caching: la KV-cache come canale di leak

Anche il layer di prompt caching alleggerisce la pipeline delle query al modello.

Il prompt caching lato provider riutilizza l’elaborazione già svolta sui prefissi ricorrenti, come i system prompt e gli esempi, conservando la KV-cache e riutilizzandola.

Agisce all’interno dell’infrastruttura del modello, il che lo rende apparentemente innocuo, ma non lo è.

Lo studio “Unveiling and Mitigating Privacy Risks of KV-cache in LLM Inference” espone tre vettori distinti, inversion, collision e injection, che permettono di ricostruire l’input sensibile a partire dalla KV-cache.

Quando la cache è condivisa tra gli utenti, il timing sul riuso dei prefissi diventa un side-channel: misurando la latenza è possibile capire se un dato prefisso è già stato elaborato e, di conseguenza, cosa hanno sottoposto gli altri utenti.

Non a caso, gli autori propongono una contromisura dedicata: KV-Cloak, un sistema di offuscamento reversibile della cache basato su matrici.

Efficienza e sicurezza: un trade-off da valutare attentamente

In sintesi, il filo conduttore di tutti questi casi è che la vulnerabilità del semantic caching alle collisioni, come le altre viste in precedenza, non può essere risolta con una patch.

Il conflitto tra locality, che serve a risparmiare, e collision-resistance, che serve a difendersi, è dunque irriducibile, in quanto si tratta di due aspetti della stessa scelta progettuale.

Ciò non toglie nulla al valore dell’efficienza, ma impone di considerare ogni punto di costo risparmiato insieme alla superficie d’attacco che introduce e di prevedere i controlli compensativi fin dall’inizio.

Costruire un’architettura LLM economica è alla portata di tutti, ma costruirne una che sia economica e sicura richiede di considerare l’efficienza per quello che è: una scelta di rischio.

LLM e superfici d’attacco, le contromisure per layer

Ecco un elenco di contromisure volte a mitigare le vulnerabilità introdotte:

• MCP / gateway / tool;
• Routing / orchestrazione;
• RAG;
• Semantic caching;
• Prompt caching / KV-cache;
• Trasversale.

MCP / gateway / tool

• Vetting dei server MCP, firma e verifica dei manifest, allow-list esplicita dei tool ammessi.
• Minimo privilegio per ogni tool; nessuna capacità concessa senza una ragione precisa.
• Audit trail delle invocazioni tool e revisione periodica dei metadata (contro il tool poisoning).

Routing / orchestrazione

• Trattare confidence e logiche di routing come componenti security-critical, con integrità verificata.
• Validare che né il downgrade al modello debole né l’escalation forzata siano inducibili da input adversarial; prevedere rate-limiting e budget per query contro il denial-of-wallet.
• Non addestrare i router su preference data pubblici non verificati; sanitizzare e monitorare le fonti di rating, contro il backdoor in fase di training.

RAG

• Spotlighting e delimitazione esplicita del contenuto recuperato rispetto alle istruzioni di sistema.
• Sandboxing dei tool azionabili dal contenuto recuperato; principio del minimo privilegio sulle azioni derivabili dal retrieval.
• Sanitizzazione e provenance-tagging dei documenti indicizzati; trattare l’intera knowledge base come input non fidato.

Semantic caching

• Trattare la cache condivisa come memoria non fidata: nessun deployment multi-utente senza controlli di integrità.
• Isolamento per-tenant delle entry; mai condividere la cache tra confini di fiducia diversi.
• Soglie di similarità conservative e validazione dell’output servito rispetto alla query originale.
• Monitoraggio delle anomalie di hit rate e alerting su pattern compatibili con key-collision probing.
• Nei workflow agentici, escludere dalla cache le risposte che innescano azioni non reversibili.

Prompt caching / KV-cache

• Evitare la KV-cache condivisa tra utenti quando i prompt contengono dati sensibili.
• Considerare l’offuscamento reversibile della KV-cache (approccio KV-Cloak) dove il provider lo consenta.
• Trattare la latenza differenziale come canale: normalizzare o mascherare i tempi di risposta sui path cache-hit se il timing è osservabile dall’esterno.

Trasversale

• Osservabilità end-to-end: logging della provenienza di ogni risposta e correlazione query–chiave di cache.
• Threat modeling dell’architettura di ottimizzazione già in fase di design.

Riferimenti

• Chen, L., Zaharia, M., Zou, J. (2023). FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv:2305.05176
• Ong, I., et al. (2025). RouteLLM: Learning to Route LLMs with Preference Data. ICLR 2025. arXiv:2406.18665
• Bang, F. (2023). GPTCache: An Open-Source Semantic Cache for LLM Applications. EMNLP NLP-OSS 2023
• Liu, N. F., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. TACL, vol. 12.
• Zhang, Z., et al. (2026). From Similarity to Vulnerability: Key Collision Attack on LLM Semantic Caching (CacheAttack). arXiv:2601.23088
• Wu, Wang, Zhang, Zhang, Niu, Wu, Zhang (2026). When Cache Poisoning Meets LLM Systems: Semantic Cache Poisoning and Its Countermeasures. NDSS Symposium 2026.
• Luo, Shao, Zhang, Zhou, Hu, Zhao, Liu, Qin (2026). Shadow in the Cache: Unveiling and Mitigating Privacy Risks of KV-cache in LLM Inference (KV-Cloak). arXiv:2508.09442
• Greshake, K., et al. (2023). Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. AISec @ ACM CCS 2023. arXiv:2302.12173
• Li, X., Gao, X. (2026). A First Look at the Security Issues in the Model Context Protocol Ecosystem. DSN 2026. arXiv:2510.16558
• Huang, Huang, Tran, Milani Fard (2026). Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning. arXiv:2603.22489
• Shafran, Schuster, Ristenpart, Shmatikov (2025). Rerouting LLM Routers. arXiv:2501.01818
• Lin, Ji, Zhai, Shen, Zhang, Fang, Gao (2025). Life-Cycle Routing Vulnerabilities of LLM Router (2025). arXiv:2503.08704
• Tang, Yan, Lu, Liu, Dai (2026). Route to Rome (R2A): Directing LLM Routers to Expensive Models via Adversarial Suffix Optimization. arXiv:2604.15022
• Liu, Z., Zeng, Y., Chang, Y., Lin, L. (2026). Forced Deferral: Manipulating Routing Decisions in Multimodal LLM Cascades. arXiv:2606.15308