AWS mostrou como conectar servidores MCP protegidos por OAuth ao Bedrock AgentCore Gateway

AWS mostrou como conectar servidores MCP protegidos por OAuth ao Amazon Bedrock AgentCore Gateway através do fluxo Authorization Code. O cenário é projetado para equipes que precisam de logon único para agentes de IA em ferramentas corporativas sem tokens incorporados e sem configuração manual de cada integração.

Por que o Amazon Bedrock AgentCore Gateway é Necessário

A AWS posiciona o Gateway como o ponto central através do qual agentes e clientes MCP obtêm acesso às ferramentas dentro da empresa. Em vez de configurar cada servidor MCP separadamente em um IDE, a equipe pode dar aos desenvolvedores uma única URL do Gateway e regras de acesso unificadas. A AWS move autenticação, observabilidade e controle de políticas de acesso para esta camada, de modo que as conexões às ferramentas não cresçam em um conjunto de configurações manuais dispersas.

Isso é especialmente relevante para empresas onde os servidores MCP se multiplicam: serviços internos próprios, GitHub, Salesforce, Databricks e outros sistemas externos. Muitos desses servidores são protegidos por OAuth 2.0 e exigem que o agente atue em nome de um usuário específico.

Nesse esquema, o Gateway alivia as aplicações de trabalho extra: não há necessidade de incorporar credenciais no código, atualizar tokens independentemente ou repetir a mesma lógica para cada conector.

Dois Modos de Conexão

No artigo, a AWS mostra duas formas de conectar um servidor MCP protegido por OAuth ao Gateway. A primeira é sincronização implícita ao criar um target: o administrador passa pelo fluxo Authorization Code durante CreateGatewayTarget, UpdateGatewayTarget ou SynchronizeGatewayTargets, após o que o Gateway lê a lista de ferramentas e a armazena em cache. A segunda é fornecer o esquema de ferramentas antecipadamente sem aguardar uma solicitação em tempo real ao servidor durante a criação do target. A AWS nomeia diretamente a segunda opção como preferida nos casos em que o envolvimento humano em criar ou atualizar não é possível.

• A sincronização implícita requer que o admin complete a autorização e dê ao Gateway acesso ao servidor MCP já na fase de configuração.
• O esquema pré-definido permite inserir imediatamente a lista de ferramentas e obter um target pronto sem autorização ao criar.
• No modo com esquema antecipado, você não pode usar SynchronizeGatewayTargets, porque o Gateway se baseia na descrição fornecida e não na leitura em tempo real do servidor.
• Os usuários do Gateway podem executar tools/list sem fazer login em cada servidor, porque as definições de ferramentas já estão no cache.
• A autorização é acionada apenas quando o usuário realmente chama a ferramenta necessária através de tools/call.

Como exemplo, a AWS usa o servidor MCP do GitHub. Para tal cenário, você precisa de um Gateway na versão MCP 2025-11-25 ou mais recente, caso contrário a opção Authorization code grant 3LO não estará disponível. A configuração também especifica a URL de retorno: é para onde o usuário ou administrador retorna após a tela de consentimento, e então a aplicação conclui a troca através de CompleteResourceTokenAuth.

Como Funciona a Autorização

A parte-chave do esquema é a vinculação do AgentCore Gateway e AgentCore Identity. Primeiro, o Gateway obtém um token de acesso de workload, confirmando que tem direito de solicitar credenciais em nome de sua workload. Em seguida, através de um provedor de credencial, ele recebe um token de acesso pronto ou a URL de autorização e URI de sessão se um token ainda não foi emitido para um usuário específico. Na fase inicial de configuração do target, por causa disso, ele pode acabar no status Needs authorization, e após concluir o consentimento passar para Ready com rótulo Authorized.

A AWS enfatiza separadamente URL session binding. O mecanismo verifica que a autorização foi iniciada e concluída pelo mesmo usuário, não por alguém que acidentalmente recebeu um link encaminhado. Após o consentimento, o navegador retorna ao callback, a aplicação passa o URI de sessão e identidade do usuário para CompleteResourceTokenAuth, e apenas após essa verificação ocorre a troca do código de autorização por token de acesso. De acordo com a AWS, o link de autorização e o URI de sessão vivem por 10 minutos, o que restringe ainda mais a janela para abuso.

Para o usuário final, a lógica é mais simples. A solicitação tools/list é servida do cache do Gateway e não força você a fazer login em todos os sistemas conectados antecipadamente. Mas tools/call já inicia o fluxo Authorization Code apenas para aquele servidor MCP cuja ferramenta está sendo realmente chamada. Após o login bem-sucedido, o token é armazenado em cache no Token Vault na vinculação de identidade workload e identidade do usuário, portanto chamadas subsequentes passam sem nova autorização enquanto o token permanecer válido.

O Que Isso Significa

A AWS está movendo MCP de um conjunto de integrações pontuais para uma camada corporativa gerenciada. Para equipes que constroem sistemas de agentes em múltiplas ferramentas externas e internas, isso reduz o caos nos acessos: o catálogo de ferramentas pode ser exibido centralmente, e a autorização do usuário pode ser ativada apenas no momento da invocação real do servidor necessário.