Kong AI Gateway 3.14 tar trafikken mellom agenter inn i gatewayen

API gatewayer startet som en måte å styre trafikken til API-er på. Etter hvert lærte de å håndtere kall til språkmodeller, og senere til MCP-servere. 14. april tok Kong neste steg: versjon 3.14 av Kong AI Gateway ruter og styrer også trafikken mellom agenter som bruker A2A-protokollen.

Kong sier at dette gjør den til den første gatewayen som håndterer alle tre typene AI-trafikk på ett sted: kall til LLM-er, kall til MCP-servere og kall mellom agenter.

Hva Kong lanserte

Den viktigste nyheten er støtte for A2A-trafikk, som Kong også markedsfører som Kong Agent Gateway. Ifølge Kong gir den:

• routing og håndheving av policies for kall mellom agenter,
• strukturert logging av A2A-kall, med innhold og statistikk, til bruk i audit,
• oversikt over tokenforbruk for trafikken mellom agenter,
• ett kontrollpunkt for sikkerhet og tilgangsregler.

Versjon 3.14 har også flere forbedringer for MCP og kostnadskontroll:

• Token exchange (RFC 8693), slik at et token kan snevres inn før det sendes videre, og tilgang til MCP-verktøy kan begrenses med OAuth scope.
• Lokal validering av MCP-tokens med de publiserte nøklene til autorisasjonsserveren, uten et ekstra kall for hver forespørsel.
• Budsjetter for tokens på tvers av alle leverandører og modeller, med egne grenser per modell.
• Standardiserte guardrails og støtte for egne guardrails fra tredjeparter.
• Nye modelleverandører, blant annet Databricks, DeepSeek og self-hosted modeller via vLLM.

Funksjonene er tilgjengelige i Kongs plattform Konnect.

Hvorfor det betyr noe

Når agenter begynner å kalle hverandre, dukker de samme spørsmålene opp som med API-er: hvem kalte hvem, med hvilke rettigheter, hva kostet det, og hva skjedde når noe feilet? Gatewayer svarer allerede på de spørsmålene for API-er, så det er et naturlig steg å sende trafikken mellom agenter gjennom samme type gateway.

Detaljene i 3.14 viser hvor de vanskelige delene er. Token exchange og tilgang til verktøy styrt av scope handler om at en agent bare skal få rettighetene den trenger for en bestemt oppgave, og ikke de brede rettighetene til tjenesten den kjører som. Budsjettene for tokens er et svar på at AI-kostnader er vanskeligere å forutsi enn API-kostnader.

Hvordan det står seg

Kong er ikke alene. De store leverandørene av iPaaS og API management bygger sine egne AI gatewayer med støtte for MCP og etter hvert A2A. Det som skiller Kong, er at selskapet kommer fra gateway-siden og ikke har en egen integrasjonsplattform. Derfor brukes Kong ofte foran andre plattformer.

For virksomheter som allerede bruker Kong for API-er, kan det være enklere å utvide til trafikk mellom agenter enn å legge til en ny komponent. For dem som bruker en iPaaS med egen gateway, er spørsmålet om man vil ha én gateway for alt eller én per plattform.

Hva du bør spørre om

1. Én gateway eller flere? Kartlegg hvor trafikken til LLM-er, MCP-servere og agenter går i dag, og bestem om den skal styres på ett sted.
2. Delegerte rettigheter. Sjekk hvordan gatewayen begrenser hva en agent kan gjøre på vegne av en bruker, og om token exchange støttes.
3. Kostnadskontroll. Spør om budsjetter for tokens kan settes per team, per modell og per agent, og hvordan man blir varslet før en grense nås.