Si vous avez deja investi dans un AI gateway ou dans les Guardrails d’un hyperscaler, la premiere chose honnete a dire est : conservez-les, Olivares AI ne cherche pas a les remplacer. Le role d’un gateway est l’appel au modele — le router, le mettre en cache, l’equilibrer, le budgetiser. Le role des Guardrails est la securite du contenu sur cet appel. Les deux sont reels, les deux font bien leur travail, et aucun des deux n’est ce qu’est Olivares.
TL;DR: Olivares AI n’est pas un AI gateway. Il ne route pas, ne met pas en cache, n’equilibre pas la charge et ne se situe pas sur le chemin critique de votre trafic de modeles, et ne le fera jamais. Il se situe a cote et derriere votre gateway en tant que plan de gouvernance et de preuve : enforcement en processus au sein du runtime de l’agent, un registre de preuves inviolable, cycle de vie des identites non humaines, et human-in-the-loop / break-glass / kill-switch sur les sessions actives. Votre gateway gouverne la requete ; Olivares gouverne l’agent et tout ce qu’il touche, et le prouve a un auditeur.
Ce qu’un gateway et les Guardrails font bien (utilisez-les pour cela)
Ce sont des capacites bien comprises et consolidees, et les fournisseurs les decrivent clairement :
- Les AI gateways sont des gestionnaires de chemin de requete pour les appels aux modeles. LiteLLM est 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 permet de “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). Routage, fallbacks, cache, cles virtuelles, budgets par cle, journalisation des requetes — c’est leur domaine.
- Les Guardrails des hyperscalers sont des filtres de securite de contenu. Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications” qui “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — filtres de contenu, sujets refuses, filtres de mots, expurgation de PII, controles de grounding contextuel et de raisonnement automatise (AWS).
Si votre probleme est “donner a mes applications un point d’acces unique vers plusieurs modeles, avec budgets, cache et filtrage de contenu”, cette pile le resout et vous n’avez pas besoin d’un plan de controle pour cela. Nous nous integrons a ce schema ; nous ne le reimplementons pas.
La lacune de gouvernance qu’ils laissent ouverte
Un gateway voit une requete. Les Guardrails voient du contenu. Aucun ne voit l’agent — son identite dans le temps, ce qu’il a atteint sur votre plan de donnees, qui a autorise une action risquee, ni si quoi que ce soit peut etre prouve par la suite. C’est cette lacune qu’Olivares comble.
| Lacune laissee par le gateway / Guardrails | Pourquoi c’est important | Ce qu’Olivares AI apporte |
|---|---|---|
| Enforcement au niveau du runtime de l’agent | Un gateway applique les regles a la frontiere de la requete ; il ne peut pas arreter un tool-call local de Claude Code qui ne le traverse jamais | Un PEP deny-closed en processus au niveau de l’agent : porte d’identite ferme, disposition de politique, overlay de politique en temps reel, le tout avant l’execution de l’outil |
| Preuve inviolable | Le gateway et les Guardrails emettent des logs — des enregistrements de requetes mutables ; un auditeur veut des preuves immuables | Registre append-only, chaine par hash, signe Ed25519, verifiable hors serveur, exportable en tant que preuve OSCAL |
| Cycle de vie des identites non humaines | La “cle virtuelle” d’un gateway est un conteneur de budget, pas une identite provisionnee, attribuee, alternee et desactivee | Cycle de vie NHI : obsolescence puis blocage, cascade de desactivation, controle dual sur la rotation, lie a la carte d’acces |
| Intervention sur session active | Les logs et budgets sont a posteriori ; aucun des outils evalues n’arrete une session en cours | Approbations HITL, break-glass et un kill switch qui refuse toute actuation gouvernee jusqu’a une reactivation avec controle dual |
| Ground truth sur l’ensemble de l’infrastructure | Un gateway ne voit que les appels qui le traversent ; les agents touchent aussi des BDD, des object stores, MCP et des fichiers directement | La carte d’acces read-first R/RW et la derive Permitted-vs-Observed, corroboree avec l’audit natif |
| Souverainete | Les gateways SaaS et les Guardrails cloud traitent ce trafic dans leur cloud | Self-hosted / air-gapped ; le plan de donnees ne quitte jamais votre perimetre |
Rien de tout cela n’est une fonction de routage. C’est bien le point : la lacune n’est pas un meilleur routage, c’est une gouvernance que le chemin de requete n’a jamais ete concu pour fournir.
Sur les Guardrails en particulier : la securite de contenu est un hook, pas un concurrent
Bedrock Guardrails peut etre applique de deux facons — en ligne pendant un appel
d’inference Bedrock, ou “directly through the ApplyGuardrail API without
invoking the foundation models”, qui fonctionne “with any foundation model
whether hosted on Amazon Bedrock or self-hosted models”
(AWS). C’est genuinement utile, et
Olivares traite la securite de contenu comme un detecteur que vous branchez,
jamais comme un mur que nous vous demandons de choisir a la place des
Guardrails. Deux faits honnetes et distincts :
- Le proxy d’inference en ligne expose une couture d’inspection de contenu — un point connectable ou un detecteur de contenu / DLP renvoie un verdict sur lequel le decideur deny-closed agit. La securite de contenu a sa place la, dans le pipeline, plutot que d’etre reimplementee en tant que filtre concurrent.
- Olivares lit les decisions propres de vos Guardrails en mode read-first. Le
connecteur AWS ingere les decisions des guardrails Bedrock depuis leurs logs
CloudWatch / S3 en tant que posture et preuve ; il n’invoque deliberement
pas lui-meme le runtime payant
ApplyGuardrail. Vos verdicts de contenu integrent le registre inviolable.
Ainsi, la securite de contenu se compose avec ce que vous utilisez deja. Ce que les Guardrails ne documentent pas — et ou la lacune de gouvernance reste ouverte — est le reste de la vie de l’agent : les pages Bedrock ne documentent ni identite d’agent, ni gestion de sessions, ni approbations humaines, ni gouvernance des couts (non documente sur ces pages, verifie le 21-06-2026). Olivares est exactement ce complement : il porte l’identite, les controles de session, les approbations et les preuves ; le filtre de contenu reste la ou il vit deja.
Comment ils se composent
Un agencement sain garde chaque outil dans son couloir :
- Conservez votre gateway (LiteLLM / Portkey / Kong / Cloudflare) en tant que plan d’appels aux modeles — routage, cache, cles virtuelles, budgets sur la requete.
- Conservez vos Guardrails (Bedrock / Azure Content Safety) en tant que
detecteur de securite de contenu — le PEP d’Olivares execute un detecteur
connectable a sa couture d’inspection de contenu et lit les decisions propres de
vos Guardrails en mode read-first comme preuve ; il n’invoque pas
ApplyGuardraillui-meme. - Ajoutez Olivares a cote en tant que plan de gouvernance et de preuve : le PEP en processus sur les agents qui ne passent jamais par votre gateway, la carte d’acces sur l’ensemble de l’infrastructure, le registre inviolable et les controles HITL/break-glass/kill en temps reel.
Le seul point ou Olivares touche l’inference est etroit et explicite — un chemin
de gateway uniquement par API key pour les appelants SDK brut ou curl,
decrit dans
Governing subscription-authed agents.
Il existe pour gouverner le trafic que vos autres outils ne peuvent pas atteindre,
jamais pour rivaliser avec eux sur le routage, et il ne transporte jamais de
credential d’abonnement.
Quand votre gateway suffit
L’honnetete fonctionne dans les deux sens. Si vos agents n’appellent les modeles qu’a travers votre gateway, que vos besoins de securite de contenu sont couverts par les Guardrails, que vous n’avez aucun agent self-hosted ou sur poste de travail accedant directement a des bases de donnees / object stores / MCP, et que vous n’avez aucune exigence de souverainete ou de preuve inviolable — alors votre gateway avec ses logs et les Guardrails peut etre tout ce dont vous avez besoin, et vous ne devriez pas ajouter un plan de controle pour le simple fait de l’avoir.
Olivares gagne sa place lorsque les questions deviennent transversales a l’infrastructure et adversariales : quels agents existent et qu’a reellement atteint chacun, puis-je arreter une mauvaise action deny-closed au niveau de l’agent, qui a autorise l’action risquee, et puis-je remettre a un auditeur des preuves immuables — le tout sans envoyer ce tableau dans le cloud d’un tiers. Pour le traitement approfondi de deux comparaisons adjacentes, consultez vs AI control towers et vs LLM observability.