Kong hat Kong AI Gateway 2.0 allgemein verfügbar gemacht und markiert damit einen weiteren Schritt in der Umstellung vom einfachen LLM-Proxy hin zu einer breiteren Kontrollebene für Modelle, Agenten, Tools und KI-Ausgaben.
Die Version vom 1. September bringt mehrere Funktionen mit sich, die für Teams wichtig sind, die bereits Produktions-KI-Workloads ausführen: MCP-Server-Bündelung für kontrollierten Werkzeugzugriff, dynamisches Kostenmanagement, das verschiedene Modalitäten berücksichtigt, breitere Modell- und Anbieterabdeckung, identitätsbewusste KI-Richtlinien und native IAM-Authentifizierung für Amazon Bedrock AgentCore. Kong sagt außerdem, dass das Produkt jetzt in Kong Konnect ohne Beta-Aktivierung verfügbar ist.
Diese Kombination ist die Neuigkeit. In der Kategorie „KI-Gateway“ geht es nicht mehr nur darum, eine Anfrage im OpenAI-Stil entgegenzunehmen, sie an einen Anbieter weiterzuleiten und die Antwort zu protokollieren. Unternehmenskäufer möchten zunehmend, dass das Gateway entscheidet, wer welches Modell aufrufen kann, welche Tools ein Agent erreichen kann, wie Ausgaben gemessen werden sollen und wie diese Entscheidungen auf Identitätssysteme angewendet werden, die bereits vom Unternehmen verwendet werden.
Was sich in Kong AI Gateway 2.0 geändert hat
Die bemerkenswerteste Ergänzung ist die MCP-Server-Bündelung. MCP (Model Context Protocol) ist zu einer gängigen Methode geworden, um KI-Agenten Tools und Ressourcen zur Verfügung zu stellen. Durch die Bündelung von MCP-Servern auf der Gateway-Ebene haben Plattformteams die Möglichkeit, diese Tool-Verbindungen zu bündeln und zu steuern, anstatt dass jedes Anwendungsteam seine eigenen Agentenintegrationen verkabeln und überwachen muss.
Das ist eine sinnvolle Produktausrichtung. Wenn Agenten von Demos zu internen Arbeitsabläufen übergehen, besteht das Risiko weniger darin, dass ein Model eine Frage schlecht beantwortet, sondern eher darin, dass ein Model mit zu vielen Tools verbunden ist und zu wenig Aufsicht hat. Ein Gateway, das den MCP-Zugriff bündeln und steuern kann, kommt dem betrieblichen Problem näher: Welche Agenten können welche Systeme unter wessen Identität und mit welchen Richtliniengrenzen erreichen.
Kong fügte außerdem ein dynamisches, modalitätsbewusstes Kostenmanagement hinzu. Dies ist wichtig, da es sich bei der KI-Preisgestaltung nicht mehr um ein einzelnes Token-Messgerät handelt. Text-, Bild-, Audio-, Video-, Tool-Aufrufe, zwischengespeicherter Kontext und Argumentationsmodi können je nach Anbieter jeweils unterschiedliche wirtschaftliche Auswirkungen haben. Eine Kostenkontrollschicht, die die Modalität versteht, kann Teams genauere Grenzwerte und Routing-Regeln bieten als ein generischer Anfragezähler.
Die Version erweitert außerdem die Modell- und Anbieterabdeckung und fügt identitätsbewusste KI-Richtlinien hinzu. Kongs native IAM-Authentifizierung für Amazon Bedrock AgentCore ist besonders relevant, da Bedrock AgentCore zu einem der Orte wird, an denen Unternehmen Agenten ausführen und verwalten. Durch die Verbindung der Gateway-Richtlinie mit der Cloud-Identität verringert sich die Lücke zwischen KI-spezifischen Kontrollen und den Zugriffssystemen, die Unternehmen bereits prüfen.
Warum dies für Entwickler und Plattformteams wichtig ist
Für Entwickler besteht der praktische Effekt darin, dass das Gateway Teil der Anwendungsarchitektur wird und nicht nur ein Infrastruktur-Add-on. Ein Team, das einen internen Supportagenten, einen Codierungsassistenten oder einen Datenanalyse-Workflow aufbaut, benötigt jetzt möglicherweise Gateway-Regeln für Modellzugriff, Toolzugriff, Budgetschwellenwerte und Identitätsweitergabe, bevor die App in Produktion geht.
Das kann einige Einrichtungskosten verursachen, behebt aber auch einen echten Fehlermodus. Ohne eine gemeinsame Gateway-Ebene verteilen sich Modellauswahl, Anbieteranmeldeinformationen, Toolberechtigungen und Ausgabenkontrollen tendenziell auf Anwendungscode, CI-Geheimnisse, SDK-Wrapper und teamspezifische Dashboards. Diese Fragmentierung erschwert die Untersuchung von Vorfällen und die Ausführung von Modellmigrationen.
Die Veröffentlichung von Kong ist auch ein Signal für Anbieter, die OpenAI-kompatible API-Schichten und Multi-Modell-API-Produkte entwickeln. Allein die Kompatibilität wird zum entscheidenden Faktor. Kunden erwarten zunehmend Governance rund um die Anfrage: Richtliniendurchsetzung, Nutzungsanalyse, Zugriff auf Teamebene, Budgetkontrollen, Fallback-Routing und Modell-/Anbieter-Sichtbarkeit.
Für Model Gate-Benutzer ist die Verbindung direkt. Einheitliche Abrechnung, API-Schlüsselverwaltung, Nutzungsanalysen und Teamkontrollen werden wertvoller, wenn der Modellzugriff nur ein Teil des Workflows ist. Da Agenten über Schnittstellen im MCP-Stil Zugriff auf Tools erhalten, müssen Gateways nicht nur darstellen, welches Modell aufgerufen wurde, sondern auch, welches Team, welcher Schlüssel, welches Toolpaket und welcher Richtlinienkontext beteiligt waren.
Der Wettbewerbsmaßstab ändert sich
Kong ist in dieser Richtung nicht allein. Jüngste Entwicklungen auf dem Markt zeigen, dass Anbieter von KI-Infrastrukturen vor demselben größeren Problem stehen: Unternehmens-KI benötigt einen geregelten Pfad zwischen Benutzern, Modellen, Agenten, Tools und Ausgaben. Gateway-Produkte werden weniger danach beurteilt, ob sie Anfrageformate normalisieren können, sondern eher danach, ob sie Produktionskontrollen unterstützen können.
Das erhöht den Druck auf Käufer, schärfere Fragen zu stellen. Versteht das Gateway anbieterspezifische Preise und Modalitäten? Können Administratoren Richtlinien nach Team oder Identität festlegen? Kann es anbieterübergreifend weitergeleitet werden, ohne dass die Prüfbarkeit verloren geht?Kann es Agententools steuern, nicht nur Modellendpunkte? Können Nutzungs- und Kostendaten auf eine Weise offengelegt werden, die Finanzen, Sicherheit und Technik gemeinsam nutzen können?
Diese Fragen sind nicht mehr theoretisch. Langkontextmodelle, Agenten-Tool-Aufrufe und multimodale Arbeitslasten können Kostenprofile schnell ändern. Ein Workflow, der beim Testen billig aussieht, kann teuer werden, wenn wiederholter Kontext, Bildeingaben oder Tool-intensive Agentenschleifen in die Produktion gelangen. Ein Gateway, das diese Muster nicht unterscheiden kann, zentralisiert möglicherweise immer noch den Zugriff, gibt den Betreibern jedoch nicht genügend Kontrolle.
Was bleibt ungewiss
Die Ankündigung legt die allgemeine Verfügbarkeit fest und nennt die wichtigsten Funktionen, aber die tatsächliche Akzeptanz wird von den Implementierungsdetails abhängen: wie Teams MCP-Bundles konfigurieren, wie granular die identitätsbewussten Richtlinien sind, wie sich Kostenkontrollen bei gemischten Anbietern verhalten und wie viel betriebliche Transparenz Kunden in der Praxis erhalten.
Es ist auch noch zu früh, um zu wissen, ob Unternehmen Agenten standardisieren werden Governance in einem einzigen KI-Gateway oder Aufteilung der Verantwortung auf Cloud-Plattformen, Sicherheitstools, Entwicklerplattformen und Observability-Anbieter. AWS, Hosting-Plattformen, IDE-Anbieter und eigenständige Gateway-Anbieter versuchen alle, Teile derselben Steueroberfläche zu besitzen.
Dennoch ist die Richtung klar. Kong AI Gateway 2.0 behandelt den KI-Verkehr als verwaltetes Unternehmenssystem und nicht als Strom von Modellaufrufen. Für Entwickler und Unternehmen, die auf Modell-APIs aufbauen, bedeutet das, dass Gateway-Entscheidungen zu Architekturentscheidungen werden: Sie wirken sich auf Kosten, Sicherheit, Modellauswahl, Tool-Zugriff und die Zuverlässigkeit von Agent-Workflows aus.