User's blog

Novas capacidades do Amazon Bedrock AgentCore Gateway para MCP em produção

Written by

Make.com Service User

in

Um único ponto de entrada para servidores MCP corporativos

Quando uma organização começa a escalar o uso de servidores Protocolo de Contexto de Modelo (MCP) em produção, surgem desafios sérios: controle de acesso granular, visibilidade sobre quais equipes usam quais ferramentas, proteção contra vazamento de dados e gerenciamento centralizado de credenciais. Sem uma solução centralizada, cada servidor MCP precisa resolver esses problemas por conta própria.

O Amazon Bedrock AgentCore Gateway foi criado exatamente para resolver esse cenário. Ele atua como intermediário entre os servidores MCP e os clientes que os consomem, centralizando credenciais, observabilidade e conectividade segura em um único ponto confiável. A AWS anunciou recentemente uma expansão significativa desse serviço com novas capacidades voltadas para implantações MCP em ambientes corporativos.

As novidades cobrem: suporte estendido ao esquema de ferramentas MCP, prompts MCP e recursos MCP como primitivos de primeira classe, listagem dinâmica para descoberta em tempo de execução, streaming e gerenciamento de sessões para interações em tempo real, elicitação para solicitações de entrada durante a execução, e troca de tokens OAuth 2.0 on-behalf-of para autenticação delegada. Exemplos práticos estão disponíveis no repositório de amostras no GitHub.

Como o AgentCore Gateway centraliza a governança

Sem um gateway centralizado, cada servidor MCP construído pela organização precisa lidar individualmente com credenciais, aplicação de políticas, conectividade privada e logs. O servidor MCP de revisão de contratos do time jurídico, o de recuperação de dados do time financeiro e o de resposta a incidentes do time de operações — todos carregam o mesmo peso de infraestrutura. O time de segurança precisa revisar cada servidor separadamente, os desenvolvedores aguardam aprovações e ninguém tem uma visão unificada do uso da infraestrutura MCP.

O AgentCore Gateway elimina essa duplicação ao estabelecer um ponto de entrada único para todo o tráfego MCP. Cada equipe cuida apenas da lógica de negócio do seu servidor; o gateway trata do restante. Ele agrega capacidades de diferentes tipos de destino, incluindo servidores MCP, APIs REST, funções AWS Lambda e outros.

Entre os recursos de governança já disponíveis no AgentCore Gateway, destacam-se:

Primitivos MCP como cidadãos de primeira classe

O AgentCore Gateway passa a funcionar como um único endpoint MCP que agrega capacidades de todos os servidores MCP da organização. Os clientes enxergam um catálogo unificado de ferramentas, uma biblioteca de prompts e um namespace de recursos — sem precisar gerenciar 20 conexões separadas.

O gateway suporta os três primitivos MCP: ferramentas, prompts e recursos. As definições de ferramentas incluem um outputSchema opcional para definir a estrutura de saída esperada e anotações que descrevem propriedades comportamentais, como se a ferramenta é somente leitura ou destrutiva. O gateway também suporta os métodos MCP completos: tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read e resources/templates/list.

No modo de listagem padrão, o AgentCore Gateway descobre e armazena em cache as ferramentas, prompts e recursos dos servidores MCP conectados. Esse cache é atualizado implicitamente sempre que se chama CreateGatewayTarget ou UpdateGatewayTarget, e pode ser atualizado explicitamente com a API SynchronizeGatewayTargets. Quando os clientes fazem chamadas de listagem, o gateway responde diretamente do cache. A interação real com o servidor MCP só ocorre durante operações de invocação: tools/call, prompts/get e resources/read.

Ferramentas e prompts retornados pelo gateway recebem o prefixo do nome do destino no formato targetName___. URIs de recursos são retornados sem prefixo — o URI original do servidor MCP é repassado diretamente. Um ponto de atenção importante: como os URIs de recursos não são validados pelo gateway, é preciso ter cuidado com destinos não confiáveis, pois um servidor MCP comprometido poderia retornar URIs apontando para endpoints internos ou caminhos do sistema de arquivos local.

Listagem dinâmica para controle de acesso por usuário

Alguns servidores MCP personalizam suas capacidades por usuário. Um servidor com controle de permissões pode expor a ferramenta approve_expense apenas para gerentes, ou um servidor multi-tenant pode disponibilizar ferramentas compatíveis com HIPAA somente para clientes de saúde. A listagem dinâmica permite preservar esse controle de acesso no lado do servidor, mesmo roteando pelo AgentCore Gateway.

Ao criar um destino, é possível escolher entre dois modos de listagem: padrão e dinâmico.

  • Modo padrão: o gateway invoca o servidor MCP durante CreateGatewayTarget ou UpdateGatewayTarget para descobrir e armazenar em cache ferramentas, prompts e recursos. Chamadas de listagem são respondidas diretamente do cache.
  • Modo dinâmico: o gateway não invoca o servidor durante a criação ou atualização do destino. As chamadas de listagem são encaminhadas em tempo real ao servidor MCP, usando a identidade do usuário que está fazendo a chamada.

Em ambos os modos, operações de invocação como tools/call, prompts/get e resources/read são roteadas diretamente ao servidor MCP de destino.

Imagem original — fonte: Aws

Essa arquitetura dual também oferece flexibilidade para multi-tenancy e controle de acesso granular (FGAC). Para o modo dinâmico, o controle de acesso pode ser gerenciado diretamente no servidor MCP, já que as operações de listagem são executadas sob a identidade do usuário final. Vale observar que, no modo dinâmico, os primitivos não são indexados no gateway, o que significa que a capacidade de busca semântica de ferramentas não pode ser utilizada.

Streaming, gerenciamento de sessões e elicitação

Muitos fluxos de trabalho MCP corporativos vão além de simples chamadas de requisição-resposta. Um servidor MCP pode precisar transmitir atualizações de progresso enquanto gera um relatório, pausar no meio da execução para pedir aprovação do usuário antes de uma ação sensível, ou manter contexto ao longo de uma conversa com múltiplos passos. O AgentCore Gateway agora suporta transporte HTTP com streaming, gerenciamento de sessões MCP e elicitação.

HTTP com Streaming

Sem streaming, uma chamada de ferramenta que leva 45 segundos não retorna nada até o final. Com streaming, o usuário vê eventos de progresso em tempo real. Quando um cliente envia uma requisição tools/call com Accept: application/json, text/event-stream, o AgentCore Gateway abre um stream SSE (Eventos Enviados pelo Servidor) e encaminha eventos do servidor MCP em tempo real, incluindo notificações de progresso, mensagens de log e o resultado final da ferramenta. Clientes que enviam apenas Accept: application/json continuam recebendo uma única resposta JSON, preservando compatibilidade retroativa.

Para habilitar o streaming, basta configurar o bloco enableResponseStreaming na chamada de API CreateGateway ou UpdateGateway:

"protocolConfiguration": {
  "mcp": {
    "streamingConfiguration": {
      "enableResponseStreaming": true
    }
  }
}

Um ponto de atenção: o AgentCore Gateway determina o código de status HTTP a partir do primeiro evento do stream. Se ocorrer um erro no meio do stream, ele é entregue como um objeto de erro JSON-RPC dentro de um frame SSE, e não como um código de status HTTP.

Gerenciamento de Sessões

O gerenciamento de sessões introduz fluxos de trabalho com múltiplos turnos ao AgentCore Gateway. Quando as sessões são habilitadas, o gateway gera um Mcp-Session-Id na primeira requisição de inicialização e o retorna como cabeçalho de resposta. O cliente inclui esse cabeçalho nas requisições subsequentes, permitindo que o gateway rastreie interações, mantenha mapeamentos para sessões de servidores MCP downstream e correlacione requisições de elicitação entre chamadas de ferramentas.

Para habilitar sessões, adiciona-se um bloco sessionConfiguration na chamada de API CreateGateway ou UpdateGateway. O tempo limite de sessão pode ser configurado de 15 minutos a 8 horas, com padrão de 1 hora:

"protocolConfiguration": {
  "mcp": {
    "sessionConfiguration": {
      "sessionTimeoutInSeconds": 3600
    }
  }
}

As sessões são escopadas ao usuário autenticado. O gateway deriva a identidade do usuário a partir do contexto de autorização — token JWT bearer para ingresso OAuth ou credenciais IAM para ingresso AWS_IAM — e valida que cada requisição dentro de uma sessão se origina do mesmo usuário, ajudando a prevenir sequestro de sessão. O gateway retorna HTTP 400 se receber uma requisição sem o cabeçalho Mcp-Session-Id, e HTTP 404 para sessões expiradas ou inexistentes.

Elicitação

A elicitação permite que servidores MCP por trás do AgentCore Gateway pausem a execução e solicitem entrada do usuário final. Isso é especialmente valioso para operações de alto risco que exigem confirmação explícita do usuário, coleta de dados estruturados ou autenticação fora de banda antes de prosseguir.

O AgentCore Gateway suporta três modos de elicitação:

  • Modo formulário: o servidor MCP envia um JSON Schema descrevendo os campos necessários, e o cliente renderiza um formulário para o usuário preencher.
  • Modo URL: o servidor envia uma URL que o cliente abre para o usuário — tipicamente uma tela de consentimento OAuth ou um fluxo de aprovação externo.
  • Modo exceção URL: o servidor retorna um URLElicitationRequiredError contendo uma URL, solicitando que o cliente redirecione o usuário e tente novamente após a conclusão do fluxo externo.

A elicitação requer que tanto o streaming quanto as sessões estejam habilitados no gateway. O AgentCore Gateway respeita a negociação de capacidades — ele só declara suporte à elicitação para um servidor MCP downstream quando o cliente conectado também declarou suporte durante a inicialização. O gateway também suporta múltiplas elicitações ativas por sessão, permitindo que chamadas de ferramentas concorrentes tenham cada uma sua própria elicitação pendente.

Troca de tokens OAuth 2.0 on-behalf-of

Quando agentes precisam acessar recursos downstream em nome de usuários autenticados, o AgentCore Gateway suporta troca de tokens OAuth 2.0 on-behalf-of (OBO) por meio do AgentCore Identity. Isso habilita um modelo de autenticação zero-trust onde a identidade original do usuário é preservada e propagada em cada salto da cadeia de requisições, enquanto cada camada recebe um token escopado precisamente para sua audiência pretendida.

O fluxo funciona assim: o cliente MCP se autentica no AgentCore Gateway com JWT A, escopado para a audiência do gateway (aud: gw). Quando o gateway precisa chamar um servidor MCP downstream, ele chama o AgentCore Identity para trocar JWT A por JWT B, agora escopado para a audiência do servidor MCP (aud: mcp). Se o servidor MCP precisar chamar uma API ainda mais downstream, pode usar GetResourceOAuth2Token para obter JWT C escopado para essa API (aud: api). Em cada salto, a identidade original do usuário (sub: X) é mantida, permitindo que serviços downstream apliquem autorização granular por usuário sem disparar fluxos de consentimento adicionais.

O AgentCore Identity atua como o broker central de tokens para todo esse fluxo. Ele fornece um cofre seguro de tokens para armazenar credenciais OAuth e segredos de cliente, além de suportar identidade de carga de trabalho para autenticação serviço a serviço usando identidade de carga de trabalho AWS em vez de segredos de longa duração. Suporta troca de tokens padrão (RFC 8693) ou concessão de autorização JWT (RFC 7523), dependendo do provedor de identidade.

Adoção incremental sem quebrar o que já funciona

Com essas novidades, é possível construir fluxos de trabalho agênticos com múltiplos turnos com streaming de progresso em tempo real, gates de aprovação humana que pausam e retomam a execução, e propagação de identidade zero-trust — tudo por meio de um único endpoint gerenciado. Sem stores de sessão customizados, sem infraestrutura de streaming manual, sem credenciais de conta de serviço compartilhadas.

Para começar, a AWS recomenda consultar a documentação do Amazon Bedrock AgentCore Gateway para detalhes de configuração de cada recurso. Para exemplos práticos, o repositório de amostras no GitHub é o ponto de partida. Quem já executa servidores MCP por trás do AgentCore Gateway pode adotar essas capacidades de forma incremental, sem alterações nas configurações existentes do gateway ou dos destinos.

Fonte

Extending MCP support for Amazon Bedrock AgentCore Gateway (https://aws.amazon.com/blogs/machine-learning/extending-mcp-support-for-amazon-bedrock-agentcore-gateway-2/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts