Ifølge et blogindlæg fra AWS introduceres en managed Consent‑portal og et session‑binding‑endpoint i AgentCore Identity i Amazon Bedrock AgentCore. Portalen håndterer browser‑omdirigeringer og session binding, og de resulterende tokens lagres i AgentCore Identitys token vault. Blogindlægget forklarer sammenhængen med OAuth‑samtykke for AI‑agenter, der skal tilgå tredjepartstjenester på vegne af brugere (kilde: AWS blog).
Blogindlægget beskriver, at AI‑agenter ofte skal tilgå tjenester som GitHub og Slack på brugerens vegne, og at brugeren derfor skal autentificere sig hos udbyderen og eksplicit godkende den ønskede adgang. Applikationen skal derefter knytte det udstedte OAuth‑grant sikkert til den bruger, der godkendte det, hvilket AWS omtaler som session binding (kilde: AWS blog).
Før kunderne fik portalen
Ifølge blogindlægget måtte kunder, der brugte AgentCore Identitys tre‑leddet OAuth‑flow, før denne udvidelse selv bygge og hoste session‑binding‑infrastrukturen. AWS oplister eksplicit opgaver som at præsentere authorization URL, hoste en offentlig HTTPS‑callback, autentificere den returnerende bruger, styre browser‑sessioner og kalde CompleteResourceTokenAuth for at fuldføre forløbet (kilde: AWS blog).
Det er de konkrete trin, blogindlægget fremhæver som kundens ansvar i den tidligere model. Blogindlægget oplyser ikke yderligere målinger eller kvantificerede driftsgevinster i forbindelse med ændringen (kilde: AWS blog).
Hvad den nye Consent‑portal gør
AgentCore Identity tilbyder nu en managed Consent‑portal samt et session‑binding‑endpoint til AgentCore Gateway. Ifølge blogindlægget opretter administratorer en portal for et gateway og deler URL’en med brugerne. Brugerne autentificerer sig via organisationens IdP, ser hvilke tjenester agenten kan forbinde til, og giver samtykke pr. udbyder. Portalen håndterer browser‑omdirigeringer og session binding, og AgentCore Identity lagrer de resulterende tokens i sin token vault (kilde: AWS blog).
Blogindlægget gennemgår et workflow med administrator‑ og slutbruger‑oplevelsen i AWS Management Console og browser, og viser, hvordan man kan gennemgå den resulterende aktivitet i AWS CloudTrail. Blogindlægget angiver også, at funktionen er nyttig for agenter tilgået via IDE‑ og Model Context Protocol (MCP)‑klienter som Kiro, Claude Code, Cursor og Visual Studio Code, så brugere kan give samtykke før et værktøj kaldes, hvorefter efterfølgende kald kan genbruge det lagrede token for den bruger (kilde: AWS blog).
OAuth og session binding i praksis
Ifølge AWS er udgangspunktet, at agenter ikke skal handle uden eksplicit samtykke fra brugeren, og at session binding sikrer, at det udstedte grant entydigt forbindes til den rigtige brugeridentitet. Den administrerede portal understøtter forløbet ved at centralisere omdirigeringer og binding, så tokens ender i en fælles vault under AgentCore Identity (kilde: AWS blog).
Blogindlægget viser via en figur og trin, at portalen autentificerer brugeren mod virksomhedens IdP, bruger sin IAM execution role til at opdage konfigurerede gateway targets, præsenterer udbyder‑forbindelser, fuldfører session binding og lagrer per‑bruger tokens i AgentCore Identitys token vault (kilde: AWS blog).
Hvad blogindlægget eksplicit dækker
Blogindlægget beskriver de nævnte komponenter og trin og illustrerer logningen i CloudTrail. Blogindlægget beskriver ikke frekvens for token‑rotation, mekanismer for revocation eller de præcise IAM‑privilegier for adgang til token‑vaulten. De punkter er ikke uddybet i blogindlægget og kræver separat produktdokumentation for bekræftelse (kilde: AWS blog).
Af samme grund rummer blogindlægget heller ikke benchmarks for tidsforbrug eller kvantificerede driftsgevinster. Blogindlægget angiver, hvad portalen gør, og hvordan man kan gennemgå aktivitet i CloudTrail, uden yderligere målinger af effekt (kilde: AWS blog).
IDE og MCP‑klienter
Ifølge blogindlægget er kapabiliteten særlig nyttig, når agenter bruges gennem IDE‑ og MCP‑klienter, fordi brugere kan give samtykke på forhånd. Eksemplerne omfatter Kiro, Claude Code, Cursor og Visual Studio Code. Pointen i blogindlægget er, at efterfølgende værktøjskald kan udnytte de allerede lagrede tokens for den pågældende bruger (kilde: AWS blog).
Blogindlægget beskriver, at den praktiske anvendelse kan være at tilgå tjenester som GitHub på brugerens vegne gennem agentens værktøjer efter samtykke. Det er netop i disse klienter, at forstyrrelser fra ad‑hoc samtykke‑prompter kan undgås ved at samle godkendelsen i portalen, som blogindlægget beskriver (kilde: AWS blog).
CloudTrail‑gennemsyn
Blogindlægget viser, hvordan man kan gennemgå aktivitet i AWS CloudTrail relateret til portalen og de tilhørende hændelser. Det indgår som en del af den beskrevne administrator‑oplevelse sammen med browserforløbet for en slutbruger (kilde: AWS blog).
Det, der fremgår af blogindlægget, er, at begivenheder kan findes i CloudTrail, og at administratoren kan følge forløb og hændelser via den kanal. Der tilføjes ikke andre implementeringsdetaljer i blogindlægget (kilde: AWS blog).
Relateret udvikling i økosystemet
En artikel fra MarkTechPost den 14. september 2026 omtaler, at Agent‑net har open‑sourcet Webagent, et Go‑baseret harness til offentligt vendte agenter. Ifølge artiklen er projektet stadig v0, og flere funktioner, herunder en “OAuth‑gated MCP”, er listet som ikke bygget endnu. Referencen bruges her udelukkende til at pege på parallel udvikling i agent‑rammer, ikke til at antyde feature‑paritet med AWS’ løsning (kilde: MarkTechPost, 14. september 2026).
MarkTechPost‑artiklen leverer versions‑ og statusoplysninger for Webagent‑projektet og et overblik over, at visse moduler endnu ikke er realiseret. Der fremsættes ikke yderligere antagelser ud over, hvad artiklen beskriver (kilde: MarkTechPost).
Opsummering
På baggrund af AWS’ blogindlæg kan det konstateres, at AgentCore Identity nu tilbyder en managed Consent‑portal og et session‑binding‑endpoint til AgentCore Gateway, at portalen håndterer omdirigeringer og session binding, og at tokens lagres i AgentCore Identitys token vault. Blogindlægget viser også, hvordan aktivitet kan gennemgås i CloudTrail, og beskriver brugen i IDE‑ og MCP‑klienter som Kiro, Claude Code, Cursor og Visual Studio Code (kilde: AWS blog).
Blogindlægget beskriver ikke parametre som rotationsfrekvenser, revocation‑mekanismer eller de præcise IAM‑roller og privilegier for adgang til token‑vaulten. For de spørgsmål henviser blogindlægget ikke til konkrete detaljer. Den dokumenterede del angår portalens funktion, de nævnte trin i OAuth‑forløbet og muligheden for at følge hændelser i CloudTrail (kilde: AWS blog).
