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 AI-gateway. Het routeert niet, cachet niet, load-balancet niet en zit niet op het warme pad van uw modelverkeer, en dat zal het nooit doen. Het zit naast en achter uw gateway als het governance- en bewijslaagvlak: in-process handhaving binnen de agent-runtime, een fraudebestendig bewijsregister, levenscyclus van niet-menselijke identiteiten, en human-in-the-loop / break-glass / kill-switch over actieve sessies. Uw gateway bestuurt het verzoek; Olivares bestuurt de agent en alles wat hij raakt, en bewijst het aan een auditor.
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.
Het governancegat dat ze openlaten
Een gateway ziet een verzoek. Guardrails zien inhoud. Geen van beide ziet de agent — zijn identiteit in de tijd, waar hij toegang toe had in uw data plane, wie een riskante actie goedkeurde, en of dat later bewezen kan worden. Dat is het gat dat Olivares vult.
| Gat dat de gateway / Guardrails openlaten | Waarom het ertoe doet | Wat Olivares AI biedt |
|---|---|---|
| Handhaving in de agent-runtime | Een gateway handhaaft op de verzoekgrens; het kan een lokale Claude Code tool-call die er nooit doorheen gaat niet stoppen | Een deny-closed in-process PEP bij de agent: firm-identity gate, beleidsdispositie, live-beleidsoverlay, allemaal voordat de tool wordt uitgevoerd |
| Fraudebestendig bewijs | Gateway en Guardrails produceren logs — muteerbare verzoekregistraties; een auditor wil onveranderlijk bewijs | Append-only, hash-geketend, Ed25519-ondertekend register, off-box verifieerbaar, exporteerbaar als OSCAL-bewijs |
| Levenscyclus van niet-menselijke identiteiten | De “virtuele sleutel” van een gateway is een budgetbucket, geen identiteit die wordt ingericht, toegekend, geroteerd en uitgeschreven | NHI-levenscyclus: veroudering → blokkering, offboarding-cascade, dual-control bij rotatie, gebonden aan de toegangskaart |
| Interventie in actieve sessies | Logs en budgetten zijn achteraf; geen van deze beoordeelde tools stopt een sessie midden in de vlucht | HITL-goedkeuringen, break-glass, en een kill switch die alle bestuurde actuatie weigert totdat een dual-control heractivering plaatsvindt |
| Ground truth over het gehele landgoed | Een gateway ziet alleen de aanroepen die erdoorheen gaan; agents raken ook databases, objectstores, MCP en bestanden rechtstreeks aan | De read-first R/RW toegangskaart en Permitted-vs-Observed drift, gecorroboreerd tegen native audit |
| Soevereiniteit | SaaS-gateways en cloud-Guardrails verwerken dat verkeer in hun cloud | Self-hosted / air-gapped; het data plane verlaat nooit uw perimeter |
Niets hiervan zijn routeringsfuncties. Dat is het punt: het gat is geen betere routering, het is governance die het verzoekpad nooit was ontworpen om te bieden.
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 21-06-2026). 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.