· David

Google Cloud Next 2026: agent registry, gateway og identitet blir skytjenester

På Cloud Next 2026 la Google til Agent Registry, Agent Gateway og Agent Identity i agentplattformen sin. Hva det betyr for integrasjon og for kjøpere av iPaaS.

Read in English

Google Cloud Next 2026 ble avsluttet med en liste over 260 kunngjøringer, de fleste om AI-agenter. For integrasjonsteam er de viktigste nyhetene ikke de nye modellene, men et sett med tjenester for governance: en registry over agenter og verktøy, en gateway for trafikk mellom agenter og egne identiteter for agenter.

Dette er de samme byggeklossene som iPaaS-leverandørene har lagt inn i plattformene sine det siste året. Nå tilbyr en av de store skyleverandørene dem som en del av sin egen plattform.

Hva Google lanserte

Vertex AI har blitt til Gemini Enterprise Agent Platform, som Google beskriver som en plattform for å bygge, skalere, styre og optimalisere agenter. Flere av de nye tjenestene handler om governance:

  • Agent Registry gir en oversikt over virksomhetens agenter, verktøy og skills, og har et bibliotek med godkjente verktøy, slik at bare styrte ressurser er tilgjengelige.
  • Agent Gateway er ett kontrollpunkt for koblinger mellom agenter, og mellom agenter og verktøy. Ifølge SiliconANGLE forstår den både MCP og A2A, og den håndhever sikkerhetsregler og Model Armor-beskyttelse mot prompt injection og datalekkasje.
  • Agent Identity gir hver agent sin egen identitet med begrensede, delegerte rettigheter.
  • Partnerskap med leverandører av sikkerhet og identitet, blant annet Okta, Ping Identity, Palo Alto Networks og Zscaler, lar kundene koble egne verktøy til Agent Gateway. Dette er i preview.

Google kunngjorde også flere administrerte MCP-servere, blant annet for databaser, Cloud Storage og Workspace, og støtte for å koble MCP-servere fra tredjeparter til Gemini Enterprise.

Hvorfor det betyr noe

En registry, en gateway og identitet for agenter er kjernen i agent governance. De svarer på spørsmålene som dukker opp så snart en virksomhet har mer enn en håndfull agenter: hva finnes, hvem eier det, hva har det tilgang til, og hva har det gjort?

Når en skyleverandør tilbyr dette som standardtjenester, endrer spørsmålet seg for kjøpere av iPaaS. Det handler ikke lenger bare om hvilken integrasjonsplattform som har best agent governance, men om hvor governance skal ligge når agentene kjører både i skyleverandørens plattform og i integrasjonsplattformen.

Hvordan det står seg

Leverandørene av iPaaS og API management bygger sine egne registries og gatewayer for agenter og MCP-servere, og de andre skyleverandørene gjør det samme. Protokollene er de samme, MCP og A2A, men hver plattform har sin egen registry og sine egne regler.

For de fleste store virksomheter blir det realistiske resultatet flere registries og flere gatewayer. Da blir evnen til å utveksle informasjon mellom dem, eller til å skanne andre plattformer etter agenter, viktigere enn hvilken plattform som har flest funksjoner.

Hva du bør spørre om

  1. Hvor ligger hovedregistryen? Bestem hvilken registry som skal være hovedkilden for agenter og MCP-servere, og hvordan de andre holdes synkronisert.
  2. Identitet på tvers av plattformer. Sjekk om identiteten til en agent i Google Cloud kan forstås og begrenses når den kaller en agent eller et API i en annen plattform.
  3. Hvor gatewayene står. Kartlegg hvilken trafikk som går gjennom hvilken gateway, slik at ingen agenttrafikk går utenom policies og logging.

Kilder

Innlegget er skrevet med hjelp av AI og gjennomgått av redaksjonen før publisering.

← Alle innlegg