Amazon Bedrock AgentCore Adds a Consent Portal for AI Agents

Your agent wants to open a GitHub issue, post to Slack, and update a Salesforce record, all on behalf of a user who hasn't agreed to any of it. Making that consent real used to mean building your own OAuth callback server, session binding, and token storage. AWS just shipped a way to stop doing that yourself.

What shipped

Amazon Bedrock AgentCore Identity now offers a managed consent portal: a hosted, AWS-run page that authenticates end users against your OIDC identity provider and collects explicit approval before an agent accesses a downstream resource in their name. Each portal attaches to one AgentCore Gateway and reuses the same identity provider the gateway's inbound JWT authorizer already trusts, so you're not standing up a second identity system just for consent.

The flow stays server-side. The browser never holds a token; AgentCore stores and refreshes it in its own token vault. Users sign in once, then see a Connections page listing every outbound provider the gateway talks to (AWS's examples are GitHub and Slack, and the architecture covers any OAuth2 authorization-code vendor, including Atlassian and LinkedIn). Each grant is independent: approving GitHub doesn't approve Slack, and users can revisit the page later to manage what they've connected.

This is the latest piece of AgentCore Identity to go GA as AWS rolls the suite out feature by feature through 2026.

Why this matters for an FDE

The part of "agent talks to third-party systems on a user's behalf" that nobody enjoys building is exactly the part with the most liability: who approved this, what exactly did they approve, and how do you prove it later. A homemade OAuth callback page is not the artifact you want sitting between your agent and a customer's GitHub org.

A managed, per-gateway consent surface also changes a UX conversation that usually goes badly. "Trust the agent with everything" and "ask for approval on every tool call" are both wrong answers: the first is a security incident waiting to happen, the second trains users to click through prompts without reading them. A one-time, resource-scoped consent grant that the user can review and revoke is the middle path, and now it's AWS's job to host it instead of yours.

Setting up a consent portal

Creating one is a control-plane API call once you've registered an OAuth2 credential provider for your IdP and an execution role for the portal:

aws bedrock-agentcore-control create-consent-portal \
    --name "my-consent-portal" \
    --execution-role-arn "arn:aws:iam::<account-id>:role/<execution-role-name>" \
    --idp-config '{
        "credentialProviderArn": "arn:aws:bedrock-agentcore:<region>:<account-id>:token-vault/default/oauth2credentialprovider/<credential-provider-id>",
        "scopes": ["openid", "email", "profile"],
        "audience": "<audience>"
    }' \
    --sources '[{
        "identifier": "<gateway-id>",
        "type": "agentcore-gateway"
    }]'

Poll get-consent-portal until status is ACTIVE to get the portalUrl, then register <portalUrl>/callback as a redirect URI on your IdP application (Cognito calls this Allowed callback URLs, Okta calls it Sign-in redirect URIs). Only then is the portal ready to share with end users.

Gotchas

A few details from AWS's own docs will bite you if you skip them:

• openid is mandatory. A consent portal always requests the openid scope in addition to whatever you list, and every scope you configure has to already be enabled on the IdP or the flow fails with invalid_scope.
• No trailing slash on the callback URL. <portalUrl>/callback with a trailing slash gets rejected by the IdP as an unregistered redirect.
• An empty portal means no targets, not a bug. If the gateway has no outbound targets configured yet, the consent page loads with nothing on it. Configure at least one target before you hand the link to a real user.
• One portal per gateway. If your agent fans out across multiple gateways for different customer segments, you're managing multiple consent portals, not one shared surface.

What to do Monday morning

If you've already got an agent acting on a user's behalf against GitHub, Slack, or a similar OAuth2-gated service through AgentCore Gateway, spend half a day standing up a consent portal in a dev account and see whether it replaces whatever callback handler you built to get the demo working. If you're earlier in the build, skip writing that handler at all and design consent around this from day one, because retrofitting a security-sensitive flow after it's in front of customers is worse.

Getting agent permissions right in production is still mostly a UX problem wearing a security costume, and this is one fewer piece of that costume you have to sew yourself.