A Amazon Web Services colocou no ar, em 14 de setembro de 2026, um novo recurso do Amazon Bedrock AgentCore Identity: o Consent portal. É uma experiência web gerenciada que organiza o consentimento OAuth de usuários finais para agentes de inteligência artificial.
A companhia também apresentou um endpoint de session binding voltado ao AgentCore Gateway.
A proposta é resolver um problema que vinha ficando caro para quem opera agentes corporativos. Associar, de forma segura, cada autorização OAuth à pessoa que realmente aprovou o acesso.
O gargalo que existia antes
Agentes de IA frequentemente precisam acessar serviços como GitHub e Slack em nome de um usuário. Antes que o agente possa agir, é preciso que a pessoa se autentique no provedor.
E que aprove explicitamente o acesso solicitado. A aplicação precisa amarrar a concessão resultante ao usuário correto, processo conhecido como session binding.
No fluxo de OAuth de três pernas (3LO), também chamado de authorization code flow, clientes do AgentCore Identity tinham de construir e hospedar a própria infraestrutura de vinculação de sessão. Isso incluía exibir a URL de autorização, manter um callback HTTPS público, autenticar o usuário que retorna, gerenciar sessões de navegador e chamar CompleteResourceTokenAuth para fechar o ciclo.
Muita engenharia para uma etapa que, do ponto de vista do negócio, deveria ser apenas uma tela de consentimento.
Como o consent portal funciona
Com o novo portal, o administrador cria um portal para um gateway e compartilha o endereço com os usuários. A pessoa se autentica no provedor de identidade da própria organização, revisa quais serviços estão disponíveis para o agente e concede consentimento provedor por provedor.
O portal cuida dos redirecionamentos de navegador e do session binding. O AgentCore Identity guarda os tokens resultantes em seu token vault.
A arquitetura usa a execution role do IAM para descobrir os targets configurados no gateway antes de apresentar as conexões ao usuário.
O cenário descrito no material da AWS é o da fictícia Example Corp, que oferece um assistente de programação com IA aos seus desenvolvedores por meio de um AgentCore Gateway. O agente tem dois destinos: um target do GitHub, capaz de listar repositórios e criar issues, e um target do Slack, que lista canais públicos e publica mensagens.
O administrador configura o IdP corporativo, os dois targets, a execution role e o portal. O desenvolvedor abre a URL, entra com as credenciais corporativas e conecta cada provedor quando precisar.
Onde isso encaixa no dia a dia
O recurso foi pensado especialmente para agentes acessados por IDEs e clientes de Model Context Protocol (MCP), como Kiro, Claude Code, Cursor e Visual Studio Code. O usuário pode conceder consentimento antes de invocar uma ferramenta. As chamadas seguintes reaproveitam o token já armazenado para aquela pessoa, sem novos prompts repetidos.
Há pré-requisitos. A organização precisa de uma conta AWS com acesso ao Amazon Bedrock AgentCore, de um gateway configurado com autorização de entrada JWT, de um IDE ou cliente MCP apontando para esse mesmo gateway, de acesso administrativo ao IdP corporativo, de um GitHub OAuth App e de um app Slack registrados para desenvolvimento ou teste.
Também é preciso permissão para cadastrar a URL de callback do AgentCore Identity em cada provedor. É possível acompanhar a atividade resultante no AWS CloudTrail.
Por que isso importa
Consentimento em agentes de IA é um problema menos glamouroso que capacidade de modelo, mas igualmente decisivo para adoção corporativa. Sem rastreabilidade, um agente que cria issues no GitHub ou publica no Slack em nome de alguém se transforma em risco de auditoria.
Ao mover a vinculação de sessão para um serviço gerenciado e guardar tokens por usuário, a AWS reduz a superfície de implementação própria. E concentra o controle onde ele costuma ser exigido: no provedor de identidade da empresa.
Para equipes que já operam gateways com múltiplos targets, o ganho imediato é operacional. Menos código de integração, menos endpoints públicos mantidos internamente e um fluxo de consentimento padronizado entre provedores distintos.
A contrapartida é a dependência de mais uma camada gerenciada da plataforma, o que reforça a importância de revisar políticas de IAM e o registro de eventos no CloudTrail.
Fontes e links
- AWS
- Guia de introdução ao Amazon Bedrock AgentCore
- Quick start do AgentCore Gateway
- Autorização de entrada JWT no gateway
- Criação de um GitHub OAuth App
- Instalação de apps Slack com OAuth
