Architektur von AI-Gateways: Proxying agentische Workflows und MCP-Verkehr

Traditionelle API-Gateways versagen, wenn autonome Agenten gleichzeitig 50 kaskadierende Tool-Aufrufe initiieren. Hier erfahren Sie, wie man AI-native Reverse Proxies einsetzt, um Reasoning-Ketten zu zwischenspeichern, MCP-Verkehr zu routen und rogue Agents zu drosseln — und warum die Sicherheitslage deutlich komplexer geworden ist, als es das ursprüngliche Gateway-Konzept vermuten ließ.

---

Bis 2026 hat sich die AI-Landschaft eindeutig von statischen Prompt-Response-Chatbots zu autonomen, multi-step agentischen Workflows gewandelt. Große Sprachmodelle agieren nun als Reasoning-Engines, die eigenständig Datenbanken abfragen, externe APIs triggern und komplexen Code ausführen. Dieser architektonische Sprung hat einen kritischen Schwachpunkt in der traditionellen Unternehmensnetzwerkinfrastruktur offenbart: Legacy API-Gateways wurden für linearen, vorhersehbaren Request-and-Response-REST-Verkehr im 1:1-Verhältnis entwickelt. Sie sind völlig ungeeignet, um die unregelmäßigen, volumenstarken, token-lastigen Datenströme zu bewältigen, die von autonomen AI-Agenten erzeugt werden.

Wenn eine einzelne Nutzeranfrage Dutzende von kaskadierenden Modellaufrufen und Tool-Invocations auslösen kann, braucht es eine spezialisierte Zwischeninstanz am Netzwerkperimeter. Hier kommt der AI-Gateway-Proxy ins Spiel: ein AI-nativer Reverse Proxy, der am Netzwerkrand positioniert ist, um semantisches Caching, intelligente LLM-Verkehrssteuerung und das wachsende Volumen des Model Context Protocol (MCP) zu verwalten — und gleichzeitig eine völlig neue Klasse von Supply-Chain-Angriffen abzuwehren, die von legacy Gateways nie vorgesehen waren.

---

Der Auslöser für den Wandel: Das Model Context Protocol

Um zu verstehen, warum AI-Gateways unverzichtbar geworden sind, muss man den Verkehrsfluss agentischer Daten im Jahr 2026 kennen. Der Haupttreiber ist MCP.

Anthropic führte MCP am 25. November 2024 ein, veröffentlichte die Spezifikation (Version 2024-11-05) zusammen mit Python- und TypeScript-SDKs. Das Protokoll löste ein grundlegendes Skalierungsproblem: Vor MCP mussten Entwickler für jedes Tool, auf das ein LLM zugreifen sollte, spezielle, vendor-spezifische Konnektoren schreiben. MCP schuf eine universelle, offene Schnittstelle, die AI-Systeme nahtlos mit externen Datenquellen verbindet — in der Community-Presse auch als “USB-C für AI” bezeichnet.

Die Akzeptanzkurve war steil. Innerhalb von drei Monaten entstanden über 1.000 MCP-Server, die von der Community gebaut wurden. Bis April 2025 stiegen die Downloads auf über 8 Millionen pro Monat. Ende 2025 waren mehr als 5.800 MCP-Server und 300+ MCP-Clients verfügbar, mit Unterstützung durch SAP, Oracle und Docker neben den ursprünglichen Unterstützern Google, OpenAI und Microsoft.

Mit der Verbreitung kam die Governance. Im Dezember 2025 spendete Anthropic MCP an die Agentic AI Foundation (AAIF), eine von der Linux Foundation geführte Stiftung, die von Anthropic, Block und OpenAI mitgegründet wurde. Damit wurde MCP zu einer vendor-neutralen Infrastruktur, nicht nur einem vordefinierten Protokoll. Zum einjährigen Jubiläum wurde die Spezifikation um wichtige Funktionen erweitert: asynchrone Workflows, URL-basierte Abfragen für sichere OAuth-Flows und MCP-Server-seitiges Sampling mit Tools — so können MCP-Server ihre eigenen agentischen Schleifen innerhalb des Token-Budgets des Nutzers laufen lassen, ohne Zugangsdaten offenzulegen.

Das Transportlayer des Protokolls nutzt JSON-RPC 2.0 über zwei Kanäle: Standard Input/Output (stdio) für lokale Ausführung sowie Server-Sent Events (SSE) oder HTTP-Stream für entfernte Verbindungen. Die Architektur ist explizit in drei Rollen entkoppelt:

• MCP Host — die Anwendung, die das LLM ausführt (z.B. IDE, Konversationsschnittstelle oder automatisierter Backend-Service).
• MCP Client — ein Router im Host, der LLM-Anfragen in das MCP-Wire-Format übersetzt.
• MCP Server — der externe Dienst, der Fähigkeiten (Tools, Ressourcen, Prompts) für das LLM bereitstellt.

Durch MCP kann ein autonomer Agent jetzt dynamisch Enterprise-Systeme entdecken und verbinden. Diese einfache Konnektivität ist ein zweischneidiges Schwert: Sie macht komplexe Multi-System-Operationen routine, birgt aber auch das Risiko, dass ein einzelner Prompt in einen riesigen Baum interdependenter API-Aufrufe ausufert — und so eine erweiterte Angriffsfläche schafft.

---

Die Anatomie eines agentischen Zusammenbruchs: Eine IIoT-Fallstudie

Um die Belastung durch agentische Workflows auf die Netzwerkinfrastruktur zu visualisieren, betrachten wir eine Unternehmens-Implementierung, die auf industrielles Mirroring und das Tunneln lokaler Sensoren zu Cloud-basierten digitalen Zwillingen setzt.

Ein spezialisierter autonomer AI-Agent überwacht ein Industrial Internet of Things (IIoT)-Sensorennetzwerk. Der Agent hört auf einen kontinuierlichen Telemetrie-Stream, der direkt vom Fabrikboden getunnelt wird. Bei einer Vibrationsanomalie schlussfolgert das LLM, dass es mehr Kontext braucht — und führt ohne menschliches Eingreifen die folgenden Kaskaden via MCP-Tool-Calls aus:

1. Abfrage einer Zeitreihendatenbank für 72 Stunden historische Sensordaten.
2. Invokation eines leichten Zusammenfassungs-LLMs zur Analyse der Wartungsprotokolle.
3. Triggern eines Physik-Simulations-Tools via MCP-Server.
4. Aufruf einer NVIDIA Omniverse-Renderpipeline, um den digitalen Zwilling der betroffenen Maschine in Echtzeit zu aktualisieren und zu visualisieren.
5. Entwurf und Versand eines Alarm-Payloads an einen Unternehmens-Slack-Kanal.

In Bruchteilen einer Sekunde hat ein einzelner Anomalie-Trigger über 50 API-Aufrufe, mehrere LLM-Invocations mit Hunderten von Tausenden Tokens sowie eine schwere Render-Task ausgelöst.

Verläuft dieser Verkehr durch ein herkömmliches API-Gateway, ist das System blind. Ein Legacy-Gateway erkennt HTTP-Verkehr, versteht aber Tokens nicht. Es kann zwischen einem einfachen Datenbank-Lesezugriff und einem rechenintensiven LLM-Reasoning-Schritt nicht unterscheiden. Das führt zu Rate-Limit-Exhaustion, Billing-Spikes durch redundante Tool-Calls und Pipeline-Ausfällen, weil der Agent bei Flooding-Anfragen von den LLM-Anbietern blockiert wird.

---

Das AI-Gateway-Proxy-Design

Ein AI-Gateway-Proxy ist eine Middleware-Schicht, die den AI-Verkehr steuert. Als Reverse Proxy zwischen MCP Host und den verschiedenen Backend-LLMs sowie MCP-Servern sitzt er zwischen den Komponenten, analysiert und verwaltet jeden Schritt des agentischen Workflows.

Die aktuelle Generation AI-nativer Gateways — darunter Bifrost (von Maxim AI, Apache 2.0, in Go, ca. 11 µs Overhead bei 5k RPS), LiteLLM (MIT, Python, 33.000+ GitHub-Sterne), Portkey (vollständig Open Source seit März 2026), Kong AI Gateway (Version 3.14) und das Linux Foundation-Projekt agentgateway — sind alle im Sprachgebrauch von AI bewandert. Sie tracken Nutzung in Tokens statt Bytes, inspizieren Prompt-Payloads und setzen Policies basierend auf semantischer Absicht um, nicht nur auf URL-Pfade.

Die architektonische Wahl zwischen diesen Gateways hat konkrete Performance-Auswirkungen. Python-basierte Gateways wie LiteLLM verursachen etwa 8–50 ms Overhead pro Request, was bei moderatem Durchsatz akzeptabel ist, aber bei anhaltender Last über 250–300 RPS pro Instanz zu Problemen führt. Go-basierte Gateways wie Bifrost weisen einen Overhead von ca. 11 µs bei 5.000 RPS auf — ein Unterschied von mehreren Größenordnungen, der in latenzkritischen Szenarien wie dem IIoT oben entscheidend ist.

Durch den Einsatz eines AI-Gateways am Netzwerkrand gewinnen Unternehmen Kontrolle durch drei Kernpfeiler: Semantic Caching, Intelligent Routing und Rogue Agent Throttling. Ein vierter Pfeiler — Sicherheit gegen MCP-spezifische Angriffsklassen — ist ebenso wichtig und wird im Folgenden detailliert behandelt.

---

Pfeiler 1: Semantisches Caching am Netzwerkrand

In agentischen Workflows treten LLMs häufig in kognitive Schleifen ein, in denen sie wiederholt dieselben Fragen stellen oder dieselben Daten abfragen, während sie ein Multi-Schritt-Problem lösen. Das wiederholte Anfragen an denselben Anbieter kosten Rechenleistung und Geld — und verursachen unerwünschte Latenz in Echtzeitsystemen. Eine Fallstudie zeigte, dass semantisches Caching die LLM-Kosten in einem Kundensupport-System um 69 % senkte.

Semantisches Caching löst dieses Problem, indem es identische oder logisch ähnliche Agenten-Anfragen direkt aus dem Cache des Gateways bedient. Anders als herkömmliches Caching — das eine perfekte Byte-für-Byte-Übereinstimmung erfordert — versteht semantisches Caching die Bedeutung eines Prompts.

Moderne AI-Gateways setzen eine duale Caching-Architektur ein:

Schicht 1 — Exakte Hash-Übereinstimmung. Das Gateway hash den eingehenden Prompt. Wenn der Agent fragt: “Was ist die aktuelle Temperatur von Turbine 4?”, liefert das Gateway sofort die zwischengespeicherte Antwort ohne Overhead.

Schicht 2 — Vektorähnlichkeitssuche. Wenn der Agent den gleichen Wunsch leicht umformuliert — “Gib mir die Temperatur von Turbine 4” — generiert das Gateway eine Einbettung des neuen Prompts und vergleicht sie mit zuvor gecachten Anfragen in einem Hochgeschwindigkeits-Vektor-Store (Redis, Qdrant oder Milvus). Wenn der Ähnlichkeits-Score einen vordefinierten Schwellenwert (typischerweise 0,85 oder höher) überschreitet, umgeht das Gateway das LLM vollständig und liefert die zwischengespeicherte Antwort.

LiteLLM unterstützt die Cache-Modi redis-semantic und qdrant-semantic. Portkey bietet eine der ausgereiftesten Implementierungen für semantisches Caching im Managed-Gateway-Bereich. Cloudflare AI Gateway deckt derzeit exakte Übereinstimmung im globalen Edge ab, mit konfigurierbarer Cache-TTL via HTTP-Header; vollständiges semantisches (Vektor-Ähnlichkeits-)Caching ist im Mid-2026-Stand noch eine Lücke im Managed-Angebot.

Für hohen MCP-Verkehr ist semantisches Caching der Unterschied zwischen einer funktionierenden Echtzeit-Anwendung und einem unerschwinglichen Prototyp.

---

Pfeiler 2: LLM-Verkehrssteuerung und Fallbacks

Autonome Agenten sind nicht an ein einzelnes Modell gebunden. Eine reife agentische Architektur nutzt ein Ensemble verschiedener LLMs, die für spezifische Teilaufgaben geeignet sind. Diese Routing-Logik im Agenten selbst ist fragil: Fällt ein Anbieter aus, scheitert der Agent.

Ein AI-Gateway abstrahiert diese Komplexität. Der Agent sendet alle Anfragen an eine zentrale, einheitliche Schnittstelle (z.B. eine OpenAI-kompatible API), und das Gateway trifft dynamische Routing-Entscheidungen im Millisekundenbereich.

Dynamisches Modell-Routing. Das Gateway inspiziert den Payload und leitet ihn an das optimale Ziel weiter. Einfache Klassifikationsaufgaben — z.B. die Priorisierung eines Sensorsignals — werden an schnelle, kostengünstige Modelle weitergeleitet. Komplexe Reasoning- oder Code-Generierungsaufgaben an schwergewichtige Modelle. Version 3.10 und später von Kong AI Gateway implementieren semantisches Routing via das AI Proxy Advanced-Plugin, das Anfragen basierend auf der semantischen Ähnlichkeit zwischen Prompt und einer konfigurierten Beschreibung der Modell-Spezialisierung verteilt. Portkey unterstützt Routing über 200+ LLM-Anbieter aus einer einzigen Steuerzentrale.

Resilienz und Fallback-Ketten. Ausfälle bei LLM-APIs und Rate-Limiting sind Realität — OpenAI hatte 2025 drei größere Ausfälle; Anthropic erlebte Rate-Limiting-Phasen während der Spitzenzeiten. AI-Gateways überwachen kontinuierlich die Gesundheit und setzen automatische Fallback-Ketten ein. Bei Timeout oder 429 Too Many Requests leitet das Gateway transparent an einen sekundären Anbieter weiter. Der Agent merkt nichts von der Störung; er erhält die Daten und setzt seinen Workflow fort.

Agent-zu-Agent (A2A) Verkehr. Bis April 2026 hatte sich das Routing-Problem auf den gesamten Agentenverkehr ausgeweitet. Version 3.14 von Kong führte den Kong Agent Gateway ein, der erstmals alle drei Verkehrstypen in einer einheitlichen Steuerzentrale verwaltet: LLM-Calls, MCP-Tool-Calls und A2A-Kommunikation via das A2A-Protokoll (ursprünglich von Google im April 2024 eingeführt). Gartner’s Emerging Tech Adoption Radar 2026 merkt an, dass “mit zunehmender Verbreitung von Agenten-zu-Agenten-Interaktionen AI-Gateways die Rückgrat für sichere und skalierbare AI-Implementierungen werden.” Das Linux Foundation-Projekt agentgateway — unterstützt von Microsoft, AWS, Cisco, Adobe, Huawei und Apple — verfolgt dasselbe Ziel, basiert auf Open-Source und Policy-Engine-Design mit Open Policy Agent (OPA) für feingranulare Autorisierung.

---

Pfeiler 3: Rogue Agents drosseln und Sicherheitsregeln durchsetzen

Das gefährlichste an agentischen Workflows ist die Gefahr, dass eine autonome Schleife außer Kontrolle gerät. Ein rogue Agent entsteht, wenn ein LLM eine Fehlermeldung missversteht, eine Halluzination erzeugt und wiederholt MCP-Tools in einer schnellen Schleife auslöst. In einer unkontrollierten Umgebung kann ein rogue Agent Tausende teure API-Calls in Minuten auslösen oder destruktive Operationen an Unternehmensdatenbanken durchführen.

AI-Gateways dienen hier als Sicherheitsnetz durch granulare, token-abhängige Steuerung.

Token-basierte Rate-Limiting. Standard-Request-per-Minute-Limits sind nutzlos, wenn eine einzelne Anfrage zwischen 100 und 100.000 Tokens verbraucht. AI-Gateways setzen Tokens-Per-Minute (TPM)-Limits pro virtuellen Schlüssel, Agenten-Persönlichkeit oder Projekt durch. Bifrost implementiert eine hierarchische Budgetverwaltung: Kunde → Team → Virtueller Schlüssel → Anbieter-Konfiguration, mit Spend-Limits auf jeder Ebene. Wenn der IIoT-Diagnose-Agent plötzlich den Token-Verbrauch steigert, drosselt das Gateway die Pipeline, bevor das Unternehmensbudget aufgebraucht ist.

Zugriffssteuerung für MCP-Tools. Gateways setzen Role-Based Access Control (RBAC) auf Tool-Ebene um. Während ein Agent möglicherweise Zugriff auf viele MCP-Server hat, erzwingt das Gateway das Prinzip der minimalen Privilegien — SELECT-Anfragen zum Lesen von Sensordaten sind erlaubt, DROP- oder UPDATE-Befehle an Produktionsdatenbanken werden aktiv blockiert. Version 3.12 von Kong (Oktober 2025) fügte MCP-ACLs hinzu und generiert MCP-Server automatisch aus bestehenden REST-API-Definitionen, um interne Dienste schnell für Agenten freizugeben, mit zentralem OAuth.

Bifrosts Code Mode ist eine bemerkenswerte Optimierung auf dieser Ebene: Es reduziert Tool-Definitionen auf essentielle Schemata, bevor sie in den LLM-Kontext eingebunden werden, und senkt den Token-Verbrauch pro agentischer Runde um mehr als 50 %, was den Radius eines möglichen Runaway-Loops direkt verkleinert.

---

Pfeiler 4: Sicherheit gegen MCP-spezifische Angriffsklassen

Dieser Abschnitt existierte im ursprünglichen Gateway-Konzept nicht. Er ist jetzt notwendig, weil die MCP-Angriffsfläche in den letzten 18 Monaten systematisch kartiert wurde und die gefundenen Risiken ernst sind.

Tool-Poisoning. MCP-Server können bösartige Anweisungen direkt in Tool-Metadaten einbetten — in JSON-Schema-Feldern, Tool-Beschreibungen und strukturierten Metadaten, die beim Booten geladen werden. Da das Modell diese als Anweisungen liest, kann ein Angreifer, der einen MCP-Server kontrolliert oder kompromittiert, Direktiven in die Deskriptoren schreiben, die vom Agenten an das LLM weitergegeben werden, ohne dass eine Sanitisierung erfolgt. Das wurde als eigenständige Klasse in CVE-2025-54136 (MCPoison) und CVE-2025-54135 (CurXecute) dokumentiert, beide 2025 veröffentlicht. OWASP klassifiziert diese als LLM01 (Prompt-Injection) und LLM05 (unsachgemäße Ausgabenbehandlung).

Das Rug-Pull-Muster. MCP-Tool-Definitionen können sich nach der Installation verändern. Ein bei der Deployment als sicher eingestufter Tool kann sich still und heimlich neu definieren — API-Schlüssel umleiten, Befehle ändern oder Calls an vertrauenswürdige Tools abfangen — ohne dass eine oberflächliche Überwachung dies erkennt. Simon Willison dokumentierte dieses Muster im April 2025 als eines der hinterhältigsten strukturellen Risiken im Protokoll.

Supply Chain-Komprimierung via Registries. CVE-2025-6514, eine kritische OS-Command-Injection in mcp-remote (CVSS 9.6), zeigte die Supply-Chain-Gefahr. Die Schwachstelle — entdeckt von JFrog Security Research, behoben in Version 0.1.16 — erlaubte einem bösartigen MCP-Server, eine manipulierte authorization_endpoint direkt an die Shell zu übergeben, was Remote Code Execution ermöglichte. Über 437.000 Downloads und Integration in Cloudflare, Hugging Face und Auth0 machten eine unpatched Version effektiv zu einer Supply-Chain-Backdoor. CVE-2025-49596 (MCP Inspector) war eine separate CSRF-Schwachstelle, die RCE durch eine manipulierte Webseite erlaubte.

Cross-Server Cross-Tool-Poisoning. Empirische Untersuchungen an sieben MCP-Clients zeigten, dass bei mehreren verbundenen Servern ein bösartiger Server Anrufe an einen vertrauenswürdigen Server überschreiben oder abfangen kann. Ein Cursor-Agent mit privilegiertem service-role bei Supabase verarbeitete Support-Tickets mit eingebetteten SQL, was Integrations-Tokens in einem öffentlichen Thread leakte. Unzureichende statische Validierung und unsichtbare Parameterbehandlung wurden als Ursachen identifiziert.

Was das Gateway tut. Ein AI-Gateway fungiert als Schnittstelle, an der ein Team eine einzige Abwehrmaßnahme gleichzeitig auf Tausende von Agenten ausrollen kann. Durch die Pflege eines validierten, fixierten Registers genehmigter MCP-Server-Definitionen und das Abfangen dynamischer Tool-Registrierungen — der risikoreichsten Registrierungsart — begrenzt es die Schadensausbreitung, selbst wenn ein Client verwundbar ist. Es ersetzt keine Client-Patches oder Vendor-Hygiene, ist aber die Schicht, in der Prompt-Injection-Scanning, Tool-Definition-Validierung und Verhaltensanalyse zentral angewandt werden können, bevor Tool-Calls an nachgelagerte Systeme gelangen. Isolierte Ausführung (z.B. MCP-Clients und -Server in Docker-Containern) in Kombination mit Gateway-gestützter Least Privilege-Politik ist die empfohlene Defense-in-Depth-Basis nach Cloud Security Alliance.

---

Beobachtbarkeit: Die Reasoning-Kette rekonstruieren

Fehlerhafte agentische Workflows zu debuggen ist äußerst schwierig, weil die Logik nicht-deterministisch ist. Herkömmliche Logs zeigen nur, dass HTTP-Anfragen stattgefunden haben. Sie erklären aber nicht warum der Agent die Entscheidungen traf.

OpenTelemetry ist zum De-facto-Standard für AI-Observability geworden. Die GenAI Special Interest Group (GenAI SIG), gegründet im April 2024, hat die semantischen Konventionen schrittweise von einfachen LLM-Call-Trace bis hin zu vollständiger agentischer Abdeckung erweitert. Die Version 1.39 der OTel-Semantik-Konventionen führte MCP-spezifische Span-Attribute ein — mcp.session.id, mcp.method.name, mcp.protocol.version, gen_ai.tool.name — die Kontextinformationen tragen, die die generischen RPC-Konventionen vermissen lassen. Damit wurde die bisher dokumentierte Lücke geschlossen, bei der der Agent Trace A und der MCP-Server Trace B ohne Verbindung produzierten.

Die gen_ai.*-Semantik-Konventionen standardisieren jetzt die Erfassung von Modellattributen, Token-Nutzung, Latenz, Tool-Invocations und agentischem Reasoning in der gesamten Call-Tree. Datadog’s LLM Observability Produkt fügte native Unterstützung für OTel GenAI SemConv (Version 1.37) im Dezember 2025 hinzu. New Relic startete MCP-Monitoring 2025. Mehrere Identitätsanbieter — Auth0, Okta, WorkOS — bieten inzwischen spezielle Enterprise-Authentifizierungsintegrationen für MCP-Deployments.

AI-Gateways, die Telemetrie via OTel exportieren, ermöglichen es Entwicklern, genau nachzuvollziehen, warum ein Agent eine bestimmte Tool-Call-Sequenz gewählt hat, was aus dem Cache geliefert wurde, welcher Anbieter im Fallback genutzt wurde und wo der Workflow ins Stocken geriet — die vollständige Reasoning-Kette statt einer Sammlung unverbundener HTTP-Logs.

---

Gateway-Auswahl in der Praxis

Kein einzelnes Gateway ist für alle Deployment-Profile optimal:

Gateway	Architektur	Beste Einsatzmöglichkeiten
Bifrost (Maxim AI)	Go, Apache 2.0, ca. 11 µs Overhead bei 5k RPS	Latenzempfindliche, regulierte Branchen, VPC / luftgetrennt
LiteLLM	Python, MIT, 100+ Anbieter, 33.000+ GitHub-Sterne	Breite Anbieterabdeckung; Prototyping bis moderater Durchsatz
Portkey	Managed SaaS (vollständiges OSS seit März 2026), 200+ Anbieter	Teams, die Managed-Operationen, ausgereifte PII-Reduktion + Guardrails wünschen
Kong AI Gateway 3.14	Nginx-Core + Plugins; Enterprise-Preise ca. $500–2.500/Monat	Organisationen, die bereits Kong nutzen; LLM + MCP + A2A in einer Steuerzentrale
Cloudflare AI Gateway	Vollständig gemanagt, globaler Edge	Keine Infrastruktur, exaktes Match-Caching, 350+ Modelle
agentgateway (Linux Foundation)	Open Source, OPA-Policy-Engine, Multi-Vendor	Governance-orientiert, offene Standards für A2A und MCP; Community-basiert

Für Teams mit unter 250 RPS pro Instanz und breiter Anbieterauswahl ist LiteLLM eine praktische Einstiegslösung. Für hochvolumige Produktionsworkloads, bei denen jede Millisekunde Overhead den Gesamtdurchsatz beeinflusst, sind Go-basierte oder Managed-Edge-Lösungen die richtige Wahl. Für Organisationen, die bereits Kong im Einsatz haben und eine zentrale Steuerung für LLM, MCP und A2A benötigen, deckt Kong Agent Gateway (GA in Version 3.14, April 2026) den gesamten Datenpfad ab, ohne neue Infrastruktur zu schaffen.

---

Fazit: Das neue Perimeter

Da MCP über 97 Millionen SDK-Downloads pro Monat erreicht und Agenten in kritische Umgebungen eingebettet werden — von Finanzprognosen bis hin zu Echtzeit-Industriesensor-Tunneling — muss sich das Netzwerkperimeter weiterentwickeln.

Das traditionelle API-Gateway ist ein Artefakt der Web 2.0-Ära. Es fehlt an Token-Controllen, semantischem Caching und — entscheidend — an Verständnis für die neuen Angriffsklassen, die MCP eingeführt hat. Der Einsatz autonomer Agenten ohne AI-native Reverse Proxy ist vergleichbar mit dem Anschluss eines Hochdruck-Wasserstrahls an eine Gartensprinkleranlage: Die Infrastruktur wird versagen, und zwar auf eine Weise, die erst durch umfassendes Monitoring sichtbar wird, wenn der Schaden bereits angerichtet ist.

Durch den Einsatz dedizierter AI-Gateways erhalten Organisationen vier zentrale Vorteile, die herkömmliche Infrastruktur nicht bieten kann: semantisches Caching für stabile Echtzeit-Pipelines, intelligentes Routing für hohe Verfügbarkeit trotz volatiler LLM-Anbieterlandschaft, strikte Token-Drosselung zur Vermeidung von Kostenexplosionen sowie eine zentrale Interceptionsschicht, die Tool-Definitionen validiert und Verhaltensabweichungen erkennt, bevor MCP-Calls an nachgelagerte Systeme gelangen.

Im Jahr 2026 ist das AI-Gateway kein optionales Add-on mehr, sondern das grundlegende Steuerungssystem für das agentische Unternehmen — und zunehmend die wichtigste Verteidigungslinie gegen Angriffsklassen, die vor 18 Monaten noch unbekannt waren.

---

Changelog

Faktische Korrekturen und Ergänzungen zum Originalentwurf:

• MCP-Governance-Körperschaft korrigiert. Der Entwurf sagte, MCP sei an die “Agentic AI Foundation” gespendet worden. Das ist korrekt, aber unvollständig: Die AAIF ist ein von der Linux Foundation geführter Fonds, der von Anthropic, Block und OpenAI mitgegründet wurde. Die Spende erfolgte im Dezember 2025, nicht zu einem früheren Zeitpunkt.
• MCP-Startdatum bestätigt. 25. November 2024; Spezifikationsversion 2024-11-05. Bestätigt durch Anthropic-Veröffentlichungsdokumentation.
• MCP-Transport ergänzt. Der Entwurf erwähnte den HTTP-Stream-Transport nicht; dieser wurde im Jubiläums-Update im November 2025 hinzugefügt, neben SSE und stdio. Das Update führte auch aufgabenbasierte Workflows, URL-basierte Abfragen für OAuth und MCP-Server-seitiges Sampling ein — alles relevante Themen für den Sicherheitsabschnitt.
• Adoptionskennzahlen belegt. “Über 1.000 MCP-Server in der Community” war der Stand Anfang 2025; die aktuelle Zahl ist 5.800+ Server, 97 Mio+ SDK-Downloads monatlich und 300+ Clients.
• Gateways-Landschaft korrigiert. Der Entwurf nannte nur “Bifrost, Cequence oder Kong AI Gateway.” Cequence ist eine API-Sicherheitsplattform, kein AI-Gateway — entfernt. Ergänzt wurden LiteLLM, Portkey, Cloudflare AI Gateway und das Linux Foundation-Projekt agentgateway.
• Latency-Zahlen für Python- vs. Go-Gateways ergänzt. LiteLLM: ca. 8–50 ms Overhead. Bifrost: ca. 11 µs bei 5.000 RPS. Diese Zahlen stammen aus veröffentlichten Benchmarks (Maxim AI, März 2026) und sind relevant für das IIoT-Realtime-Szenario.
• Versionsbezüge bei Modellen aktualisiert. Die Nennung von “Claude 3.7 Haiku” und “Claude 3.5 Sonnet” wurde durch neutralere Beschreibungen ersetzt.
• Kong AI Gateway Version korrigiert. Der Entwurf deutete an, Kong’s Gateway sei aktuell; die tatsächliche Version ist 3.8 (Dezember 2025, semantisches Caching + MCP-ACLs), 3.10 (April 2025, automatisiertes RAG + tokenbasiertes Load Balancing), 3.12 (Oktober 2025, MCP-ACLs + Claude Code-Unterstützung), 3.14 (April 2026, Kong Agent Gateway mit A2A-Unterstützung, GA).
• Preise für Kong ergänzt. Kong Konnect: ca. $500–2.500/Monat; Enterprise auf Anfrage.
• A2A-Protokoll ergänzt. Das A2A-Protokoll, von Google im April 2024 eingeführt und jetzt in Kong 3.14 sowie im agentgateway implementiert, ist eine bedeutende Entwicklung, die im ursprünglichen Entwurf fehlte.
• Vollständiger Sicherheits-Pfeiler (Pillar 4) ergänzt. Der ursprüngliche Entwurf enthielt keine Diskussion zu MCP-spezifischen Sicherheitslücken. Hinzugefügt wurden: Tool-Poisoning (CVE-2025-54136, CVE-2025-54135), Rug-Pull-Muster, Supply Chain via CVE-2025-6514 in mcp-remote (CVSS 9.6) und der Support bei Cursor/Support-Tickets (Mitte 2025). Quellen: Elastic Security Labs, JFrog, authzed.com, arXiv 2603.22489 (März 2026), practical-devsecops.com, TrueFoundry.
• OpenTelemetry-Abschnitt erweitert. Das ursprüngliche Dokument erwähnte “OpenTelemetry” ohne Details. Ergänzt: Gründung der GenAI SIG (April 2024), MCP-spezifische Semantik-Konventionen in OTel v1.39 (mcp.session.id, mcp.method.name, mcp.protocol.version, gen_ai.tool.name), Unterstützung durch Datadog (v1.37, Dezember 2025) und New Relic, sowie die Problematik der Trace A / Trace B-Disconnection, die mit v1.39 behoben wurde.
• Schwellenwert für semantisches Caching belegt. Der in der ursprünglichen Version genannte Wert von 0,85 für die Cosinus-Ähnlichkeit entspricht den veröffentlichten Konfigurationen für Redis-semantic und Qdrant-semantic in LiteLLM.
• Kosteneinsparung durch semantisches Caching erwähnt. 69 % Kostensenkung in einem Kundensupport-Deployment (MindStudio, Februar 2026).
• Bifrost Code Mode ergänzt. Reduziert Tool-Definitionen auf essentielle Schemata, senkt Token-Verbrauch pro Runde um 50+ %, was den Radius eines Runaway-Loops deutlich verringert.