AgentCore Identity Consent Portal: A UK Playbook for User-Delegated Agent Access
September 2026 adds an AWS-hosted Consent Portal for Amazon Bedrock AgentCore Identity so users can grant OAuth access without the browser holding tokens. Here is the UK IdP and gateway checklist.
September 2026 adds an AWS-hosted Consent Portal for Amazon Bedrock AgentCore Identity so users can grant OAuth access without the browser holding tokens. Here is the UK IdP and gateway checklist.
- Consent Portal is an AWS-hosted OIDC consent UX attached to one AgentCore Gateway; tokens stay server-side.
- Requires JWT inbound auth on the gateway and an IdP that includes the openid scope.
- UK GDPR programmes need clear scopes, revoke runbooks and audit evidence — not custom token-holding frontends.
- 14-day path: IdP → gateway → portal → one agent → DPO/cyber assurance (pair with Evaluations for TypeScript too).
User-delegated agent access needs a real consent UX
UK teams are wiring Amazon Bedrock AgentCore agents to SaaS and internal APIs with OAuth. Machine-to-machine scopes are the easy part. The hard part is on-behalf-of access: an end user must grant consent before the agent touches their mailbox, CRM or IdP-protected API — without dumping tokens into the browser or inventing a custom consent app.
September 2026 brings AgentCore Identity Consent Portal: an AWS-hosted portal that authenticates users to your OIDC IdP and collects consent before the agent proceeds. The OAuth flow stays server-side; the browser never holds the token.
Cloud security and identity
This is a UK-oriented enablement note for platform, IAM and cyber leads — not a console walkthrough.
What the Consent Portal is (and is not)
A consent portal:
- Attaches to a single AgentCore Gateway (its source)
- Uses an OAuth2 credential provider tied to the same IdP the gateway’s inbound JWT authorizer trusts
- Requires the IdP’s permitted scopes to include
openid - Is managed with create / get / list / update / delete consent-portal APIs (plus console)
It is not a replacement for gateway policy, Bedrock Guardrails, or your Entra ID / Okta conditional access. It is the human consent surface for delegated agent access.
Why UK boards should care this month
| Pressure | Why Consent Portal helps |
|---|---|
| GDPR / UK GDPR lawful basis and transparency | Clear, hosted consent step before agent OBO calls |
| Shadow “login with Google then paste token” hacks | Tokens stay server-side in AgentCore Identity |
| Multi-agent sprawl on one gateway | Portal scoped to a gateway; targets configurable |
| Audit for cyber and DPO | Consent becomes a first-class Identity operation, not a custom React page |
Pair this with September’s other AgentCore update: Evaluations now score TypeScript agents (Strands, LangGraph, OpenAI Agents, Vercel AI SDK). Consent without quality gates is still risky — but consent without a portal is how programmes stall in legal review.
Reference architecture
End user browser
│ redirect to portalUrl
▼
Consent Portal (AWS-hosted)
│ OIDC to Entra ID / Okta / Cognito (openid + resource scopes)
▼
AgentCore Identity (credential provider)
│
▼
AgentCore Gateway (JWT inbound auth)
│ policy + optional Guardrails
▼
Downstream APIs / MCP / SaaS (user-delegated token)
Hard requirements before you create a portal:
- Gateway exists with JWT inbound authentication
- IdP app registration allows the portal redirect and includes
openid - Execution role / IAM for consent-portal operations agreed with cloud platform
- Target configuration — which downstream resources the portal may grant
- Runbook for revoke / delete portal when a programme ends
14-day UK rollout checklist
| Day | Focus | Exit criteria |
|---|---|---|
| 1–2 | IdP | App registration, redirect URIs, openid + least-privilege scopes documented |
| 3–4 | Gateway | JWT authorizer trusts same issuer; non-prod gateway only |
| 5–7 | Portal | Create portal, attach target, test happy-path consent and deny |
| 8–10 | Agent | One AgentCore agent/runtime path that only proceeds after consent |
| 11–14 | Assurance | DPO/cyber review, CloudTrail evidence, revoke test, TypeScript or Python eval smoke |
Design rules that survive UK cyber review
- One portal per gateway programme — do not share a prod portal across unrelated agent products.
- Scopes are product decisions — “read mail” is not the default; name the business purpose.
- Consent is not authorisation forever — define re-consent and token lifetime with IAM.
- Fail closed — if the portal or IdP is down, agents must not fall back to stored user passwords.
- Measure consent completion and denial rates — high denial means your UX or scope ask is wrong.
Common failure modes
- Pointing the portal at a different IdP than the gateway JWT issuer
- Asking for broad scopes “for future agents” and failing legal review
- Building a custom consent page that holds tokens in localStorage
- Enabling Consent Portal in prod before gateway rate limits and policy exist
- Ignoring TypeScript agent estates now that Evaluations supports them — still unmeasured
Bottom line
AgentCore Runtime and Gateway get agents running. Consent Portal is how UK organisations let those agents act as the user without inventing another OAuth micro-frontend. Put it on the critical path of every OBO agent programme this quarter.
AIATS helps UK teams design AgentCore Identity, gateway policy and evaluation gates together.
OBO agents without a hosted consent path stall in legal review. Wire Consent Portal to the same IdP as your gateway JWT, keep scopes minimal, and fail closed.
