Envoy AI Gateway (Jetzt Agent Router): Ein ehrlicher Testbericht

Die Umbenennung in einem Absatz

Falls Sie nach „Envoy AI Gateway“ gesucht haben und hier gelandet sind: Sie sind genau richtig, und das Produkt existiert weiterhin. Es heißt jetzt Agent Router, ist unter theagentrouter.ai erreichbar und ist ein eigenständiges Projekt innerhalb der Agentic AI Foundation (einem Projektverbund der LF Projects, LLC) statt eines Envoy-Subprojekts unter dem Dach der CNCF. Die Ankündigung datiert vom 9. September 2026; der Wechsel wurde am darauffolgenden Tag wirksam.

Technisch gesehen gab es keine Breaking Changes. Der Namespace lautet weiterhin envoy-ai-gateway-system, die API-Gruppe aigateway.envoyproxy.io, das CLI weiterhin aigw und die Lizenz bleibt Apache 2.0. Manifeste in Ihrem Repository funktionieren unverändert weiter. Geändert haben sich lediglich die Governance-Struktur, die Dokumentationsdomain, der Repository-Pfad und der Name. Im Folgenden verwenden wir die Bezeichnung „Agent Router“.

Was Agent Router tatsächlich ist

Agent Router ist eine erweiternde Schicht auf Envoy Gateway — kein Fork —, die Envoy die Kommunikation mit LLMs beibringt. Die projekteigene Formulierung bringt es auf den Punkt: „Agent Router konfiguriert. Envoy verarbeitet den Datenverkehr.“

Die Maintainer stammen laut der 1.0-Ankündigung von Tetrate, Bloomberg, Tencent, Netflix, AMD und Nutanix. Tetrate ist der kommerzielle Haupttreiber und bietet sowohl einen gehosteten Service als auch ein selbstverwaltetes Enterprise-Produkt darauf an. Es gibt wöchentliche Community-Meetings, öffentliche Design-Proposals und einen Discord-Server.

Versionshistorie

Ungefähr ein Minor-Release pro Quartal — ein gesunder Veröffentlichungsrhythmus. Die Version v1.0 enthält die verbindlichste Zusage in der Dokumentation des Projekts:

„Wir werden die APIs niemals ohne Abwärtskompatibilität ändern, es sei denn, es liegt ein kritisches Sicherheitsproblem vor. Sollten wir Anpassungen vornehmen müssen, stellen wir in den Release Notes stets einen Migrationspfad bereit.“

Das ist ein schriftliches, verbindliches Versprechen — weit mehr, als die meisten kommerziellen Gateways schriftlich garantieren.

Architektur

Agent Router trennt sauber zwischen Control Plane und Data Plane.

Control Plane. Der Kubernetes API Server dient als Konfigurationsschnittstelle. Der AI Gateway Controller verwaltet KI-spezifische Ressourcen und konfiguriert den External Processor, indem er xDS über den Extension-Server-Mechanismus von Envoy Gateway feinabstimmt; der Envoy Gateway Controller übernimmt die grundlegende Proxy-Konfiguration.

Data Plane. Envoy Proxy, ein External Processor (ext-proc), der KI-spezifische Transformationen und Validierungen durchführt, sowie ein Rate Limit Service für tokenbasiertes Limiting. Das MCP Gateway ist ein leichtgewichtiger Proxy innerhalb des Agent Router Sidecars.

Fünf CRDs, alle in v1beta1 bereitgestellt und durch die Stabilitätsgarantie von Version 1.0 abgedeckt: AIGatewayRoute (routet LLM-Datenverkehr und wählt Backends aus), AIServiceBackend (deklariert einen Upstream-Anbieter oder ein selbstgehostetes Modell), BackendSecurityPolicy (zentralisiert Upstream-Anmeldeinformationen), GatewayConfig (Konfiguration auf Gateway-Ebene) und MCPRoute (MCP-Multiplexing, Werkzeugfilterung, Autorisierung).

Die Konfiguration erfolgt über YAML-Dateien mittels kubectl. Die dokumentierten Feldnamen vermitteln einen guten Eindruck der Struktur — modelNameOverride an einem Backend für Modell-Virtualisierung, credentialOverride für Upstream-Anmeldeinformationen pro Anfrage, streamIdleTimeout für begrenzte Wartezeiten beim Streaming und auf einer MCPRoute:

Zudem verwalten Sie eine Versionsmatrix. Die Basis von v1.1.0 bilden Go 1.26.4, Envoy Gateway v1.8.1, Envoy Proxy v1.38.1, Gateway API v1.5.1, Inference Extension v1.0.2 und das MCP Go SDK v1.7.0. Upgrades von Envoy Gateway werden somit zu Ihrer direkten Abhängigkeit.

[SCREENSHOT: Agent Router — Architekturdiagramm der Dokumentationsseite mit Control Plane (AI Gateway Controller + Envoy Gateway Controller) und Data Plane (Envoy Proxy + External Processor + Rate Limit Service)]

Funktionsumfang laut Dokumentation

Provider — 16 direkt integriert: OpenAI, Azure OpenAI, Gemini, Vertex AI, Bedrock, Anthropic, Mistral, Cohere, Groq, Together AI, DeepInfra, DeepSeek, Hunyuan, SambaNova, Grok und Tetrate Agent Router Service. Selbstgehostete Instanzen von vLLM und Ollama sind über das CLI erreichbar.

Vereinheitlichte API. OpenAI-kompatibel: Chat, Completions, Embeddings, Bildgenerierung, Audio und die Responses API sowie nativ Anthropic über /anthropic/v1/messages. Providerübergreifende Übersetzungen decken Anwendungsfälle wie Anthropic Messages zu Bedrock Converse ab.

Traffic-Management. Token-basiertes Rate-Limiting. QuotaPolicy für Token-Budgets über konfigurierbare Zeitfenster. Provider-Fallback und automatisches Failover. Modellnamen-Virtualisierung über modelNameOverride, sodass der Wechsel von Providern eine reine Konfigurationsänderung und keine Codeanpassung erfordert. Header- und Body-Mutationen. In v1.1 streamIdleTimeout mit Failover — wird dieses vor dem ersten Token ausgelöst, leitet ein erneuter Versuch die Anfrage an das nächste Backend weiter.

Inference-Routing und Anmeldeinformationen. Unterstützung für InferencePool und Endpoint Picker, sowohl über HTTPRoute + InferencePool als auch AIGatewayRoute + InferencePool — besonders nützlich, wenn Sie eigene GPUs betreiben. BackendSecurityPolicy zentralisiert die Upstream-Authentifizierung: API-Schlüssel, AWS SigV4, Azure und cloud-native GCP-Identitäten einschließlich Workload Identity und GKE ADC.

Umfangreiche MCP-Unterstützung. Server-Multiplexing hinter einem einzelnen Endpunkt mit automatisch nach Backend vorangestellten Präfixen für Werkzeuge (github__issue_read), Werkzeugfilterung, OAuth mit PKCE gemäß MCP-Autorisierungsspezifikation, streamfähiges HTTP mit Wiederverbindung über Last-Event-ID. Ein herausragendes Merkmal ist die feingranulare Autorisierung mittels CEL über JWT-Claims und MCP-Kontext — request.mcp.method, request.mcp.tool, request.mcp.params, request.auth.jwt —, wobei tools/list nur die vom Aufrufer autorisierten Werkzeuge zurückgibt. Nur wenige Projekte bieten eine vergleichbare Funktionstiefe.

Observability. Prometheus-Metriken gemäß den OpenTelemetry GenAI Semantic Conventions, mit separater Erfassung von Reasoning-Tokens. OTel-Tracing mit OpenInference-Kompatibilität. Access Logs mit KI-Metadaten. v1.1 ergänzt gen_ai.*-Span-Attribute und ein Beispiel-Grafana-Dashboard im Repository.

Guardrails sind kein natives Kernfeature. In der Dokumentation gibt es keine eigene Seite für Guardrails; die Seite zu Sicherheitsfunktionen verweist weitgehend auf die Sicherheitsdokumentation von Envoy Gateway. Im Vergleich von Tetrate ist die Open-Source-Zeile als „Guardrail Hooks“ ausgewiesen, während vollwertige KI-Guardrails als Enterprise-Produkt angeboten werden.

Die tatsächlichen Stärken

Ein solides Projekt verdient eine fundierte Analyse seiner Stärken.

Die Data Plane basiert auf Envoy. Kein neuer, in Python oder Node geschriebener Proxy — sondern der Proxy, der bereits produktiven Datenverkehr in enormem Umfang verarbeitet. Das betriebliche Risiko der Data Plane ist somit minimal.

Die Stabilitätsgarantie ist außergewöhnlich. Eine verbindlich stabile v1beta1 Control-Plane-API mit schriftlichem Versprechen und zugesagtem Migrationspfad übertrifft das Angebot vieler kommerzieller Anbieter.

Herstellerübergreifende Maintainer-Basis. Tetrate, Bloomberg, Netflix, AMD, Nutanix und Tencent stellen Maintainer. Es handelt sich nicht um ein Einzelanbieter-Projekt mit Open-Source-Etikett; der Bus-Faktor bietet echten Schutz.

Keine künstlich beschnittene Community-Version. Tetrate bringt es klar auf den Punkt: „Keine proprietäre Data Plane, keine beschnittene Community-Version, keine vorenthaltenen Funktionen, um sie später zu verkaufen.“ Der Mehrwert der Enterprise-Version liegt im Flottenmanagement, nicht in gesperrten Data-Plane-Funktionen — ein vorbildliches Open-Core-Modell. Zudem ist das Projekt durchgehend standards-basiert aufgebaut (Gateway API, Inference Extension, OTel GenAI Conventions, OpenInference, MCP), was das Risiko eines Vendor Lock-ins minimiert.

Einfache Testmöglichkeiten. Ein einziger Befehl ohne Kubernetes oder Docker unter Linux oder macOS genügt:

OPENAI_API_KEY=sk-... aigw run

Damit steht ein OpenAI-kompatibler Router auf localhost:1975 bereit. Nur wenige Open-Source-AI-Gateway-Projekte führen so schnell zu einem funktionsfähigen Endpunkt.

Bekannte Anwender. Die Homepage führt Alan by Comma Soft, Bloomberg, LY Corporation, National Research Platform, Nutanix, Paper Compute Co., Simplifai, Stacklok, Tencent Cloud, Tetrate und Unwrap auf; der 1.0-Release-Beitrag dankt den ersten drei namentlich. Zwar finden sich keine formalen Fallstudien mit konkreten Kennzahlen — Logos und Danksagungen ersetzen keine Fallstudien —, aber immerhin bauen drei kommerzielle Produkte darauf auf (Tetrate Agent Router Service und Enterprise, Nutanix Agent Gateway), was ein solider Beleg für produktionsreifen Code ist.

[SCREENSHOT: Agent Router — Anwender-Bereich der Homepage mit den elf Unternehmenslogos]

Wo Teams an Grenzen stoßen

Dies stellt keine Kritik am Code dar. Es ist eine Bestandsaufnahme der Funktionen, die das Open-Source-Projekt nicht enthält — belegt durch das Fehlen in der Dokumentation oder den Eintrag in Tetrates kostenpflichtiger Vergleichsübersicht (Stand: 25. September 2026).

1. Es gibt keine grafische Benutzeroberfläche (UI). Die Navigation der Dokumentation enthält keine Admin-Konsole. Jede Einbindung eines neuen Modells, jede Schlüsselrotation und jede Kontingentänderung erfordert ein Kubernetes-Manifest über Ihre GitOps-Pipeline. Tetrate bietet „The Management Console“ als Enterprise-Komponente an. Für ein Platform-Team mag das ausreichen; für zwölf Anwendungsteams, die an einem Donnerstag ein neues Modell testen möchten, bedeutet es jedes Mal ein Support-Ticket.

2. Kein Platform-RBAC oder SSO für die Gateway-Administration. Kubernetes RBAC auf den CRDs ersetzt keine rollenbasierte Zugriffskontrolle für Modelle, MCP-Server und Teams. Die Authentifizierung von Anfragen auf der Data Plane (JWT, OIDC) wird von Envoy Gateway übernommen, betrifft jedoch die Aufrufer-Authentifizierung und nicht die administrative Zugriffskontrolle. Tetrate führt SSO mit Okta/Entra/OIDC/SAML und feingranulare Konsolen als Enterprise-Funktionen auf.

3. Kostenzuordnung beschränkt sich auf Metriken, kein Chargeback. Token-Metriken werden an Prometheus übermittelt. Die Umwandlung dieser Daten in teambezogene Ausgaben inklusive Preiskatalog, Showback und Chargeback müssen Sie selbst entwickeln — ebenso wie die laufende Aktualisierung des Preiskatalogs. Tetrate bringt es offen auf den Punkt: Bei gemischten Umgebungen aus selbstgehosteten GPUs und Token-basierten APIs gilt: „Die Zuordnung muss beides normalisieren, sonst sind die Zahlen für die Finanzabteilung reine Fiktion.“

4. Budgets gelten pro Gateway, nicht flächendeckend. QuotaPolicy bietet Token-Budgets über Zeitfenster, allerdings weist Tetrates Vergleich das Open-Source-Verhalten als „pro Gateway“ aus. Betreiben Sie Gateways in drei Regionen, kann ein Agent, der in einer Region abgelehnt wird, in einer anderen erfolgreich sein.

5. Keine Protokollierung von Prompts oder Antworten. Access Logs enthalten Modellnamen und Token-Zahlen; eine dokumentierte Erfassung, Speicherung, Suche oder Wiedergabe von Prompts und Antworten existiert nicht. Version 0.6 führte die Schwärzung (Redaction) von Anfragedaten ein — der Fokus liegt also auf der Entfernung von Daten, nicht auf deren Speicherung.

6. Keine Human-in-the-Loop-Freigaben und Guardrails müssen selbst mitgebracht werden. Die MCP-Autorisierung erfolgt als Allow/Deny zum Zeitpunkt der Anfrage; kritische Werkzeugaufrufe werden nicht durch manuelle Freigabeprozesse abgesichert. Tetrate bietet einen Notfall-Schalter (Kill Switch) für Agenten an, jedoch existiert kein automatisierter Freigabe-Workflow pro Aufruf. Ebenso fehlen im Open-Source-Projekt Funktionen zur Erkennung von PII, zum Schutz vor Prompt Injections, zur Inhaltsmoderation oder zum Scannen von Zugangsdaten.

7. Kubernetes ist Voraussetzung für den Produktivbetrieb. Der Befehl aigw run ist für lokale Entwicklerumgebungen gedacht. Für den Produktivbetrieb werden ein Cluster, Envoy Gateway, der AI Gateway Controller und ein Rate Limit Service benötigt. Falls Sie Kubernetes mit der Gateway API derzeit nicht nutzen, bedeutet dies einen erheblichen Einrichtungsaufwand, bevor das erste Token geroutet werden kann.

8. Klare Verantwortlichkeiten im Ernstfall. Der Support der Community erfolgt über GitHub, Discord, Slack und ein wöchentliches Meeting montags. Tetrate Enterprise bietet 24/7-Support mit SLA, einem festen Ansprechpartner, CVE-korrigierten Builds auf einem gewarteten Release-Pfad, Air-Gapped-Bereitstellung und einen aktuellen Modellkatalog. Im Vergleich von Tetrate ist die Open-Source-Spalte mit „Sie warten es selbst“ gekennzeichnet — die Gesamtsituation kurz zusammengefasst.

Möchten Sie den Kontrollpunkt ohne Eigenentwicklung nutzen?

Routen Sie Anfragen an über 1.000 Modelle — inklusive Kostenzuordnung, Budgets und RBAC.

Kostenlos starten

Eigenentwicklung vs. Kauf (Build vs. Buy) im direkten Vergleich

Wenn Ihr Platform-Team bereits Envoy Gateway einsetzt und über entsprechende Kapazitäten verfügt, stellt die rechte Spalte eine umsetzbare Roadmap dar. Andernfalls bauen Sie unbeabsichtigt ein eigenes Produkt auf. Bewerten Sie die Entscheidung wie jede andere Build-vs-Buy-Entscheidung: nach Personalaufwand in Monatsgehältern, nicht nach Lizenzgebühren.

Wo TrueFoundry ansetzt

Wir behaupten nicht, dass Agent Router ein schlechtes Produkt ist. Der Unterschied liegt im Funktionsumfang und der betrieblichen Verantwortung.

Das AI Gateway von TrueFoundry verfolgt denselben architektonischen Ansatz — einen zentralen Kontrollpunkt für Modell- und Tool-Datenverkehr —, stellt jedoch die umliegende Plattform direkt bereit, anstatt diese dem Anwender zu überlassen. Es erzeugt eine zusätzliche Latenz von lediglich ca. 3–4 ms, verarbeitet über 350 RPS pro vCPU und bindet mehr als 1.000 LLMs über eine einheitliche, OpenAI-kompatible API an.

Eine Benutzeroberfläche und eine effektive Zugriffskontrolle (RBAC). Die Einbindung von Modellen, die Rotation von Schlüsselmaterial sowie Kontingentanpassungen erfolgen über eine Benutzeroberfläche mit lückenlosem Audit-Log. Dadurch können Teams eigenständig agieren, ohne Tickets beim Platform-Team erstellen zu müssen. Subjekte sind Benutzer, Teams, virtuelle Konten oder Agenten; Ressourcen umfassen Provider-Konten, MCP-Server, Agenten, Cluster und Workspaces mit jeweils spezifischen Rollenstrukturen. SSO wird über OIDC oder SAML 2.0 inklusive SCIM unterstützt.

Präzise Kostenzuordnung und nachvollziehbare Budgets. Budget Limiting V2 ermöglicht mandanten- und teambezogene Budgets, die nach Subjekt, Modell, Provider-Konto oder Metadaten strukturiert werden können — inklusive eines reinen Warnmodus. Die Kostenverfolgung basiert auf einem Open-Source-Preiskatalog (github.com/truefoundry/models) mit regionalen und gestaffelten Tarifen; die Zuordnung erfolgt über X-TFY-METADATA. Diese Lücken selbst zu schließen, erfordert meist den größten Aufwand — siehe Kostenzuordnung und Team-Budgets.

Guardrails als integrierter Katalog statt reiner Schnittstelle. Neun integrierte Schutzmechanismen (Secrets, Code Safety, SQL-Sanitizer, Regex, Prompt Injection, PII, Content-Moderation, Cedar, OPA) sowie Anbindungen an 17 externe Anbieter stehen an vier Kontrollpunkten zur Verfügung: LLM-Eingabe, LLM-Ausgabe, MCP-Pre-Tool und MCP-Post-Tool.

Ein wichtiger Hinweis: Schutzfunktionen für Inhaltsmoderation, PII und Prompt Injection funktionieren nur, wenn TrueFoundry das Gateway hostet, nicht bei Betrieb auf eigener Infrastruktur. Alle übrigen Schutzfunktionen stehen in beiden Szenarien zur Verfügung.

MCP-Governance mit manuellem Freigabeprozess. Werkzeugspezifische Aktivierung/Deaktivierung, Lese- und Schreib-Annotationen sowie Human-in-the-Loop-Freigaben mit definierbaren Geltungsbereichen (namentlich, schreibend, global), Ablaufdaten für Berechtigungen und Benachrichtigungen via E-Mail, Slack, PagerDuty oder Teams. In der Dokumentation von Agent Router gibt es hierfür kein Äquivalent.

Integrierte Observability und einfache Bereitstellung. OTel-Traces und -Metriken über HTTP oder gRPC, Prometheus-Scraping im Self-Hosted-Betrieb sowie Metrik-APIs für Modelle, MCP, Guardrails, Caching und Routing. Der Betrieb ist als SaaS über mehr als 12 Regionen und drei Cloud-Anbieter möglich, ebenso wie als Self-Hosted-Variante in Ihrer VPC, On-Premises oder Air-Gapped — der Datenverkehr verbleibt in Ihrer Infrastruktur, ohne dass TrueFoundry im kritischen Pfad liegt.

Testen Sie es mit Ihrem eigenen Datenverkehr.

Leiten Sie einen Workload über das Gateway und analysieren Sie die Kosten- und Latenzwerte selbst.

Kostenlos starten

Direkter Vergleich

Eine Anmerkung: Die MCP-Autorisierung mittels CEL von Agent Router ist hervorragend umgesetzt. Die Apache-2.0-Lizenz ohne eingeschränkte Data-Plane-Funktionen bietet zudem eine dauerhafte Unabhängigkeit, die kein kommerzielles Produkt in dieser Form bieten kann.

Weiterführende Themen

• Was ist ein LLM Gateway — Die Produktkategorie erklärt
• Das beste AI Gateway 2026 — Marktübersicht im Vergleich
• Envoy Proxy Alternativen — Die zugrundeliegende Infrastruktur-Schicht
• Gesamtkosten (TCO) für GenAI-Infrastruktur — Wirtschaftlichkeitsanalyse von Eigenentwicklungen
• Was ist ein MCP Gateway — Spezifisches Routing für Tool-Datenverkehr

Fazit

Agent Router — das Projekt, das vielen noch als Envoy AI Gateway bekannt sein dürfte — gehört zu den ausgereiftesten Entwicklungen im Bereich der Open-Source-KI-Infrastruktur. Die Data Plane basiert auf Envoy. Die API ist stabil, was von den Maintainern schriftlich garantiert wird. Sechs Unternehmen sichern die Weiterentwicklung. Das MCP-Autorisierungsmodell übertrifft viele kommerzielle Angebote. Zudem ist der Open-Core-Ansatz transparent und fair gestaltet.

Der Grund, sich für eine Alternative zu entscheiden, liegt nicht in mangelnder Qualität, sondern in der Aufgabenverteilung. Agent Router stellt die Routing-Schicht bereit. Die Verwaltungskonsole, das Platform-RBAC, die präzise Kostenzuordnung pro Team, die übergreifenden Budgets, die Prompt-Protokollierung, die Freigabe-Workflows, der Guardrail-Katalog sowie die betriebliche Verantwortung im Fehlerfall verbleiben vollständig in Ihrer Hand — und machen den Großteil des Gesamtaufwands aus. Ein Platform-Team mit umfassender Kubernetes-Expertise und den entsprechenden Ressourcen kann diesen Stack erfolgreich eigenständig betreiben. Das ist eine valide Strategie, gegen die dieser Beitrag keineswegs argumentiert.

Falls Sie ein solches Projekt jedoch nicht von Grund auf neu aufbauen möchten, empfiehlt sich die Nutzung eines Gateways, bei dem diese Aufgaben bereits gelöst sind.

Routen Sie Ihren ersten Workload über TrueFoundry

Kostenlos starten