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 une passerelle IA générale : il ne met pas en cache et ne répartit pas la charge du trafic de modèles, et il ne revendique aucune matrice universelle de fournisseurs, de modèles ou de routage. Il résout des politiques de routage en une chaîne de repli ordonnée, et dispose d’un seul chemin d’exécution mesuré — deny-closed, n’actionnant qu’un client compatible Claude Messages que vous configurez, directement ou avec votre propre endpoint de passerelle comme base URL Messages. Au-delà de ce chemin, il est le plan de gouvernance et de preuve : application en processus dans le runtime de l’agent, registre infalsifiable, cycle de vie d’identité non humaine et human-in-the-loop / break-glass / kill-switch sur les sessions actives. Il se compose avec la passerelle que vous exploitez déjà au lieu de la remplacer.
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.
Ce que chaque produit documente aujourd’hui
Lu le 2026-09-12 sur la page de chaque éditeur. Ce sont les limites des pages lues, pas des affirmations sur un produit entier, et aucune n’est un classement.
| Produit | Surface pour agents qu’il documente | Ce que la page ne couvre pas |
|---|---|---|
| LiteLLM | La documentation du proxy comporte une section “Agent & MCP Gateway”, ainsi que Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | La page lue documente la surface du proxy ; l’application des règles dans un runtime d’agent qui ne le traverse jamais reste en dehors |
| Portkey | Sa liste de produits comprend Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | La page lue est un aperçu des fonctionnalités ; elle ne décrit pas de carte d’accès permis-versus-observé sur tout le parc |
| 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 page lue est une présentation produit ; elle ne décrit pas d’exploitation self-hosted ou air-gapped de ce plan |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, utilisables en ligne ou “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | Ce sont des pages de sécurité du contenu ; le cycle de vie de l’identité d’agent, l’intervention en session et les approbations n’en sont pas le sujet et n’y sont pas documentés |
L’ancien cadrage était donc faux. « Les passerelles ne voient jamais l’agent » ne tient pas face aux pages ci-dessus : LiteLLM et Portkey documentent des surfaces d’agents et MCP, et Cloudflare qualifie sa passerelle de plan de contrôle. Ce qui reste différent, c’est où s’applique l’enforcement et quel type de trace en sort : une comparaison d’architecture, pas une affirmation d’absence.
Là où les architectures diffèrent encore
Conditionnel, pas universel — chaque ligne vaut quand la condition de gauche est remplie :
| Si vos agents… | Alors un produit de chemin de requête | Alors Olivares AI |
|---|---|---|
| …n’atteignent les modèles qu’à travers le proxy | gouverne chaque appel qu’il voit, à la requête | apporte peu sur le chemin de requête lui-même |
| …s’exécutent aussi localement et atteignent directement bases de données, stockages objet, MCP ou fichiers | ne peut pas voir les appels qui ne le traversent pas | applique un enforcement deny-closed en processus sur l’agent, avant l’exécution de l’outil |
| …ont besoin d’une trace qu’un auditeur peut vérifier hors machine | émettent des logs de requêtes, qui sont des enregistrements mutables | registre append-only, chaîné par hash, signé Ed25519, vérifiable hors machine |
| …doivent être arrêtés en pleine session | n’est pas l’endroit où une session active est arrêtée | approbations HITL, break-glass et un kill switch avec réactivation en double contrôle |
| …doivent être identifiés sur toute leur vie | une virtual key est une enveloppe budgétaire | cycle de vie d’identité non humaine : blocage pour obsolescence, cascade de départ, rotation en double contrôle |
| …doivent rester dans votre périmètre | les plans SaaS traitent ce trafic dans leur cloud | self-hosted ou air-gapped ; le plan de données ne quitte pas votre périmètre |
Le chemin d’exécution d’Olivares et ses limites réelles
Olivares touche bien à l’inférence, en un seul point mesuré, et la description honnête est celle que porte sa propre mesure actuelle :
- La route
POST /routing-policies/{id}/executeest deny-closed par construction et n’actionne qu’un client compatible Claude Messages, directement ou avec un endpoint de passerelle résolu comme base URL Messages — votre passerelle actuelle peut donc être cet endpoint. - La résolution de politiques produit une chaîne de repli ordonnée. Le module résout toujours une route et n’agit qu’à travers un port exécuteur ; l’exécuteur par défaut n’est pas câblé, donc le routage se résout sans aucun appel fournisseur tant qu’un opérateur n’en compose pas un.
- Deux barrières de portée deny-closed et la barrière d’arrêt du kill-switch s’exécutent avant la barrière budgétaire FinOps, qui s’exécute avant l’exécuteur.
Et ce qu’il n’établit explicitement pas, dans les termes du même enregistrement :
- aucune matrice universelle de fournisseurs ou de modèles — le protocole Claude Messages établit une route configurée, pas une matrice ;
- aucune garde centralisée des clés — les champs de clé fournisseur sont des références ;
- aucune exécution depuis la console — la console résout et teste des politiques et n’a pas d’appel d’exécution.
Il s’agit d’une mesure des sources actuelles, pas d’une acceptation de capacité : l’enregistrement de claims en vigueur maintient celle-ci et toutes les autres capacités comme implémentées et non acceptées, sans aucun reçu d’exécution derrière. À prendre comme la forme du chemin, pas comme une fonctionnalité certifiée.
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 2026-09-12). 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.