Se hai già investito in un AI gateway o nei Guardrails di un hyperscaler, la prima cosa onesta da dire è: conservali, Olivares AI non intende sostituirli. Il compito di un gateway è la chiamata al modello — instradarla, memorizzarla nella cache, bilanciarla, pianificarne il budget. Il compito dei Guardrails è la sicurezza dei contenuti su quella chiamata. Entrambi sono reali, entrambi fanno bene il loro lavoro, e nessuno dei due è ciò che Olivares è.
TL;DR: Olivares AI non è un AI gateway generale: non fa caching né bilanciamento del traffico dei modelli e non rivendica alcuna matrice universale di provider, modelli o instradamento. Risolve politiche di instradamento in una catena ordinata di fallback e ha un solo percorso di esecuzione misurato — deny-closed, che attua solo tramite un client compatibile con Claude Messages configurato da te, direttamente o con il tuo endpoint di gateway come base URL di Messages. Oltre a quel percorso è il piano di governance e di evidenza: enforcement in-process nel runtime dell’agente, registro a prova di manomissione, ciclo di vita delle identità non umane e human-in-the-loop / break-glass / kill-switch sulle sessioni attive. Si compone con il gateway che già usi invece di sostituirlo.
Cosa fanno bene un gateway e i Guardrails (usali per questo)
Si tratta di capacità consolidate e ben comprese, e i produttori le descrivono con chiarezza:
- Gli AI gateway sono gestori nel percorso delle richieste per le chiamate ai modelli. LiteLLM è un “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user” (LiteLLM); Cloudflare AI Gateway consente di “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway” (Cloudflare); Portkey “records real-time API requests, including cost” (Portkey). Instradamento, fallback, cache, chiavi virtuali, budget per chiave, registrazione delle richieste — questa è la loro funzione.
- I Guardrails degli hyperscaler sono filtri di sicurezza dei contenuti. Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications” che “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — filtri di contenuto, argomenti negati, filtri lessicali, redazione PII, verifiche di grounding contestuale e ragionamento automatizzato (AWS).
Se il tuo problema è “dare alle mie applicazioni un unico endpoint verso molti modelli, con budget, cache e filtraggio dei contenuti,” quello stack lo risolve e non hai bisogno di un control plane per farlo. Noi ci integriamo con quel pattern; non lo reimplementiamo.
Che cosa documenta oggi ciascun prodotto
Letto il 2026-09-12 sulla pagina di ciascun fornitore. Sono limiti delle pagine lette, non affermazioni su un intero prodotto, e nessuno è una classifica.
| Prodotto | Superficie per agenti documentata | Che cosa la pagina non copre |
|---|---|---|
| LiteLLM | La documentazione del proxy contiene una sezione “Agent & MCP Gateway”, oltre a Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | La pagina letta documenta la superficie del proxy; l’enforcement dentro un runtime di agente che non lo attraversa mai resta fuori |
| Portkey | Il suo elenco prodotti include Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | La pagina letta è una panoramica di funzioni; non descrive una mappa di accesso consentito-contro-osservato su tutto il parco |
| Cloudflare AI Gateway | ”An intelligent control plane for your AI applications” — “Connect to any model, dynamically route requests, and manage usage, billing, and logs”, “fallback routing, rate limiting, and safety guardrails” (Cloudflare) | La pagina letta è una presentazione di prodotto; non descrive un esercizio self-hosted o air-gapped di quel piano |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, utilizzabili inline oppure “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | Sono pagine di sicurezza dei contenuti; il ciclo di vita dell’identità dell’agente, l’intervento in sessione e le approvazioni non ne sono l’oggetto e non vi sono documentati |
L’impostazione precedente era quindi sbagliata. «I gateway non vedono mai l’agente» non regge davanti alle pagine sopra: LiteLLM e Portkey documentano superfici per agenti e MCP, e Cloudflare chiama il proprio gateway un piano di controllo. Resta diverso dove avviene l’enforcement e che tipo di registro ne esce: un confronto architetturale, non un’affermazione di assenza.
Dove le architetture differiscono ancora
Condizionale, non universale — ogni riga vale quando vale la condizione a sinistra:
| Se i tuoi agenti… | Allora un prodotto sul percorso della richiesta | Allora Olivares AI |
|---|---|---|
| …raggiungono i modelli solo attraverso il proxy | governa ogni chiamata che vede, alla richiesta | aggiunge poco sul percorso della richiesta |
| …girano anche localmente e raggiungono direttamente database, object store, MCP o file | non può vedere chiamate che non lo attraversano | applica enforcement deny-closed in-process sull’agente, prima che il tool parta |
| …hanno bisogno di un registro verificabile da un auditor fuori dalla macchina | emettono log di richiesta, che sono record mutabili | registro append-only, concatenato per hash, firmato Ed25519, verificabile fuori dalla macchina |
| …devono essere fermati a metà sessione | non è il punto in cui si ferma una sessione attiva | approvazioni HITL, break-glass e un kill switch con riattivazione a controllo duale |
| …devono essere identificati per tutta la loro vita | una virtual key è un capitolo di budget | ciclo di vita delle identità non umane: blocco per obsolescenza, cascata di offboarding, rotazione a controllo duale |
| …devono restare dentro il tuo perimetro | i piani SaaS trattano quel traffico nel loro cloud | self-hosted o air-gapped; il piano dati non lascia il tuo perimetro |
Il percorso di esecuzione di Olivares e i suoi limiti reali
Olivares tocca l’inferenza, in un unico punto misurato, e la descrizione onesta è quella che porta la sua stessa misurazione attuale:
- La rotta
POST /routing-policies/{id}/executeè deny-closed by construction e attua solo tramite un client compatibile con Claude Messages, direttamente o con un endpoint di gateway risolto come base URL di Messages — quindi il tuo gateway attuale può essere quell’endpoint. - La risoluzione delle politiche produce una catena ordinata di fallback. Il modulo risolve sempre una rotta e agisce solo tramite una porta executor; l’executor di default non è cablato, quindi l’instradamento si risolve senza alcuna chiamata al provider finché un operatore non ne compone uno.
- Due gate di scope deny-closed e il gate di stop del kill-switch girano prima del gate di budget FinOps, che gira prima dell’executor.
E ciò che esplicitamente non stabilisce, con le parole dello stesso record:
- nessuna matrice universale di provider o modelli — il protocollo Claude Messages stabilisce una rotta configurata, non una matrice;
- nessuna custodia centralizzata delle chiavi — i campi chiave del provider sono riferimenti;
- nessuna esecuzione dalla console — la console risolve e testa le politiche e non ha una chiamata di esecuzione.
Questa è una misurazione delle sorgenti attuali, non un’accettazione di capacità: il record di claims vigente tiene questa e ogni altra capacità come implementata e non accettata, senza alcuna ricevuta di esecuzione alle spalle. Da leggere come la forma del percorso, non come una funzione certificata.
Sui Guardrails in particolare: la sicurezza dei contenuti è un hook, non un concorrente
Bedrock Guardrails può essere applicato in due modi — inline durante una
chiamata di inferenza su Bedrock, o “directly through the ApplyGuardrail
API without invoking the foundation models”, che funziona “with any
foundation model whether hosted on Amazon Bedrock or self-hosted models”
(AWS). Questo è genuinamente
utile, e Olivares tratta la sicurezza dei contenuti come un rilevatore che si
inserisce, mai come un muro che chiediamo di scegliere al posto dei
Guardrails. Due fatti onesti e distinti:
- Il proxy di inferenza inline espone una giuntura di ispezione dei contenuti — un punto collegabile dove un rilevatore di contenuti / DLP restituisce un verdetto su cui agisce il decisore deny-closed. La sicurezza dei contenuti appartiene lì, nella pipeline, anziché essere reimplementata come un filtro concorrente.
- Olivares legge le decisioni proprie dei tuoi Guardrails in modalità
read-first. Il connettore AWS acquisisce le decisioni dei guardrail di
Bedrock dai loro log CloudWatch / S3 come postura ed evidenza; deliberatamente
non invoca il runtime a pagamento
ApplyGuardraildirettamente. I tuoi verdetti sui contenuti diventano parte del registro a prova di manomissione.
Così la sicurezza dei contenuti si compone con ciò che già utilizzi. Ciò che i Guardrails non documentano — e dove la lacuna di governance resta aperta — è il resto della vita dell’agente: le pagine di Bedrock non documentano identità dell’agente, gestione delle sessioni, approvazioni umane né governance dei costi (non documentato in quelle pagine, verificato il 2026-09-12). Olivares è esattamente quel complemento: gestisce l’identità, i controlli di sessione, le approvazioni e l’evidenza; il filtro dei contenuti resta dove già risiede.
Come si compongono
Una configurazione sana mantiene ogni strumento nel suo ambito:
- Conserva il tuo gateway (LiteLLM / Portkey / Kong / Cloudflare) come il piano delle chiamate ai modelli — instradamento, cache, chiavi virtuali, budget sulla richiesta.
- Conserva i tuoi Guardrails (Bedrock / Azure Content Safety) come il tuo
rilevatore di sicurezza dei contenuti — il PEP di Olivares esegue un
rilevatore collegabile nella sua giuntura di ispezione dei contenuti e legge le
decisioni proprie dei tuoi Guardrails in modalità read-first come evidenza; non
invoca
ApplyGuardraildirettamente. - Aggiungi Olivares accanto a essi come piano di governance ed evidenza: il PEP in-process sugli agenti che non passano mai per il tuo gateway, la mappa di accesso su tutta l’infrastruttura, il registro a prova di manomissione e i controlli HITL/break-glass/kill in tempo reale.
L’unico punto in cui Olivares tocca l’inferenza è ristretto ed esplicito — un
percorso di gateway solo con API key per i chiamanti SDK diretti o curl,
descritto in
Governing subscription-authed agents.
Esiste per governare traffico che i tuoi altri strumenti non possono
raggiungere, mai per competere con essi sull’instradamento, e non trasporta
mai una credenziale di abbonamento.
Quando il tuo gateway è sufficiente
L’onestà funziona in entrambe le direzioni. Se i tuoi agenti chiamano modelli solo attraverso il tuo gateway, le tue esigenze di sicurezza dei contenuti sono coperte dai Guardrails, non hai agenti self-hosted né su laptop che accedono a database / object store / MCP direttamente, e non hai requisiti di sovranità né di evidenza a prova di manomissione — allora il tuo gateway con i suoi log e i Guardrails possono essere tutto ciò di cui hai bisogno, e non dovresti aggiungere un control plane per il solo gusto di averlo.
Olivares guadagna il suo posto quando le domande diventano trasversali all’infrastruttura e avversariali: quali agenti esistono e a cosa ha realmente acceduto ciascuno, posso fermare un’azione dannosa deny-closed nell’agente, chi ha autorizzato quella rischiosa, e posso consegnare a un auditor prove immutabili — il tutto senza inviare quell’immagine al cloud di qualcun altro. Per il trattamento approfondito di due comparazioni adiacenti, consulta vs AI control towers e vs LLM observability.