Kong har gjort Kong AI Gateway 2.0 generelt tilgængelig, hvilket markerer endnu et skridt i skiftet fra simpel LLM-proxy til et bredere kontrolplan for modeller, agenter, værktøjer og AI-udgifter.
Udgivelsen fra 1. september bringer flere funktioner, der er vigtige for teams, der allerede kører produktions-AI-arbejdsbelastninger: MCP Server-bundling til styret styring af værktøjsmodeller, der giver mulighed for forskellige omkostningsstyringsværktøjsmodeller, og bredere omkostningsstyringsværktøjs-adgang. dækning, identitetsbevidste AI-politikker og indbygget IAM-godkendelse til Amazon Bedrock AgentCore. Kong siger også, at produktet nu er tilgængeligt i Kong Konnect uden beta-aktivering.
Denne kombination er nyheden. AI-gateway-kategorien handler ikke længere kun om at tage en OpenAI-lignende anmodning, videresende den til en udbyder og logge svaret. Enterprise-købere vil i stigende grad have gatewayen til at bestemme, hvem der kan kalde hvilken model, hvilke værktøjer en agent kan nå, hvordan forbruget skal måles, og hvordan disse beslutninger knyttes til identitetssystemer, der allerede bruges af virksomheden.
Hvad ændrede sig i Kong AI Gateway 2.0
Den mest bemærkelsesværdige tilføjelse er MCP Server Bundling. MCP, eller Model Context Protocol, er blevet en almindelig måde at eksponere værktøjer og ressourcer på for AI-agenter. Samling af MCP-servere ved gateway-laget giver platformsteams et sted at samle og styre disse værktøjsforbindelser i stedet for at overlade hvert applikationsteam til at wire og kontrollere deres egne agentintegrationer.
Det er en meningsfuld produktretning. Efterhånden som agenter bevæger sig fra demoer til interne arbejdsgange, handler risikoen mindre om, at en model svarer dårligt på ét spørgsmål, og mere om, at en model er forbundet med for mange værktøjer med for lidt overblik. En gateway, der kan pakke og kontrollere MCP-adgang, er tættere på det operationelle problem: hvilke agenter der kan nå hvilke systemer, under hvis identitet og med hvilke politiske grænser.
Kong tilføjede også dynamisk modalitetsbevidst omkostningsstyring. Dette betyder noget, fordi AI-prissætning ikke længere er en enkelt token-måler. Tekst, billede, lyd, video, værktøjsopkald, cachelagret kontekst og begrundelsestilstande kan hver især have forskellig økonomi afhængigt af udbyderen. Et omkostningskontrollag, der forstår modalitet, kan give teams mere præcise grænser og routingregler end en generisk anmodningstæller.
Udgivelsen udvider også model- og udbyderdækningen og tilføjer identitetsbevidste AI-politikker. Kongs native IAM-godkendelse til Amazon Bedrock AgentCore er især relevant, fordi Bedrock AgentCore er ved at blive et af de steder, hvor virksomheder driver og administrerer agenter. At forbinde gateway-politik til cloud-identitet reducerer kløften mellem AI-specifikke kontroller og de adgangssystemer, som virksomhederne allerede reviderer.
Hvorfor dette er vigtigt for udviklere og platformsteams
For udviklere er den praktiske effekt, at gatewayen bliver en del af applikationsarkitekturen, ikke kun en infrastrukturtilføjelse. Et team, der bygger en intern supportagent, kodningsassistent eller dataanalyse-workflow, kan nu have brug for gateway-regler for modeladgang, værktøjsadgang, budgettærskler og identitetsudbredelse, før appen når produktion.
Det kan tilføje nogle opsætningsomkostninger, men det løser også en reel fejltilstand. Uden et delt gateway-lag har modelvalg, udbyderlegitimationsoplysninger, værktøjstilladelser og forbrugskontroller tendens til at spredes på tværs af applikationskode, CI-hemmeligheder, SDK-indpakninger og teamspecifikke dashboards. Denne fragmentering gør hændelser sværere at efterforske og modelmigreringer sværere at udføre.
Kongs udgivelse er også et signal til leverandører, der bygger OpenAI-kompatible API-lag og multi-model API-produkter. Alene kompatibilitet bliver bordspil. Kunder forventer i stigende grad styring omkring anmodningen: politikhåndhævelse, brugsanalyse, adgang på teamniveau, budgetkontrol, reserveruting og model-/leverandørsynlighed.
For Model Gate-brugere er forbindelsen direkte. Ensartet fakturering, API-nøglestyring, brugsanalyse og teamkontrol bliver alle mere værdifulde, når modeladgang kun er en del af arbejdsgangen. Efterhånden som agenter får værktøjsadgang gennem grænseflader i MCP-stil, skal gateways ikke kun repræsentere, hvilken model der blev kaldt, men også hvilket team, nøgle, værktøjspakke og politikkontekst der var involveret.
Konkurrencemålet ændrer sig
Kong er ikke alene i denne retning. Nylige bevægelser på tværs af markedet viser AI-infrastrukturleverandører, der konvergerer om det samme bredere problem: Enterprise AI har brug for en styret vej mellem brugere, modeller, agenter, værktøjer og forbrug. Gateway-produkter bedømmes mindre ud fra, om de kan normalisere anmodningsformater, og mere ud fra, om de kan understøtte produktionskontrol.
Det lægger pres på købere til at stille skarpere spørgsmål. Forstår gatewayen udbyderspecifikke priser og modaliteter? Kan administratorer indstille politik efter team eller identitet? Kan det rute på tværs af udbydere uden at miste auditabilitet?Kan det styre agentværktøjer, ikke kun modelendepunkter? Kan det afsløre brugs- og omkostningsdata på en måde, som økonomi, sikkerhed og teknik alle kan bruge?
Disse spørgsmål er ikke længere teoretiske. Langkontekstmodeller, agentværktøjsopkald og multimodale arbejdsbelastninger kan hurtigt ændre omkostningsprofiler. En arbejdsgang, der ser billig ud under testning, kan blive dyr, når gentagne kontekster, billedinput eller værktøjstunge agentløkker kommer i produktion. En gateway, der ikke kan skelne mellem disse mønstre, kan stadig centralisere adgangen, men den vil ikke give operatørerne nok kontrol.
Hvad er fortsat usikkert
Meddelelsen etablerer generel tilgængelighed og navngiver nøglefunktionerne, men implementering i den virkelige verden vil afhænge af implementeringsdetaljer: hvordan teams konfigurerer MCP-pakker, hvor detaljerede politikker er, hvor meget omkostningsprogrammerne er, hvor meget omkostningsprogrammerne er, hvor meget omkostningsprogrammerne er, operationel synlighed kunder får i praksis.
Det er også for tidligt at vide, om virksomheder vil standardisere agentstyring i en enkelt AI-gateway eller opdele ansvaret på tværs af cloud-platforme, sikkerhedsværktøjer, udviklerplatforme og leverandører af observerbarhed. AWS, hostingplatforme, IDE-leverandører og selvstændige gateway-udbydere forsøger alle at eje dele af den samme kontrolflade.
Alligevel er retningen klar. Kong AI Gateway 2.0 behandler AI-trafik som et styret virksomhedssystem snarere end en strøm af modelopkald. For udviklere og virksomheder, der bygger på model-API'er, betyder det, at gateway-beslutninger bliver arkitekturbeslutninger: de påvirker omkostninger, sikkerhed, modelvalg, værktøjsadgang og pålideligheden af agentarbejdsgange.