Perplexity illustra il funzionamento dei gateway LLM e i rischi in produzione

Perplexity ha pubblicato il 27 ottobre 2026 una guida pratica ai gateway LLM, che illustra ai team di ingegneria come il livello intermediario instrada, autentica, memorizza nella cache e registra le chiamate ai modelli, e passa in rassegna i rischi per la sicurezza e l’affidabilità derivanti dalla concentrazione delle credenziali dei provider in un unico servizio.

Definizione e tassonomia dei gateway

La guida definisce un gateway LLM come un proxy inverso per le chiamate ai modelli: le applicazioni inviano le richieste al gateway anziché direttamente a provider come OpenAI, Anthropic o Google, e il gateway le inoltra applicando le regole stabilite dall’operatore. Presenta questa categoria come una risposta alla frammentazione e apre con un post del settembre 2026 su r/LLMDevs di Reddit, in cui un ingegnere descriveva un ambiente di lavoro nel quale ognuno aveva le proprie chiavi per Claude, OpenAI, AWS Bedrock e altri provider di inferenza.

La tabella comparativa della guida distingue quattro tipi di gateway. Un gateway API si colloca davanti ai servizi di backend e verifica se un client è autenticato e rispetta i limiti di frequenza. Un gateway LLM si colloca davanti ai provider di modelli e decide quale modello riceve una richiesta, chi la paga e se la risposta è stata restituita. Un gateway MCP stabilisce se un agente può utilizzare un determinato strumento con determinati argomenti. La guida usa l’espressione «gateway IA» per indicare i prodotti dei fornitori che riuniscono alcune combinazioni di questi ruoli.

Il ciclo di vita della richiesta in sei fasi

La guida spiega il funzionamento seguendo una richiesta dall’applicazione al modello e ritorno. Per prima cosa, l’applicazione invia al gateway una richiesta di chat, spesso in un formato compatibile con OpenAI. Il gateway convalida le credenziali, spesso una chiave virtuale assegnata a un team o a un prodotto, e, se sono stati configurati controlli di sicurezza sull’input, può esaminare i prompt alla ricerca di dati sensibili o di tentativi di aggirare le istruzioni del modello. Se la memorizzazione nella cache è attiva, una richiesta idonea che corrisponde a una richiesta precedente può ricevere una risposta salvata; alcuni gateway offrono anche una cache semantica, che abbina richieste considerate simili, anziché identiche. Il gateway cerca quindi nella propria configurazione la route corrispondente e può ricorrere a un provider di riserva se il primo non risponde entro i tempi previsti. Converte la richiesta nel formato del provider scelto, autentica la chiamata in uscita e riconverte la risposta per l’applicazione. Se la registrazione è attiva, registra chi ha effettuato la chiamata, quale modello ha risposto, il numero di token, la latenza e il costo.

Rischi per la sicurezza e l’affidabilità

L’avvertimento centrale della guida è che il gateway concentra le credenziali. Il team di sicurezza di Microsoft ha elencato i dati che un’installazione di LiteLLM può contenere o recuperare: chiavi API dei provider, chiave master di LiteLLM, record delle chiavi virtuali, stringhe di connessione ai database, configurazione di routing e dati sulle policy dei tenant. Nel post del 26 agosto 2026, Microsoft ha descritto una compromissione osservata di un gateway LiteLLM, in cui gli aggressori hanno sottratto credenziali dall’ambiente di esecuzione del gateway.

Il 13 ottobre 2026, Check Point Research ha divulgato due vulnerabilità ad alto rischio in LiteLLM: CVE-2026-35029, una falla nel controllo degli accessi che consentiva agli utenti autenticati, compresi quelli con soli permessi di lettura, di accedere alle funzioni amministrative e prendere il controllo del gateway; e CVE-2026-59823, una vulnerabilità di tipo server-side request forgery che consentiva agli utenti di reindirizzare le richieste del gateway a un server controllato da un aggressore e acquisire le chiavi API dei provider di IA. Entrambe sono state corrette nella versione 1.83.9 di LiteLLM. Check Point ha riferito che LiteLLM registrava 97 milioni di download al mese e oltre 59.000 stelle su GitHub, e ha dichiarato di aver avviato la divulgazione coordinata con LiteLLM nell’ottobre 2025.

La guida invita inoltre i team a definire una politica di gestione dei guasti per i controlli di sicurezza. Descrive gli hook come punti del percorso della richiesta in cui il gateway passa i contenuti a uno scanner esterno per ottenerne una valutazione; osserva che la documentazione di Portkey indica before_request_hooks e after_request_hooks e che TrueFoundry esegue quattro hook, aggiungendo controlli prima e dopo le chiamate agli strumenti MCP.

Per quanto riguarda l’affidabilità, la guida cita interruzioni del servizio documentate. Nel resoconto di Cloudflare sull’interruzione del 12 giugno 2025 si afferma che il tasso di errore di AI Gateway ha raggiunto un picco pari al 97% delle richieste, perché AI Gateway dipende da Workers KV per le configurazioni dei client e quelle interne; l’interruzione complessiva è durata 2 ore e 28 minuti. Il rapporto post mortem di OpenRouter sulle interruzioni del 17 e 19 febbraio 2026 riferisce che gli incidenti sono durati rispettivamente 38 e 35 minuti, dopo il malfunzionamento di una dipendenza di caching di terze parti, hanno generato errori 401 «Utente non trovato» e hanno portato a interventi correttivi, tra cui l’introduzione di interruttori automatici e la restituzione di errori 503 anziché 401 quando problemi infrastrutturali impediscono le verifiche di autorizzazione.

Opzioni di implementazione, prezzi e dettagli dei fornitori

La guida illustra quattro modalità di implementazione. I team possono sviluppare internamente un gateway essenziale — che accetti le richieste, controlli la chiave del chiamante, aggiunga le credenziali del provider, inoltri la chiamata e registri il risultato — oppure ospitare autonomamente un gateway open source, con LiteLLM, Bifrost e Helicone tra le opzioni indicate. Tra i gateway gestiti figurano Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter e il gateway ospitato di Portkey. Una quarta possibilità consiste nell’estendere un gateway API già utilizzato dall’azienda; tra gli esempi citati ci sono Kong AI Gateway, le policy per gateway IA di Apigee e il gateway IA di Azure API Management.

Per quanto riguarda i costi, la guida afferma che i gateway LLM spaziano dal software open source gratuito ai piani a pagamento, a partire da circa 50 dollari al mese, con prezzi personalizzati per le aziende, e che alcuni applicano invece una percentuale: il piano Standard di OpenRouter, osserva, aggiunge il 5,5% agli acquisti di crediti.

La guida si conclude con risposte specifiche sui vari fornitori. Spiega che Amazon Bedrock AgentCore Gateway supporta le chiamate ai modelli tramite quelli che AWS definisce «target di inferenza», consentendo alle applicazioni di raggiungere fornitori come Amazon Bedrock, OpenAI e Anthropic da un unico endpoint. Aggiunge che l’Agent API di Perplexity supporta l’interfaccia Responses API di OpenAI, così i team possono riutilizzare le librerie client di OpenAI già in uso, e che l’Agent API consente agli utenti di elencare fino a cinque modelli, anche di fornitori diversi, nell’ordine che preferiscono. La guida menziona inoltre Numbat, il progetto open source di Perplexity, che si collega agli agenti supportati tramite hook locali e può esaminare le azioni pianificate, come i comandi shell o la scrittura di file, prima che vengano eseguite; il blocco è facoltativo ed è disattivato per impostazione predefinita.