Amazon Web Services published a walkthrough on September 14, 2026 for a new Consent portal inside Amazon Bedrock AgentCore Identity, a managed web experience that handles end-user OAuth consent and session binding for AI agents connecting to outside services like GitHub and Slack. AWS first listed the capability in its official What's New feed on September 1, 2026, where it also named Salesforce as a supported target alongside GitHub and Slack.

The pitch is simple. Before this, a developer building an agent on AgentCore Gateway that needed to act on a user's behalf, say, reading a GitHub repo or posting to Slack, had to build and host their own OAuth callback infrastructure: a public HTTPS endpoint, session management, and code to tie the resulting token back to the right user. AWS says the Consent portal now does that for them.

This matters most for a specific and growing group of developers: people building agents that live inside IDEs or Model Context Protocol clients, tools like Kiro, Claude Code, Cursor, and VS Code, which have no built in way to pop open a browser consent screen mid session.

What AWS Actually Shipped

AgentCore Identity, part of Amazon Bedrock AgentCore, now offers a Consent portal: one hosted URL per AgentCore Gateway that an administrator provisions and shares with end users. According to AWS's blog post, written by AWS solutions architects Swara Gandhi, Satveer Khurpa, and Eashan Kaushik, the portal replaces work that customers previously had to build themselves for the three legged OAuth (3LO) flow, also known as the OAuth 2.0 authorization code flow.

That DIY work, per AWS, included presenting the authorization URL, hosting a public HTTPS callback, authenticating the returning user, managing browser sessions, and calling the CompleteResourceTokenAuth API to finish the handoff. AWS calls that process session binding: tying an OAuth grant to the specific user who approved it, not just to the agent.

With the portal in place, end users open the shared URL, sign in through their organization's own identity provider (any OIDC provider that issues JWT access tokens, AWS names Okta and Auth0 as examples), review which services the agent can reach, and approve each one individually. GitHub and Slack connections are granted separately in AWS's walkthrough, and a user can leave one disconnected until an agent actually needs it. AgentCore Identity stores the resulting tokens in its token vault, and the portal automatically renews access tokens when a provider issues a refresh token. When it doesn't, because the provider didn't issue one or it expired, the user has to go back to the portal and reauthorize by hand.

Administrators configure the pieces through three new AWS APIs (CreateConsentPortal, GetConsentPortal, ListConsentPortals), and every step generates AWS CloudTrail events, GetResourceOauth2Token, CompleteResourceTokenAuth, and GetWorkloadAccessTokenForJWT, that log the credential provider, requested scopes, and execution role involved, with token values redacted.

A few constraints are worth flagging for anyone planning to use this. AWS confirms only one Consent portal is allowed per gateway, and the gateway can't be swapped out after the portal is created. The identity provider has to issue JWT access tokens; providers that only return opaque tokens aren't supported as the primary sign in provider. AWS's September 1 What's New notice says the feature is live in all commercial regions where Bedrock AgentCore Identity is available, though neither post gives a specific regional count or a pricing change tied to the feature.

Why It Matters

I've watched this exact pattern play out with most of the major clouds at this point: a capability starts as something developers stitch together themselves, then the vendor absorbs it into the managed platform once enough customers have built (and rebuilt) the same plumbing. AWS is explicit that this is what's happening here, it says the portal removes "undifferentiated heavy lifting," and having read through the callback URL configuration AWS still requires (a separate callback for the corporate IdP, a separate return URL per gateway target, a separate callback per outbound provider), I'd call that a fair description of the problem, even if the setup is still a multi-step admin job rather than a single toggle.

The part that will actually get used day to day is the IDE and MCP client support. Naming Claude Code, Cursor, Kiro, and VS Code specifically in the post is a tell that AWS is chasing the coding agent workflow directly, where a user approves GitHub or Slack access once and every later tool call in that session or IDE reuses the stored token instead of interrupting the developer again.

The tradeoff nobody should skip past: this is an AWS hosted flow tied to AgentCore Gateway. It solves the callback infrastructure problem, but it also means the consent experience, the token vault, and the audit trail all live inside AWS's stack. That's a reasonable deal for teams already committed to Bedrock AgentCore. It's a lock in consideration for anyone weighing AgentCore against a portable, self hosted identity layer.

BriefFlash has covered how Ninth Wave built its seven agent Compass assistant on AWS Bedrock AgentCore to speed up bank onboarding, and this Consent portal addresses a piece of the same identity and access problem that a multi agent, multi tool deployment like that one runs into at scale.

What to Watch

AWS hasn't published adoption numbers or named early customers using the Consent portal specifically, so there's nothing yet to independently verify beyond the documentation and sample code AWS itself put out. Worth watching: whether AWS extends supported identity providers beyond JWT issuing OIDC providers, whether other clouds building competing agent platforms ship a comparable managed consent layer, and whether real deployments run into friction with the single portal per gateway limit as teams scale past a handful of agent tools.

Key Takeaways

  • Amazon Bedrock AgentCore Identity now offers a managed Consent portal that handles end-user OAuth consent and session binding for AI agents, confirmed in AWS's September 14, 2026 blog post and its September 1, 2026 What's New listing.
  • The portal replaces callback infrastructure developers previously built themselves, presenting the authorization URL, hosting a public HTTPS callback, and calling CompleteResourceTokenAuth, according to AWS.
  • It's built specifically for IDE and MCP client workflows, AWS names Claude Code, Cursor, Kiro, and VS Code, where agents can't natively present an OAuth consent screen mid session.
  • Constraints confirmed by AWS: one portal per gateway, only JWT issuing OIDC identity providers are supported for sign in, and manual reauthorization is required when a provider doesn't issue a refresh token.

FAQ

What is the Amazon Bedrock AgentCore Consent portal?

It's a managed, AWS hosted web portal, one per AgentCore Gateway, that lets end users sign in through their organization's identity provider, review which third party services an AI agent can access, and grant or withdraw OAuth consent for each one individually. AWS announced it in a September 14, 2026 blog post.

Does the Consent portal replace building my own OAuth callback infrastructure?

For the three legged OAuth (3LO) flow on AgentCore Gateway, yes, according to AWS. Previously, customers had to host their own public HTTPS callback, manage browser sessions, and call CompleteResourceTokenAuth themselves. The portal now handles browser redirects and session binding, and stores tokens in the AgentCore Identity token vault.

Which services and identity providers does the Consent portal support?

AWS's walkthrough configures GitHub and Slack as outbound OAuth targets, and its September 1, 2026 What's New post also names Salesforce. For sign in, the portal requires an OpenID Connect identity provider that issues JWT access tokens; AWS gives Okta and Auth0 as examples. Providers that only issue opaque access tokens aren't supported as the primary sign in provider.

Is there a limit on how many Consent portals I can create?

Yes. AWS confirms one Consent portal is allowed per AgentCore Gateway, and the gateway attached to a portal can't be changed after the portal is created.