AgentCore Gateway: Styr AI-agenters

De fleste virksomheder starter et agentprojekt med en agent, der har direkte, ubegrænset adgang til de API'er og datakilder, den skal bruge. Det virker fint i en prototype med én udvikler og én use case. Problemet opstår, når agenten flytter i produktion, og flere teams begynder at bygge oven på den samme infrastruktur. Uden et lag, der styrer adgangen centralt, ender virksomheden med agenter, der har adgang til langt flere systemer, end deres opgave kræver, og ingen samlet oversigt over, hvad der egentlig sker.

Det er præcis det problem, en gateway-arkitektur løser. I stedet for at agenten taler direkte med hvert enkelt system, går alle kald gennem et centralt lag, der kan godkende, logge og begrænse trafikken. Vi ser den samme bevægelse hos danske virksomheder, der går fra enkeltstående AI-forsøg til egentlig drift: behovet for central styring kommer ikke fra dag ét, men det kommer altid, når flere agenter og flere teams begynder at dele den samme infrastruktur.

Modellen beskriver fire niveauer, en virksomhed typisk bevæger sig igennem, efterhånden som agentbrugen modnes: Connect, Control, Catalog og Harden. Ideen er ikke at bygge det hele på forhånd. Den er at rykke til næste niveau, når et konkret governance-problem kræver det, ikke før.

Det er fristende at tro, at man bør sigte direkte efter Harden-niveauet, men det er sjældent den rigtige rækkefølge. En virksomhed med én intern agent og få brugere har ikke brug for et fuldt katalogsystem. Det ville være overengineering, der bremser udviklingen uden at løse et reelt problem.

Signalet om, at det er tid til at rykke videre, kommer typisk fra organisationen selv. Når flere teams begynder at bygge agenter, der skal bruge de samme værktøjer, er det tegn på, at Control-niveauet er nødvendigt. Når antallet af værktøjer vokser til et punkt, hvor udviklere bruger mere tid på at lede efter den rigtige integration end på at bygge, er det tid til Catalog. Og når agenter begynder at håndtere data eller handlinger med reelle forretningsmæssige konsekvenser, kundedata, betalinger, eller adgang til produktionssystemer, er Harden ikke længere valgfrit.

Vi har set samme mønster i vores egne projekter: governance, der bliver indført for tidligt, opleves som friktion og bliver omgået. Governance, der kommer på det rigtige tidspunkt, opleves som en selvfølge, fordi behovet allerede er tydeligt for alle involverede.

Det mest praktiske ved denne model er, at den giver et sprog for en samtale, som ellers ofte foregår implicit. I stedet for at diskutere "skal vi have mere sikkerhed" i abstrakte vendinger, kan et team konkret placere sig selv på et af de fire niveauer og pege på, hvad det næste skridt kræver.

For danske virksomheder, der er i gang med at flytte AI-agenter fra pilotprojekt til produktion, er den vigtigste pointe måske denne: adgangsstyring til værktøjer er ikke noget, man tilføjer bagefter som en sikkerhedsopgradering. Det er en arkitektonisk beslutning, der bør tages, inden agenten får adgang til sit første produktionssystem, fordi det er langt dyrere at rulle adgang tilbage end at designe den rigtigt fra starten.

Hos Agent Enterprise, hvor jeg selv har bygget og driver agentopsætningen, gik vi samme vej. Agenterne fik adgang til ét værktøj ad gangen, og hver ny adgang blev en bevidst beslutning frem for en standardindstilling. Det er ikke hurtigere i starten, men det betyder, at vi altid kan se, hvorfor en agent har adgang til det, den bruger.