Wenn Sie bereits in ein AI-Gateway oder in die Guardrails eines Hyperscalers investiert haben, ist das Erste, was man ehrlich sagen muss: Behalten Sie sie — Olivares AI versucht nicht, sie zu ersetzen. Die Aufgabe eines Gateways ist der Modellaufruf — routen, cachen, balancieren, budgetieren. Die Aufgabe der Guardrails ist die Inhaltssicherheit bei diesem Aufruf. Beide sind real, beide leisten gute Arbeit, und keines von beiden ist das, was Olivares ist.
TL;DR: Olivares AI ist kein AI-Gateway. Es routet nicht, cached nicht, load-balanced nicht und befindet sich nicht auf dem Hot Path Ihres Modellverkehrs — und wird es nie. Es positioniert sich neben und hinter Ihrem Gateway als die Governance- und Evidenzebene: In-Process-Enforcement innerhalb der Agent-Runtime, ein manipulationssicheres Evidenz-Ledger, Non-Human-Identity-Lifecycle und Human-in-the-Loop / Break-Glass / Kill-Switch über aktive Sitzungen. Ihr Gateway regiert die Anfrage; Olivares regiert den Agenten und alles, was er berührt, und beweist es einem Auditor.
Was ein Gateway und Guardrails gut können (nutzen Sie sie dafür)
Das sind bewährte, gut verstandene Fähigkeiten, und die Anbieter beschreiben sie klar:
- AI-Gateways sind Anfragepfad-Manager für Modellaufrufe. LiteLLM ist ein “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 ermöglicht “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). Routing, Fallbacks, Caching, virtuelle Schlüssel, Budgets pro Schlüssel, Anfrage-Logging — das ist ihr Bereich.
- Hyperscaler-Guardrails sind Inhaltssicherheitsfilter. 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” — Inhaltsfilter, gesperrte Themen, Wortfilter, PII-Redaktion, Contextual-Grounding- und Automated-Reasoning-Prüfungen (AWS).
Wenn Ihr Problem lautet „meinen Anwendungen einen einzigen Endpoint zu vielen Modellen geben, mit Budgets, Caching und Inhaltsfilterung”, dann löst dieser Stack es, und Sie brauchen dafür kein Control Plane. Wir integrieren uns mit diesem Muster; wir reimplementieren es nicht.
Die Governance-Lücke, die sie offen lassen
Ein Gateway sieht eine Anfrage. Guardrails sehen Inhalt. Keines von beiden sieht den Agenten — seine Identität über die Zeit, worauf er in Ihrem Data Plane zugegriffen hat, wer eine riskante Aktion genehmigt hat, und ob sich davon etwas im Nachhinein beweisen lässt. Das ist die Lücke, die Olivares schließt.
| Lücke, die Gateway / Guardrails lassen | Warum es wichtig ist | Was Olivares AI bietet |
|---|---|---|
| Enforcement in der Agent-Runtime | Ein Gateway setzt am Anfragegrenzpunkt durch; es kann einen lokalen Claude Code Tool-Call, der es nie durchquert, nicht stoppen | Ein deny-closed In-Process-PEP am Agenten: Firm-Identity-Gate, Policy-Disposition, Live-Policy-Overlay, alles bevor das Tool ausgeführt wird |
| Manipulationssichere Evidenz | Gateway und Guardrails erzeugen Logs — veränderbare Anfragedatensätze; ein Auditor verlangt unveränderliche Beweise | Append-only, hash-verkettetes, Ed25519-signiertes Ledger, off-box verifizierbar, exportierbar als OSCAL-Evidenz |
| Non-Human-Identity-Lifecycle | Der „virtuelle Schlüssel” eines Gateways ist ein Budget-Bucket, keine Identität, die provisioniert, zugeordnet, rotiert und offgeboardet wird | NHI-Lifecycle: Veralterung → Sperre, Offboarding-Kaskade, Dual-Control bei Rotation, gebunden an die Access Map |
| Intervention in aktiven Sitzungen | Logs und Budgets sind nachträglich; keines dieser evaluierten Tools stoppt eine Sitzung im laufenden Betrieb | HITL-Genehmigungen, Break-Glass und ein Kill Switch, der jegliche governierte Aktuation unterbindet, bis eine Dual-Control-Reaktivierung erfolgt |
| Ground Truth über die gesamte Infrastruktur | Ein Gateway sieht nur die Aufrufe, die durch es hindurchgehen; Agenten greifen auch auf Datenbanken, Object Stores, MCP und Dateien direkt zu | Die read-first R/RW Access Map und die Permitted-vs-Observed-Drift, korroboriert gegen die native Auditierung |
| Souveränität | SaaS-Gateways und Cloud-Guardrails verarbeiten diesen Verkehr in ihrer Cloud | Self-hosted / air-gapped; das Data Plane verlässt nie Ihren Perimeter |
Nichts davon sind Routing-Funktionen. Genau das ist der Punkt: Die Lücke ist nicht besseres Routing, sondern Governance, die der Anfragepfad nie zu leisten vorgesehen war.
Zu den Guardrails im Speziellen: Inhaltssicherheit ist ein Hook, kein Konkurrent
Bedrock Guardrails können auf zwei Arten angewendet werden — inline während eines
Bedrock-Inferenzaufrufs, oder “directly through the ApplyGuardrail API without
invoking the foundation models”, was funktioniert “with any foundation model
whether hosted on Amazon Bedrock or self-hosted models”
(AWS). Das ist echten Mehrwert, und
Olivares behandelt Inhaltssicherheit als einen Detektor, den Sie einstecken,
niemals als eine Mauer, die wir Sie bitten anstelle der Guardrails zu wählen.
Zwei ehrliche, eigenständige Fakten:
- Der Inline-Inferenz-Proxy legt eine Content-Inspection-Schnittstelle frei — einen steckbaren Punkt, an dem ein Content-/DLP-Detektor ein Urteil abgibt, auf das der deny-closed Entscheider reagiert. Inhaltssicherheit gehört dorthin, in die Pipeline, statt als konkurrierender Filter reimplementiert zu werden.
- Olivares liest die eigenen Entscheidungen Ihrer Guardrails read-first. Der
AWS-Konnektor ingested die Bedrock-Guardrail-Entscheidungen aus deren
CloudWatch-/S3-Logs als Posture und Evidenz; er ruft absichtlich nicht die
kostenpflichtige
ApplyGuardrail-Runtime selbst auf. Ihre Inhaltsurteile werden Teil des manipulationssicheren Datensatzes.
So fügt sich Inhaltssicherheit mit dem zusammen, was Sie bereits betreiben. Was die Guardrails nicht dokumentieren — und wo die Governance-Lücke offen bleibt — ist der Rest des Agentenlebens: Die Bedrock-Seiten dokumentieren keine Agentenidentität, kein Sitzungsmanagement, keine menschlichen Genehmigungen und keine Kostengovernance (auf diesen Seiten nicht dokumentiert, geprüft am 21.06.2026). Olivares ist genau dieses Komplement: Es trägt die Identität, die Sitzungskontrollen, die Genehmigungen und die Evidenz; der Inhaltsfilter bleibt, wo er bereits lebt.
Wie sie zusammenwirken
Eine gesunde Anordnung hält jedes Tool in seiner Spur:
- Behalten Sie Ihr Gateway (LiteLLM / Portkey / Kong / Cloudflare) als die Ebene für Modellaufrufe — Routing, Caching, virtuelle Schlüssel, Budgets auf der Anfrage.
- Behalten Sie Ihre Guardrails (Bedrock / Azure Content Safety) als Ihren
Inhaltssicherheitsdetektor — der Olivares-PEP führt einen steckbaren Detektor
an seiner Content-Inspection-Schnittstelle aus und liest die eigenen
Entscheidungen Ihrer Guardrails read-first als Evidenz; er ruft
ApplyGuardrailnicht selbst auf. - Ergänzen Sie Olivares daneben als die Governance- und Evidenzebene: der In-Process-PEP auf den Agenten, die Ihr Gateway nie durchlaufen, die Access Map über die gesamte Infrastruktur, das manipulationssichere Ledger und die Live-HITL/Break-Glass/Kill-Kontrollen.
Der einzige Punkt, an dem Olivares die Inferenz berührt, ist eng und explizit —
ein API-Key-only-Gateway-Pfad für direkte SDK-/curl-Aufrufer, beschrieben
in Governing subscription-authed agents.
Er existiert, um Verkehr zu regieren, den Ihre anderen Tools nicht erreichen
können, niemals um mit ihnen beim Routing zu konkurrieren, und er transportiert
niemals eine Subskriptions-Credential.
Wann Ihr Gateway ausreicht
Ehrlichkeit wirkt in beide Richtungen. Wenn Ihre Agenten Modelle ausschließlich über Ihr Gateway aufrufen, Ihre Inhaltssicherheitsanforderungen durch Guardrails erfüllt sind, Sie keine self-hosted oder auf Laptops laufenden Agenten haben, die direkt auf Datenbanken / Object Stores / MCP zugreifen, und Sie keinen Souveränitäts- oder Manipulationssicherheitsanspruch haben — dann sind Ihr Gateway nebst Logs und Guardrails möglicherweise alles, was Sie brauchen, und Sie sollten kein Control Plane um seiner selbst willen hinzufügen.
Olivares verdient seinen Platz, wenn die Fragen infrastrukturweit und adversarial werden: Welche Agenten existieren und worauf hat jeder tatsächlich zugegriffen, kann ich eine schädliche Aktion deny-closed am Agenten stoppen, wer hat die riskante genehmigt, und kann ich einem Auditor unveränderliche Beweise übergeben — all das, ohne dieses Bild in die Cloud eines Dritten zu senden. Für die vertiefte Behandlung zweier angrenzender Vergleiche siehe vs AI control towers und vs LLM observability.