AWS has added a managed Consent portal to Bedrock AgentCore for OAuth access by AI agents
AWS has added a managed Consent portal to Bedrock AgentCore Identity that handles OAuth session binding for AI agents without the need to host your own HTTPS callback. It integrates with the IDE tools Claude Code, Cursor, Visual Studio Code and Kiro.
Amazon Web Services has expanded AgentCore Identity, part of the Amazon Bedrock AgentCore platform, with a managed Consent portal for OAuth session binding in AgentCore Gateway. The portal allows users to sign in through a corporate Identity Provider, review the services available to a given AI agent and grant consent for access to individual providers (e.g. GitHub or Slack). According to AWS, the portal itself handles browser redirects and session binding, and stores the resulting tokens in the token vault in AgentCore Identity.
According to AWS, customers using the three-step OAuth flow (3LO) in AgentCore Identity previously had to build and operate their own infrastructure for session binding – including presenting the authorization URL, hosting a public HTTPS callback, authenticating the returning user and managing browser sessions. The new portal removes this need. According to AWS, the feature is intended primarily for agents accessible through IDEs and MCP clients such as Kiro, Claude Code, Cursor and Visual Studio Code, where the user grants consent once and subsequent tool calls then use the token already stored.
Consent portal builds on the previously introduced Amazon Bedrock AgentCore Gateway, which is intended to serve as a centralized entry point for AI agents to access corporate tools. The platform also includes AgentCore Policy for defining and enforcing security rules, integration with Amazon Bedrock Guardrails to protect security and privacy, and AWS Agent Registry for cataloging tools. According to AWS, without centralization, a team with 10 AI assistants connected to 5 internal APIs must manually maintain 50 independent access configurations.
Why it matters
According to AWS, this means companies deploying AI agents with access to corporate systems (GitHub, Slack and similar tools) do not have to build and operate OAuth infrastructure themselves to bind a session between the user and the access granted – this part is handled by a managed portal connected to a corporate Identity Provider. For developers working with AI assistants through IDEs, this effectively means granting consent once instead of receiving repeated sign-in prompts every time they use a tool.
What was added since the original report
Verified updates
-
Bedrock AgentCore Identity now offers a managed Consent portal for OAuth session binding; The portal eliminates the need to host a public HTTPS callback and handle user authentication; Consent portal authenticates users through a corporate Identity Provider and manages session binding; Integrates with IDE clients: Claude Code, Cursor, Visual Studio Code, Kiro; Removes the need to build and manage your own OAuth infrastructure for applications
- Bedrock AgentCore Identity now offers a managed Consent portal for OAuth session binding
- The portal eliminates the need to host a public HTTPS callback and handle user authentication
- Consent portal authenticates users through a corporate Identity Provider and manages session binding
- Integrates with IDE clients: Claude Code, Cursor, Visual Studio Code, Kiro
- Removes the need to build and manage your own OAuth infrastructure for applications
Two audiences, two different impacts
What this means
For individuals
Developers who use AI assistants such as Claude Code, Cursor, Visual Studio Code or Kiro connected to Bedrock AgentCore at work will grant consent for access to tools (e.g. GitHub, Slack) once through the portal instead of receiving repeated OAuth prompts with every tool call.
More practical updates →For a business
According to AWS, companies deploying AI agents with access to corporate tools can avoid developing and operating their own OAuth session-binding infrastructure (a public HTTPS callback, user session management) and instead centralize authentication through a corporate Identity Provider and token storage in a single managed portal.
Risks and complianceCheck the original
Event sources
only one source so far · 1 publisher, 0 independent. We count feeds from the same owner only once.