Als u al geïnvesteerd heeft in een AI-gateway of in de Guardrails van een hyperscaler, is het eerlijkste eerste wat we kunnen zeggen: behoud ze, Olivares AI probeert ze niet te vervangen. De taak van een gateway is de modelaanroep — routeren, cachen, balanceren, budgetteren. De taak van Guardrails is inhoudsbeveiliging op die aanroep. Beide zijn reëel, beide doen hun werk goed, en geen van beide is wat Olivares is.
TL;DR: Olivares AI is geen algemene AI-gateway: het cachet modelverkeer niet en verdeelt geen last, en claimt geen universele provider-, model- of routingmatrix. Het lost routingbeleid op in een geordende fallbackketen en heeft één gemeten uitvoeringspad — deny-closed, dat uitsluitend actueert via een door u geconfigureerde, met Claude Messages compatibele client, rechtstreeks of met uw eigen gateway-endpoint als Messages-basis-URL. Daarbuiten is het het governance- en bewijsvlak: in-process handhaving in de agent-runtime, een manipulatiebestendig grootboek, levenscyclus van niet-menselijke identiteiten en human-in-the-loop / break-glass / kill-switch over actieve sessies. Het werkt samen met de gateway die u al draait in plaats van die te vervangen.
Wat een gateway en Guardrails goed doen (gebruik ze hiervoor)
Dit zijn gevestigde, goed begrepen capaciteiten, en de leveranciers beschrijven ze helder:
- AI-gateways zijn verzoekpadmanagers voor modelaanroepen. LiteLLM is een “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 stelt u in staat om “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). Routering, fallbacks, caching, virtuele sleutels, budgetten per sleutel, verzoekregistratie — dat is hun domein.
- Hyperscaler Guardrails zijn inhoudsbeveiliging-filters. Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications” die “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — inhoudsfilters, geweigerde onderwerpen, woordfilters, PII-redactie, contextueel-grounding- en geautomatiseerd-redeneercontroles (AWS).
Als uw probleem is “mijn applicaties een enkel endpoint geven naar meerdere modellen, met budgetten, caching en inhoudsfiltering,” dan lost die stack het op en heeft u geen control plane nodig om dat te doen. Wij integreren met dat patroon; we herimplementeren het niet.
Wat elk product vandaag documenteert
Gelezen op 2026-09-12 op de eigen pagina van elke leverancier. Dit zijn grenzen van de gelezen pagina’s, geen uitspraken over een heel product, en geen ervan is een rangschikking.
| Product | Gedocumenteerde agent-oppervlakte | Wat de pagina niet dekt |
|---|---|---|
| LiteLLM | De proxydocumentatie bevat een sectie “Agent & MCP Gateway”, plus Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | De gelezen pagina documenteert het proxy-oppervlak; handhaving binnen een agent-runtime die de proxy nooit passeert valt erbuiten |
| Portkey | De productlijst noemt Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | De gelezen pagina is een functieoverzicht; het beschrijft geen estate-brede kaart van toegestane versus waargenomen toegang |
| 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) | De gelezen pagina is een productoverzicht; self-hosted of air-gapped gebruik van dat vlak wordt er niet beschreven |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, inline bruikbaar of “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | Dit zijn pagina’s over inhoudsbeveiliging; levenscyclus van agent-identiteit, ingrijpen in sessies en goedkeuringen zijn niet hun onderwerp en staan er niet in |
De oude formulering was dus onjuist. „Gateways zien de agent nooit” houdt geen stand tegenover bovenstaande pagina’s: LiteLLM en Portkey documenteren agent- en MCP-oppervlakken, en Cloudflare noemt zijn gateway een control plane. Wat verschilt is waar gehandhaafd wordt en welk soort vastlegging eruit komt: een architectuurvergelijking, geen afwezigheidsclaim.
Waar de architecturen nog verschillen
Voorwaardelijk, niet universeel — elke regel geldt wanneer de voorwaarde links geldt:
| Als uw agents… | Dan een product op het verzoekpad | Dan Olivares AI |
|---|---|---|
| …modellen alleen via de proxy bereiken | bestuurt elke aanroep die het ziet, bij het verzoek | voegt weinig toe op het verzoekpad zelf |
| …ook lokaal draaien en rechtstreeks databases, object stores, MCP of bestanden bereiken | kan aanroepen die er niet doorheen gaan niet zien | handhaaft deny-closed in-process bij de agent, voordat de tool draait |
| …een vastlegging nodig hebben die een auditor buiten de doos kan verifiëren | geven verzoeklogs uit, dat zijn muteerbare records | append-only, hash-geketend, Ed25519-ondertekend grootboek, buiten de doos verifieerbaar |
| …midden in een sessie gestopt moeten worden | is niet waar een actieve sessie wordt gestopt | HITL-goedkeuringen, break-glass en een kill switch met heractivering onder dubbele controle |
| …hun hele leven identificeerbaar moeten zijn | een virtual key is een budgetpot | levenscyclus van niet-menselijke identiteiten: blokkade bij veroudering, offboarding-cascade, rotatie onder dubbele controle |
| …binnen uw perimeter moeten blijven | SaaS-vlakken verwerken dat verkeer in hun cloud | self-hosted of air-gapped; het data plane verlaat uw perimeter niet |
Het uitvoeringspad van Olivares en zijn werkelijke grenzen
Olivares raakt inferentie wél, op één gemeten plek, en de eerlijke beschrijving is die van zijn eigen huidige meting:
- De route
POST /routing-policies/{id}/executeis deny-closed by construction en actueert uitsluitend via een met Claude Messages compatibele client, rechtstreeks of met een opgelost gateway-endpoint als Messages-basis-URL — uw bestaande gateway kan dus dat endpoint zijn. - Beleidsresolutie levert een geordende fallbackketen. De module lost altijd een route op en handelt alleen via een executor-poort; de standaard-executor is niet bedraad, dus routing lost op zonder enige provideraanroep totdat een beheerder er een samenstelt.
- Twee deny-closed scope-gates en het stop-gate van de kill-switch draaien vóór het FinOps-budgetgate, dat vóór de executor draait.
En wat het uitdrukkelijk niet vaststelt, in de woorden van dezelfde vastlegging:
- geen universele provider- of modelmatrix — het Claude Messages-protocol vestigt één geconfigureerde route, geen matrix;
- geen centrale sleutelbewaring — providersleutelvelden zijn verwijzingen;
- geen uitvoering vanuit de console — de console lost beleid op en test het en heeft geen uitvoeraanroep.
Dit is een meting van de huidige bronnen, geen acceptatie van een mogelijkheid: de geldende claims-vastlegging houdt deze en elke andere mogelijkheid als geïmplementeerd en niet geaccepteerd, zonder enige uitvoeringsbon erachter. Lees het als de vorm van het pad, niet als een gecertificeerde functie.
Over Guardrails specifiek: inhoudsbeveiliging is een hook, geen concurrent
Bedrock Guardrails kan op twee manieren worden toegepast — inline tijdens een Bedrock
inferentie-aanroep, of “directly through the ApplyGuardrail API without
invoking the foundation models”, wat werkt “with any foundation model whether
hosted on Amazon Bedrock or self-hosted models”
(AWS). Dat is oprecht nuttig, en
Olivares behandelt inhoudsbeveiliging als een detector die u aansluit, nooit
als een muur waarvoor we u vragen te kiezen in plaats van Guardrails. Twee
eerlijke, afzonderlijke feiten:
- De inline inferentie-proxy biedt een inhoudsinspectienaad — een plugbaar punt waar een inhouds-/DLP-detector een oordeel retourneert waarop de deny-closed beslisser handelt. Inhoudsbeveiliging hoort daar, in de pipeline, in plaats van opnieuw geïmplementeerd te worden als een concurrerend filter.
- Olivares leest de eigen beslissingen van uw Guardrails in read-first-modus.
De AWS-connector neemt Bedrock guardrail-beslissingen op uit hun CloudWatch /
S3-logs als postuur en bewijs; het roept bewust niet zelf de betaalde
ApplyGuardrail-runtime aan. Uw inhoudsoordelen worden onderdeel van het fraudebestendige register.
Zo composeert inhoudsbeveiliging met wat u al draait. Wat Guardrails niet documenteren — en waar het governancegat open blijft — is de rest van het leven van de agent: de Bedrock-pagina’s documenteren geen agentidentiteit, geen sessiebeheer, geen menselijke goedkeuringen en geen kostengovernance (niet gedocumenteerd op die pagina’s, gecontroleerd 2026-09-12). Olivares is precies dat complement: het draagt de identiteit, de sessiecontroles, de goedkeuringen en het bewijs; het inhoudsfilter blijft waar het al leeft.
Hoe ze componeren
Een gezonde opzet houdt elk instrument in zijn rijstrook:
- Behoud uw gateway (LiteLLM / Portkey / Kong / Cloudflare) als het modelaanroepvlak — routering, caching, virtuele sleutels, budgetten op het verzoek.
- Behoud uw Guardrails (Bedrock / Azure Content Safety) als uw
inhoudsbeveiligingsdetector — de Olivares PEP draait een plugbare detector
bij zijn inhoudsinspectienaad en leest de eigen beslissingen van uw Guardrails
in read-first-modus als bewijs; het roept zelf
ApplyGuardrailniet aan. - Voeg Olivares ernaast toe als het governance- en bewijslaagvlak: de in-process PEP op de agents die nooit door uw gateway gaan, de toegangskaart over het gehele landgoed, het fraudebestendige register, en de live HITL/break-glass/kill-controles.
Het enige punt waar Olivares inferentie raakt is smal en expliciet — een
API-key-only gatewaypad voor directe SDK/curl-aanroepers, beschreven in
Governing subscription-authed agents.
Het bestaat om verkeer te besturen dat uw andere tools niet kunnen bereiken, nooit
om met hen te concurreren op routering, en het draagt nooit een
abonnementscredential.
Wanneer uw gateway voldoende is
Eerlijkheid werkt in beide richtingen. Als uw agents alleen modellen aanroepen via uw gateway, uw inhoudsbeveiligingsbehoeften gedekt zijn door Guardrails, u geen self-hosted of laptop-agents heeft die databases / objectstores / MCP rechtstreeks bereiken, en u geen soevereiniteits- of fraudebestendig-bewijsvereiste heeft — dan zijn uw gateway plus zijn logs en Guardrails wellicht alles wat u nodig heeft, en dient u geen control plane toe te voegen omwille van zichzelf.
Olivares verdient zijn plaats wanneer de vragen landgoedbreed en adversarieel worden: welke agents bestaan en waar elk daadwerkelijk toegang toe had, kan ik een slechte actie deny-closed stoppen bij de agent, wie de riskante goedkeurde, en kan ik een auditor onveranderlijk bewijs overhandigen — dit alles zonder dat beeld naar andermans cloud te sturen. Voor de uitgebreidere behandeling van twee aangrenzende vergelijkingen, zie vs AI control towers en vs LLM observability.