De fleste virksomheder med flere forretningsenheder står med det
De fleste virksomheder med flere forretningsenheder står med det samme problem, når de vil bygge en AI-agent, der kan svare på tværs af enhederne. Data ligger spredt i separate AWS-konti, og den nemme løsning, at samle det hele i én central datasø, kræver enten et stort migreringsprojekt eller at hver enhed opgiver kontrollen over sine egne data. Et nyere AWS-mønster viser en tredje vej, hvor agenten kører centralt, men dataadgangen forbliver decentral.
Arkitektur
Flerkonto-arkitekturen bag en agent der spørger på tværs af isolerede AWS-konti
Mønstret, AWS beskriver, bygger på en klar rollefordeling mellem tre typer AWS-konti. En central platformkonto hoster selve AI-agenten, typisk bygget på Amazon Bedrock AgentCore. Herfra sendes forespørgsler via AgentCore Gateway til en række forretningsenhedskonti, som hver især ejer og drifter deres egne data. Ingen data flytter permanent til platformkontoen. Agenten henter kun det, den har brug for, til hver enkelt forespørgsel.
Det gør arkitekturen fundamentalt anderledes end en traditionel data warehouse-tilgang. I stedet for at flytte data til ét sted, flytter man adgang til dataene og lader ejerskabet blive, hvor det er. For en virksomhed med for eksempel en økonomiafdeling, en HR-afdeling og en salgsafdeling, der hver kører deres egen AWS-konto, betyder det, at ingen af afdelingerne skal give slip på deres data for at gøre dem tilgængelige for en fælles AI-agent.
Den tekniske gevinst ligger i, at cross-account adgang i AWS allerede er et modent felt med veldefinerede mekanismer: IAM-roller, ressourcepolitikker og AWS Organizations. Mønstret genbruger disse i stedet for at opfinde en ny sikkerhedsmodel specifikt til AI-agenter. Det er en pragmatisk detalje, men den betyder meget for, hvor hurtigt en virksomhed kan sætte løsningen i produktion, fordi det meste af infrastrukturen allerede findes. Det er samme pragmatisme, jeg selv lander på, når jeg bygger agentgrænser hos kunder: genbrug det, platformen allerede kan, før du opfinder noget nyt.
MCP-servere
Sådan eksponerer forretningsenhederne deres data som MCP-servere med cross-account adgang
Hver forretningsenhedskonto eksponerer sine data gennem en MCP-server, Model Context Protocol, som er blevet den de facto standard for, hvordan AI-agenter taler med værktøjer og datakilder. I stedet for at bygge en unik integration for hver afdeling, får agenten et ensartet interface at snakke med, uanset om den spørger til salgstal, lagerstatus eller HR-data.
AgentCore Gateway fungerer som broen mellem den centrale agent og de decentrale MCP-servere. Gatewayen håndterer selve cross-account kaldet, autentificerer forespørgslen, og videresender den til den rigtige forretningsenhedskonto. For forretningsenheden ser det ud, som om et internt system spørger, ikke en ekstern agent, fordi adgangen er skåret ud som en veldefineret cross-account rolle med begrænsede rettigheder. Denne form for delegeret cross-account adgang via en agent-kæde går igen i flere AgentCore-mønstre.
Det praktiske ved denne opsætning er, at forretningsenhederne kan udvikle og opdatere deres MCP-servere uafhængigt af hinanden og af platformkontoen. Salgsafdelingen kan tilføje et nyt datasæt til sin MCP-server, uden at det kræver koordinering med HR eller med teamet, der drifter selve agenten. Det reducerer den organisatoriske friktion, der ellers plager centraliserede AI-projekter, hvor alting skal godkendes af én central instans, før noget kan ændres.
Autorisation
Finkornet autorisation holder adgangskontrollen hos hver enkelt konto
Det mest interessante ved arkitekturen er, hvor autorisationslogikken ligger. Den centrale platformkonto beslutter ikke, hvad agenten må se, det gør hver enkelt forretningsenhedskonto for sine egne data. Når en forespørgsel rammer en MCP-server, tjekker den lokale autorisationslogik, om den specifikke bruger eller det specifikke agent-kald har ret til at se netop de data, der bliver bedt om.
Det betyder, at en forretningsenhed kan give agenten adgang til aggregerede tal, men afvise adgang til detaljerede personoplysninger, uden at platformkontoen nogensinde behøver at vide, at den grænse findes.
Den finkornede tilgang løser et problem, som mange virksomheder har oplevet med simplere AI-integrationer: en agent med bred adgang til én stor datakilde ender ofte med enten for meget adgang, en compliance-risiko, eller for lidt adgang, hvor agenten bliver ubrugelig, fordi den ikke kan svare på reelle spørgsmål. Ved at lade hver konto styre sin egen finkornethed kan forretningsenhederne stramme eller løsne adgangen uden at skulle bede om en ændring i et centralt system, de ikke selv ejer. Det minder om, hvordan andre AgentCore-mønstre bruger et open source politiksprog til finkornet adgang til at lade hver konto definere sine egne regler.
Autorisationsreglerne lever tæt på dataene, hvor de hører hjemme, i stedet for i en central politik, der skal forstå alle afdelingers regler på én gang.