AWS har offentliggjort en ny vejledning til, hvordan man kobler OAuth-beskyttede MCP-servere på Amazon Bedrock AgentCore Gateway via OAuth 2.0 Authorization Code flow. Det kan ligne endnu en integrationsguide fra cloud-verdenen, men her er pointen mere praktisk. AWS vil flytte MCP-adgang væk fra lokal specialkonfiguration og over i et fælles driftslag, hvor adgang, politikker og overvågning kan styres samlet.Det er relevant nu, fordi MCP hurtigt går fra at være en smart demo i én udviklers editor til at blive noget rod, når flere teams, værktøjer og leverandører blandes ind i samme miljø. AWS beskriver selv AgentCore Gateway som et centraliseret lag til at styre, hvordan AI-agenter forbinder sig til værktøjer og MCP-servere på tværs af organisationen. Formuleringen er meget AWS. Men problemet bag er reelt nok: Forbindelser, login, tokens og routing ender alt for ofte med at leve lokalt.

Det operative problem er ret kedeligt og ret vigtigt

Når virksomheder skalerer brugen af AI-agenter, vokser antallet af MCP-servere hurtigt. Det fremgår både af AWS’ nye blogindlæg og af introduktionen til AgentCore Gateway. I praksis betyder det, at teams ikke længere bare har én intern MCP-server og et par eksperimenter. De peger måske også på tredjepartsløsninger, egne værktøjer, GitHub-lignende integrationer, CRM-data og andet, som ingen rigtig gider holde styr på fredag klokken 16.12.AWS skriver ret direkte, at det bliver uholdbart at styre connections, authentication og routing på IDE-niveau, når mængden vokser. Det er nok den mest interessante del af nyheden. For det er præcis dér mange pilotprojekter begynder at knage. Ikke fordi modellen er dårlig, men fordi hver integration lever sit eget liv, og fordi én udviklers lokale opsætning pludselig bliver til en slags uofficiel platformarkitektur. Det er sjældent kønt.Vi har set noget lignende før, bare i andre klæder. Først virker lokal frihed hurtigt og smart. Så kommer team nummer to, så compliance, så et nyt værktøj med egne login-krav, og så sidder man med en mappe af små scripts, tokens og konfigfiler, som ingen helt tør slette. Det lugter ikke af strategi. Det lugter af tirsdag.

Én gateway i stedet for ti små særtilfælde

Ifølge AWS samler AgentCore Gateway authentication, observability og policy enforcement i ét endpoint. Det er værd at holde fast i, fordi det er kernen i det hele. Udviklere kan pege på én gateway-URL for adgang til flere MCP-servere i stedet for at konfigurere hver MCP-server separat per IDE. Det er verificeret i AWS’ egen gennemgang af Authorization Code flow.I praksis er gevinsten ret enkel at forstå. Hvis fem teams bruger de samme værktøjer, er det smartere, at de møder ét fælles indgangspunkt, hvor regler og adgang kan styres samlet, end at hvert team bygger sin egen lille adgangsbro. Den slags centralisering lyder altid lidt tung i powerpoint, men i drift er den ofte en lettelse. Man ved i det mindste, hvor man skal kigge, når noget går galt. Eller når nogen spørger, hvem der egentlig havde adgang til hvad.AWS kobler også gatewayen til et mere samlet kontrolplan for MCP-adgang. Det er igen deres ordvalg, men substansen holder. Samme blog og den tilhørende dokumentation peger på, at gatewayen bruges til at forbinde targets med tools, så de kan bruges i agent runtime. Der er altså ikke bare tale om en pæn URL foran gamle integrationer. Gatewayen bliver stedet, hvor relationen mellem MCP-servere, værktøjer og agentbrug organiseres.

Hvorfor Authorization Code flow betyder noget

Den nye guide handler specifikt om OAuth 2.0 Authorization Code flow, og det er ikke bare en teknisk detalje for dem, der samler på RFC-numre. Mange enterprise-MCP-servere kræver ifølge AWS OAuth 2.0-autorisering, hvor agenten skal autentificere på vegne af en bruger, før et værktøj må kaldes. Det er en anden situation end klassiske machine-to-machine flows som client credentials, hvor der ikke er en bruger inde over på samme måde.Det lyder tørt, men forskellen er afgørende. Hvis et værktøj arbejder med brugerens data, brugerens rettigheder eller en handling, der kræver personlig godkendelse, så er det ikke nok bare at lade en servicekonto marchere ind ad bagdøren. Authorization Code flow er lavet til brugerbaseret autorisation. Et menneske giver adgang, og systemet får derefter tokens på en kontrolleret måde. Ikke så sexet. Meget praktisk.AWS skriver, at AgentCore Gateway nu understøtter Authorization Code flow gennem Amazon Bedrock AgentCore Identity. Samtidig fremhæver AWS, at agenter dermed kan få sikker adgang til beskyttede MCP-servere uden at lægge credentials ind i applikationskode og uden manuel håndtering af token-livscyklus. Det sidste er en af de detaljer, der faktisk betyder noget mandag morgen. For manuel token-håndtering ser altid simpel ud i et diagram og bliver næsten altid irriterende i virkeligheden.

Lidt teknik, kun det nødvendige

Dokumentationen for Bedrock AgentCore uddyber, hvordan MCP-servere kan sættes op som preconfigured targets, når man opretter en gateway. Gatewayen bruges så til at associere targets med tools og forbinde dem til agent runtime. Det er en vigtig præcisering, fordi AWS her forsøger at gøre MCP mindre løst og mere deklarativt. Altså: mindre håndholdt per integration, mere defineret i en fælles struktur.For eksterne MCP-servere sker forbindelsen ifølge dokumentationen via SynchronizeGatewayTargets API. Den udfører protokol-håndtryk og indekserer tilgængelige tools. Det er værd at nævne, fordi det fortæller noget om, hvor AWS placerer arbejdet. Ikke ude i hver enkelt klient, men i gateway-laget. Og ja, sådan noget lyder småbureaukratisk. Men det er også præcis sådan, platforme bliver driftsklare.AWS beskriver to måder at håndtere Authorization Code flow på under target-oprettelse. Enten kan admin-brugeren gennemføre flowet under oprettelse eller synkronisering, så gatewayen kan opdage og cache værktøjerne med det samme. Eller også kan admin selv levere schema på forhånd, så gatewayen ikke behøver hente det dynamisk fra MCP-serveren. Det er faktisk en interessant detalje, fordi den viser, at AWS ikke kun tænker på login, men også på hvordan tool discovery skal fungere, når OAuth er inde over.

AWS gør MCP mere driftsklart, ikke mere neutralt

Det er her, nyheden bliver lidt mere end produktdokumentation. AWS er i gang med at flytte MCP fra eksperiment til driftsdisciplin. Mindre lokal konfiguration. Mere central governance. Mere ensartet sikkerhed. Mere sporbarhed. Det er logisk, og for AWS-kunder er det også ret stærkt.Men det er ikke magi, og det er heller ikke en neutral standardløsning for alle. Det er AWS’ måde at gøre MCP håndterbart på i AWS’ eget univers. Det skal man ikke skælde ud over, men man skal heller ikke lade som om det er et universelt svar på al agentintegration. Hvis man allerede ligger tungt i Bedrock og bygger rundt om AWS’ identitets- og gatewaylag, så giver det mening. Hvis man er et lille team med to enkle integrationer, så kan det her hurtigt blive mere platform end problem.Der er også en mere stille pointe her. Når AWS samler authentication, observability og policy enforcement i gatewayen, flytter de også magten over integrationslaget ind i deres egen styrede flade. Det er smart, men det er ikke gratis i arkitektonisk forstand. Man får mindre lokalt rod, ja. Man får også mere afhængighed af AWS’ måde at modellere targets, identitet og synkronisering på. Det er nok fint for mange. Bare ikke for alle.

Det ændrer noget for teams, der er på vej i drift

For Snillds læsere er bundlinjen ret enkel. Hvis man stadig leger med én agent og et par værktøjer, er gevinsten begrænset. Så kan man ofte leve med direkte forbindelser og lidt manuel opsætning. Men når flere teams skal dele værktøjer, når adgang skal styres ens, og når OAuth-beskyttede servere begynder at fylde, så bliver gateway-tankegangen pludselig konkret. Ikke teoretisk. Konkret.Det, der overraskede mest i AWS’ nye guide, er egentlig ikke selve OAuth-støtten. Den var næsten ventet. Det interessante er, hvor tydeligt AWS nu siger, at styring på IDE-niveau ikke holder, når MCP breder sig. Det er en ret kontant indrømmelse af, at den tidlige måde at arbejde med MCP på ikke skalerer særlig elegant. Og det gør den ærlig talt heller ikke.Så ja, vi ser det som en vigtig og ret logisk udbygning af Bedrock AgentCore. Ikke en revolution. Ikke noget der løser alt. Men en reel forbedring for organisationer, der er ved at gå fra pilot til drift og har opdaget, at integrationslaget bider igen. Man opdager først forskellen, når antallet af forbindelser begynder at opføre sig som et system og ikke bare som et projekt.

Kilder

• Connecting MCP servers to Amazon Bedrock AgentCore Gateway using Authorization Code flow
• MCP servers targets – Amazon Bedrock AgentCore
• Introducing Amazon Bedrock AgentCore Gateway
• Deploy MCP servers in AgentCore Runtime – AWS Documentation
• Thoughts on Enterprise MCP Deployment | by Bill Mahony | Feb, 2026
• #aws #amazonbedrock #ai #agentcore #mcp #oauth #aiagents …