AWS mostra como rodar proxies MCP customizados serverless no Bedrock AgentCore Runtime

A AWS publicou um walkthrough técnico mostrando como subir um proxy MCP (Model Context Protocol) customizado e serverless rodando no Amazon Bedrock AgentCore Runtime. A ideia: dar pra times uma camada programável entre o agente e o servidor MCP upstream, onde dá pra meter lógica de governança sem refatorar nada do que já existe.

O problema que motiva: quando agentes de IA conectam em ferramentas via MCP, em produção você precisa de governança, controle e observabilidade. Sanitizar input antes de chegar no backend, gerar audit trail num formato específico, redactar dado sensível na camada de protocolo. Cada empresa tem regra diferente, vinda de compliance interno, regulação setorial e particularidades do ambiente.

Por que não usar só o Gateway

O Amazon Bedrock AgentCore Gateway já oferece governança centralizada (descoberta semântica de tool, gestão de credencial, enforcement de policy) e suporta Lambda interceptors pra rodar código customizado em cada invocação de tool.

Só que tem caso onde Lambda não serve: empresa que já tem lógica de filtragem MCP acoplada a biblioteca interna ou sistema de compliance on-prem, e não quer refatorar pra Lambda. Ou ambiente híbrido onde rodar o controle como MCP server standalone dá mais portabilidade que um interceptor preso ao sistema.

É um padrão complementar, não substituto. Se sua lógica cabe em Lambda, Lambda interceptor é mais simples. O proxy entra quando você precisa carregar bagagem que não migra fácil.

Como o proxy funciona

A implementação usa FastMCP. Na inicialização, o proxy manda um tools/list padrão pro servidor upstream e recebe o catálogo completo de tools. Pra cada tool, registra dinamicamente uma versão local com o mesmo nome e descrição, com handler que encaminha o tools/call pro upstream e devolve a resposta.

O proxy não define tool própria nem sabe de antemão o que o upstream expõe. Pro cliente MCP, é indistinguível de um servidor MCP normal. Como é um servidor Python que você possui e implanta, dá pra injetar lógica antes de encaminhar a chamada ou depois de receber a resposta.

Autorização em três camadas

A autorização é independente em cada camada, criando fronteiras de confiança bem definidas:

• Agente → proxy MCP: usa AgentCore Identity, mesmo framework que você já usa pros outros workloads no Runtime.
• Proxy → servidor MCP upstream: depende do que o upstream exige. AgentCore Identity suporta IAM via AWS SigV4 e JWT via OAuth 2.0 client credentials. No projeto do GitHub, o default é IAM. Se for IAM e o upstream for outro AgentCore Runtime, escopa bedrock-agentcore:InvokeAgentRuntime. Se for AgentCore Gateway, escopa bedrock-agentcore:InvokeGateway pra gateways e identidades específicas.
• Servidor upstream → tools: usa credential providers do AgentCore Identity, que gerencia OAuth 2.0, API keys e rotação de credencial de forma transparente.

Pré-requisitos

• Ambiente Linux ou macOS com Python 3.12+
• AWS CLI configurada com permissão pra criar IAM role, mexer no Amazon ECR e invocar APIs do Bedrock AgentCore
• AgentCore starter toolkit instalado
• Docker (a CLI usa pra buildar a imagem do container)
• Endpoint MCP upstream (no walkthrough, um AgentCore Gateway com pelo menos um target registrado)
• Se for OAuth: Cognito user pool com domain configurado e app client com client credentials grant

Deploy

Clona o repo, ajusta deploy_config.json com gateway_endpoint, region, gateway_api_id (opcional, pra escopar IAM em recurso específico) e auth_mode (iam ou jwt). Aí roda setup_and_deploy.py, que valida pré-requisitos, cria o IAM execution role com trust policy pra bedrock-agentcore.amazonaws.com, configura o agente via agentcore configure apontando pra mcp_proxy/main.py, e dispara o agentcore launch passando o endpoint upstream como variável de ambiente.

Pra checar status: agentcore status --agent mcp_proxy. O ARN do agente sai no output, e é o que o cliente de teste vai usar pra invocar o proxy.

Customizações que o padrão habilita

O post mostra dois padrões concretos:

Tokenização de PII: dentro do _make_tool_handler em main.py, antes de chamar _send_gateway_request, varre os kwargs procurando padrões de PII (Personally Identifiable Information, dado pessoal identificável) e troca por tokens reversíveis. Depois que o upstream responde, reverte os tokens antes de devolver pro cliente. Mantém PII fora dos backends sem quebrar o fluxo do agente.

Controle de acesso por tool: mesmo que o upstream exponha o catálogo todo, dá pra adicionar um policy check no início do handler. Avalia a identidade do caller (extraída dos headers ou do contexto da sessão MCP) contra uma policy de acesso. Se não autorizado, devolve erro sem nem contatar o upstream. Também dá pra filtrar a resposta de tools/list na função register_gateway_tools pra que tools não autorizadas nem apareçam no catálogo do cliente.

Teste

O repo inclui test_agent.py, um script Strands Agents que conecta no proxy (não no upstream direto) invocando o endpoint do AgentCore Runtime. Manda requests MCP JSON-RPC pra descobrir e chamar tools. No exemplo do walkthrough, o upstream expõe operações aritméticas e o agente vira uma calculadora.

Limpeza

Pra evitar cobrança recorrente: agentcore destroy --agent <nome> --delete-ecr-repo --force, depois apaga inline policy e role via aws iam delete-role-policy e aws iam delete-role. Se criou um Gateway só pro teste, agentcore gateway delete-mcp-gateway --name <gateway> --force.

Pra quem opera agentes em produção e tem requisito de compliance que não cabe em Lambda, esse padrão vale o estudo. O código aberto no GitHub reduz bastante o custo de prototipar antes de decidir se compensa o overhead de manter um proxy próprio.