Build 1 publisher2 min readPublished September 14, 2026 at 2:47 PM PDT

AgentCore's Consent portal absorbs the five pieces of session binding you used to host

AgentCore Identity now hosts the redirect leg and keeps the tokens, and what you configure in exchange is an OIDC application in your corporate IdP, a service role, and AWS's callback URL inside your GitHub and Slack apps.

The Engineer · Build desk

Illustration accompanying AgentCore's Consent portal absorbs the five pieces of session binding you used to host

What happened

AgentCore Identity has added a Consent portal, a managed web experience and session binding endpoint for AgentCore Gateway that an administrator creates for a gateway and then shares as a URL with users.
Customers on AgentCore Identity's three-legged OAuth flow previously built and hosted this themselves, including a public HTTPS callback, browser session management and the CompleteResourceTokenAuth call.
In the new flow the portal handles the browser redirects and the binding step, and AgentCore Identity keeps the resulting provider tokens in its token vault.
AWS aims the feature at agents used from IDE and MCP clients including Kiro, Claude Code, Cursor and Visual Studio Code, where consent can be collected before a tool is invoked.
Adoption requires a gateway with JWT inbound authorization, administrative access to the corporate IdP, and permission to register the AgentCore Identity callback URL in the GitHub OAuth App and Slack app.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

decision Teams already running their own 3LO flow now choose between maintaining an internet-facing callback service and doing IdP plus IAM setup once per gateway.
constraint The portal only serves agents behind an AgentCore Gateway with JWT inbound authorization, so consent is collected at the gateway.
exposure Provider grants for every consenting employee now sit in AWS's token vault, so the gateway's execution role and the portal's service role are what guard access to those GitHub and Slack scopes.

Session binding is the specific thing agent builders kept having to write: taking the OAuth grant a provider hands back and associating it with the user who approved it ^[1]. The old three-legged flow put five pieces of web infrastructure into a project whose user interface is an IDE ^[15]. A public HTTPS callback is a production web endpoint. It needs a name, a certificate and uptime, and it has to be reachable from every browser your users bring.

What replaces that code is configuration in two places. In the corporate IdP you create an OIDC web application for the portal and enable the authorization code grant. Then you generate a client ID and secret, set login scopes to at least `openid`, and record the OIDC discovery URL ^[11]. On the AWS side, the console's Create default role option produces a service role named `AmazonBedrockAgentCoreConsentPortalDefaultServiceRole` with a suffix appended. Supply your own role instead and AWS says to scope `iam:PassRole` to that role's ARN ^[12]. Six administrator steps, ending with mailing the portal URL to developers ^[13].

The example assistant reaches two providers: a GitHub target that lists repositories and creates issues, and a Slack target that lists public channels and posts messages ^[8]. Because each grant is collected separately, a user sits in one of four states: neither connected, GitHub only, Slack only, or both ^[16]. Three of those four will fail at least one tool call, and the agent still has to handle the missing token.

AWS says developers can connect either provider independently and return to their IDE without repeated prompts ^[9]. For that to hold in your environment, the identity the gateway reads out of the inbound JWT has to be the identity the portal bound the grant to. That has to hold on every machine the developer signs in from. It is a question about your IdP and your MCP client configuration.

The browser leg was never agent logic. Moving it behind a URL you hand out removes the one component in an agent project that had to be internet-facing. For review after the fact, the walkthrough covers reading the resulting activity in AWS CloudTrail ^[14].

What to watch

Whether the Consent portal becomes available to AgentCore runtimes that are not fronted by a Gateway, since today a portal is created for a gateway.
Whether AWS publishes the CloudTrail event names the portal emits, and what the token vault does when a user revokes the grant at GitHub or Slack.
The announcement post does not cover region availability or pricing for the Consent portal.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
Before an agent can act on a user's behalf at a service such as GitHub or Slack, the user must authenticate with the provider and explicitly approve the requested access, and the application must then securely associate the resulting OAuth grant with the user who authorized it. AWS calls this process session binding.
ReportedSupportedView cited source
[2]
Customers using the AgentCore Identity three-legged OAuth (3LO) flow previously had to build and host their own session binding infrastructure, including presenting the authorization URL, hosting a public HTTPS callback, authenticating the returning user, managing browser sessions, and calling CompleteResourceTokenAuth to complete the flow.
ReportedSupportedView cited source
[3]
AgentCore Identity, a capability of Amazon Bedrock AgentCore, now offers a Consent portal: a managed web experience and session binding endpoint for AgentCore Gateway.
ReportedSupportedView cited source
[4]
You create a portal for a gateway and share its URL with your users.
ReportedSupportedView cited source
[5]
Users authenticate with the organization's identity provider, review the services available to the agent, and grant consent to individual providers.
ReportedSupportedView cited source
[6]
The portal handles the browser redirects and session binding, while AgentCore Identity stores the resulting tokens in its token vault.
ReportedSupportedView cited source
[7]
AWS says the capability is particularly useful for agents accessed through IDE and Model Context Protocol clients such as Kiro, Claude Code, Cursor, and Visual Studio Code, where users can grant consent before invoking a tool and subsequent tool calls can use the token already stored for that user.
ReportedSupportedView cited source
[8]
In the walkthrough, Example Corp's coding assistant has two gateway targets: a GitHub target that can list repositories and create issues, and a Slack target that can list public channels and post messages.
ReportedSupportedView cited source
[9]
The administrator wants each GitHub and Slack OAuth grant to remain associated with the employee who approved it, and developers can connect either provider independently and return to their IDE without repeated prompts.
ReportedSupportedView cited source
[10]
Prerequisites include an AWS account with access to Amazon Bedrock AgentCore, an AgentCore Gateway configured with JWT inbound authorization, an IDE or MCP client configured to connect to the same gateway that will be attached to the Consent portal, administrative access to the corporate IdP, a registered GitHub OAuth App and Slack app for a development or test workspace, and permission to register the AgentCore Identity callback URL in each provider application.
ReportedSupportedView cited source
[11]
In the corporate IdP the administrator creates an OpenID Connect web application for the Consent portal, enables the authorization code grant, generates a client ID and client secret, configures login scopes with at minimum openid, and records the OIDC discovery URL.
ReportedSupportedView cited source
[12]
The administrator IAM statement covers the Create default role option on the console, which creates a service role named AmazonBedrockAgentCoreConsentPortalDefaultServiceRole-<suffix>; if you supply your own role instead, AWS says to scope iam:PassRole to that role ARN.
ReportedSupportedView cited source
[13]
The administrator completes Steps 1 through 6 to configure the identity provider, gateway targets, execution role, and Consent portal, and then sends the portal URL to developers.
ReportedSupportedView cited source
[14]
The post walks through the administrator and end-user experiences on the AWS Management Console and browser, and shows how to review the resulting activity in AWS CloudTrail.
ReportedSupportedView cited source
[15]
The pre-portal 3LO flow required builders to own five pieces of session binding infrastructure.
DerivedSupported1 source— sign in to open
[16]
With two providers whose consent is granted independently, each user is in one of four consent states: neither, GitHub only, Slack only, or both.
DerivedSupported1 source— sign in to open

Sources

Publishers with included, body-backed reporting in this cluster.

aws.amazon.com
1 article · September 14, 2026
Manage end-user OAuth consent for AI agents with Amazon Bedrock AgentCore

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

AWS names the work that goes away: presenting the authorization URL, hosting a public HTTPS callback, authenticating the returning user, managing browser sessions, and calling CompleteResourceTokenAuth. What you configure instead sits in three places, and only one of them is yours. In the corporate IdP you create an OIDC web application with the authorization code grant, at minimum the openid scope, and a discovery URL; in AgentCore Identity you register that client ID and secret as an OAuth2 credential provider plus separate outbound providers for GitHub and Slack; in the GitHub OAuth App and the Slack app you register AWS's generated callback URL. The gateway itself has to already use JWT inbound authorization, and the IdP has to return a signed JWT access token rather than an opaque one, which is why Okta gets a custom authorization server and Auth0 gets an audience in AWS's examples. AWS does not cover token lifetime or revocation.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence62

0100

First-party, but specific enough to check

Every fact traces to AWS's own post, and it is the kind of vendor post an engineer can test. It names the call that used to close the flow, CompleteResourceTokenAuth, the role the console creates, AmazonBedrockAgentCoreConsentPortalDefaultServiceRole-<suffix>, the minimum openid scope, and the IdP behaviour the portal depends on, with Okta and Auth0 as worked examples. AWS does not show the part that matters most: that the vault keeps each grant tied to the right employee.

Adoption12

0100

Launch, no users named

The only observable event is the announcement itself, dated 14 September 2026. Example Corp is a scenario AWS wrote, not a deployment, and no customer using the portal is named. The four IDE and MCP clients are listed as places the pattern fits, not as integrations anyone has reported running.

Hype gap+8

−100 understated0 aligned+100 overstated

Narrow promise, one unshown claim

The central promise is unusually bounded for a launch post: five named pieces of hosting work move to AWS. Set against that, 'particularly useful' for the four IDE and MCP clients is asserted and not demonstrated, and the post never adds up the configuration you take on in exchange, which runs to an OIDC application, a credential provider, a service role, two provider app registrations and a gateway that already validates JWTs inbound.

Incentives88

0100

Vendor launch on its own channel

AWS published this about its own service on its own blog, and the walkthrough routes a customer through Bedrock AgentCore, Secrets Manager, IAM and CloudTrail. Normal for a launch post, and it also means the characterisation of the pre-portal work as a burden comes from the party selling the replacement.

Confidence55

0100

Single vendor account

One publisher, first-party, no replication, and only AWS can observe the behaviour that matters: that the token vault holds each grant against the employee who approved it, and that a returning developer is not prompted again. The configuration detail is precise enough that anyone who tries it can prove it wrong. That keeps this from sitting lower.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

build
AWS's one-minute test for agent access is really a test of where the answer lives
1 publisher
build
Basic Auth becomes a gateway problem: AgentCore's Lambda interceptor keeps the password away from the model
1 publisher
build
Paying $7 per 1,000 queries keeps web search inside an AWS account you already reviewed
1 publisher
build
AWS wants data governance to ship as a pull request, not a sign-off
1 publisher

AgentCore's Consent portal absorbs the five pieces of session binding you used to host

What happened

Why it matters

What to watch

Claim ledger

Sources

Topics and entities

Topics

Entities

Claim ledger

Sources

Perspective Coverage

Reality

Topics and entities

Topics

Entities

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Sources

Let Clarity write the post for you.

Perspective Coverage

Reality

Topics and entities

Topics

Entities

Related stories