Phase 13 - Lesson 17

Gateways e Registros de MCP — Planos de Controle Empresariais

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

As empresas não podem permitir que cada desenvolvedor instale servidores MCP aleatórios. Um gateway centraliza autenticação, RBAC, auditoria, limitação de taxa, cache e detecção de envenenamento de ferramentas, expondo então a superfície de ferramentas mesclada como um único endpoint MCP. O Registro Oficial de MCP (Official MCP Registry, mantido por Anthropic + GitHub + PulseMCP + Microsoft, com verificação de namespace) é o upstream canônico. Esta lição descreve onde um gateway se encaixa, percorre uma implementação mínima e analisa o cenário de fornecedores de 2026.

Tipo: Learn Linguagens: Python (stdlib, minimal gateway) Pré-requisitos: Fase 13 · 15 (tool poisoning), Fase 13 · 16 (OAuth 2.1) Tempo: ~45 minutos

Objetivos de Aprendizado

  • Explicar onde um gateway MCP se posiciona (entre os clientes MCP e múltiplos servidores MCP de backend).
  • Implementar as cinco responsabilidades do gateway: auth, RBAC, audit, rate limit, policy.
  • Impor um manifesto de hash de ferramenta fixado (pinned-tool-hash manifest) na camada do gateway.
  • Diferenciar o Registro Oficial do MCP de metarregistros (Glama, MCPMarket, MCP.so, Smithery, LobeHub).

O Problema

Uma empresa da Fortune 500 possui 30 servidores MCP aprovados, 5000 desenvolvedores, requisitos de conformidade e auditoria e uma equipe de segurança que deseja uma política centralizada. Permitir que cada desenvolvedor instale servidores arbitrários em suas IDEs é inviável.

O padrão de gateway:

  1. O gateway roda como um único endpoint HTTP de streaming (Streamable HTTP endpoint) ao qual os desenvolvedores se conectam.
  2. O gateway armazena as credenciais de cada servidor MCP de backend.
  3. Cada solicitação do desenvolvedor é autenticada e delimitada por escopo por meio do próprio OAuth do gateway.
  4. O gateway roteia a chamada para o servidor de backend, aplicando políticas.
  5. Todas as chamadas são registradas para auditoria.

Cloudflare MCP Portals, Kong AI Gateway, IBM ContextForge, MintMCP, TrueFoundry, Envoy AI Gateway — todos lançaram gateways ou recursos de gateway em 2025-2026.

Enquanto isso, o Registro Oficial de MCP foi lançado como o upstream canônico: servidores com curadoria, verificação de namespace e nomes no formato de DNS reverso dos quais o gateway pode extrair recursos. Os metarregistros (Glama, MCPMarket, MCP.so, Smithery, LobeHub) agregam servidores de múltiplas fontes.

O Conceito

Cinco responsabilidades do gateway

  1. Auth. OAuth 2.1 para identificar o desenvolvedor; mapeia para as funções do usuário.
  2. RBAC. Política por usuário: quais servidores, quais ferramentas, quais escopos.
  3. Audit. Cada chamada é registrada com quem, o quê, quando e o resultado.
  4. Rate limit. Limites por usuário / por ferramenta / por servidor para evitar abusos.
  5. Policy. Rejeitar descrições envenenadas, impor a Regra de Dois (Rule of Two), redigir informações pessoalmente identificáveis (PII).

Gateway como um único endpoint

Para os desenvolvedores, o gateway parece um único servidor MCP. Internamente, ele roteia para N backends. Os IDs de sessão (Fase 13 · 09) são reescritos no limite da fronteira.

Armazenamento seguro de credenciais (Credential vaulting)

Os desenvolvedores nunca veem os tokens de backend. O gateway os armazena (ou atua como proxy para um provedor de identidade que o faz). Um desenvolvedor com notes:read no gateway pode acessar transitivamente o servidor MCP de notas com as próprias credenciais de backend do gateway — mas apenas sob uma política que vincule esse acesso transitivo.

Fixação de hashes de ferramentas no gateway (Tool-hash pinning)

O gateway mantém um manifesto de descrições de ferramentas aprovadas (hashes SHA256). No momento da descoberta, ele busca o tools/list de cada backend, compara os hashes com o manifesto e remove qualquer ferramenta cuja descrição tenha sido alterada. Esta é a defesa contra puxadas de tapete (rug-pull defense) da Fase 13 · 15 aplicada centralmente.

Política como código (Policy-as-code)

Gateways avançados expressam políticas em OPA/Rego, Kyverno ou Styra. Regras como "o usuário alice pode chamar github.open_pr apenas em repositórios da org acme" são codificadas declarativamente. Gateways simples usam Python programado manualmente. Ambos os formatos são válidos.

Roteamento ciente de sessão (Session-aware routing)

Quando a sessão de um usuário inclui uma mistura de servidores, o gateway realiza a multiplexação: a sessão MCP única do desenvolvedor mantém N sessões de backend, uma por servidor. As notificações de qualquer backend são roteadas através do gateway para a sessão do desenvolvedor.

Mesclagem de namespaces (Namespace merging)

Os gateways mesclam os namespaces de ferramentas de todos os backends, normalmente com prefixos em caso de colisão. Exemplo: github.open_pr, notes.search. Isso torna o roteamento inequívoco.

Registros

  • Official MCP Registry (registry.modelcontextprotocol.io). Lançado sob a governança da Anthropic, GitHub, PulseMCP e Microsoft. Namespace verificado (DNS reverso: io.github.user/server). Pré-filtrado para qualidade básica.
  • Glama. Metarregistro centrado em busca que agrega muitas fontes.
  • MCPMarket. Diretório de orientação comercial com listagens de fornecedores.
  • MCP.so. Diretório da comunidade; envios abertos.
  • Smithery. Fluxo de instalação no estilo de gerenciador de pacotes.
  • LobeHub. Registro integrado à interface do usuário no aplicativo LobeChat.

Os gateways corporativos extraem do Registro Oficial por padrão, permitem adições com curadoria do administrador a partir de metarregistros e rejeitam qualquer item não fixado (unpinned).

Nomenclatura baseada em DNS reverso (Reverse-DNS naming)

O Registro Oficial exige nomes em formato de DNS reverso para servidores públicos: io.github.alice/notes. Os namespaces evitam a ocupação indevida de nomes (squatting) e tornam a delegação de confiança mais clara.

Pesquisa de fornecedores, abril de 2026

Fornecedor Força
Cloudflare MCP Portals Hospedado na borda (edge); integrado com OAuth; plano gratuito
Kong AI Gateway Nativo de K8s; política de granularidade fina; logs para OpenTelemetry
IBM ContextForge IAM corporativo; conformidade; exportação de auditoria
TrueFoundry Orientado a DevOps; métricas em primeiro lugar
MintMCP Orientado a plataformas de desenvolvedores
Envoy AI Gateway Código aberto; filtros personalizáveis

A Fase 17 (infraestrutura de produção) aprofunda-se nas operações de gateway.

Use It

O arquivo code/main.py entrega um gateway mínimo em cerca de 150 linhas: autentica usuários por meio de um token Bearer falso, mantém uma política RBAC por usuário, roteia solicitações para dois servidores MCP de backend, escreve cada chamada em um log de auditoria, impõe um limite de taxa e rejeita qualquer ferramenta de backend cujo hash de descrição não corresponda a um manifesto fixado.

O que observar:

  • O dicionário RBAC chaveado por user_id com as entradas autorizadas de server_tool.
  • AUDIT_LOG é uma lista de eventos do tipo append-only.
  • O limite de taxa usa um token bucket por usuário.
  • O manifesto de itens fixados é um dicionário no formato server::tool -> hash.

Ship It

Esta lição produz outputs/skill-gateway-bootstrap.md. Com base em um plano de MCP corporativo (usuários, backends, conformidade), a skill gera uma especificação de configuração de gateway.

Exercícios

  1. Execute code/main.py. Faça uma chamada como um usuário autorizado; depois como um usuário não autorizado; por fim, uma rajada que exceda o limite de taxa. Verifique os três fluxos.

  2. Adicione uma política que oculte informações pessoalmente identificáveis (PII) dos resultados antes de retorná-los ao cliente. Use uma verificação simples com regex para strings no formato de CPF/SSN; observe as lacunas (e-mails, números de telefone).

  3. Estenda o log de auditoria para emitir spans GenAI do OpenTelemetry. A Fase 13 · 20 aborda os atributos exatos.

  4. Desenhe uma política RBAC para uma equipe de 50 desenvolvedores com cinco backends (notes, github, postgres, jira, slack). Quem recebe acesso apenas de leitura em cada um? Quem recebe acesso de escrita?

  5. Leia o artigo de MCP corporativo da Cloudflare de ponta a ponta. Identifique um recurso que a Cloudflare oferece e que este gateway stdlib não possui.

Termos-Chave

Termo O que as pessoas dizem O que realmente significa
Gateway "MCP proxy" Servidor centralizador entre clientes e backends
Credential vaulting "Os tokens de backend permanecem no lado do servidor" Os desenvolvedores nunca veem os tokens de upstream
Session-aware routing "Sessão multi-backend" O gateway multiplexa N sessões de backend por sessão de desenvolvedor
Tool-hash pinning "Manifesto aprovado" SHA256 de cada descrição de ferramenta aprovada; bloqueia puxadas de tapete de forma centralizada
RBAC "Política por usuário" Controle de acesso baseado em funções para ferramentas e servidores
Policy-as-code "Regras declarativas" Políticas de OPA/Rego, Kyverno ou Styra impostas no gateway
Audit log "Quem, o quê, quando" Log de eventos do tipo append-only para conformidade
Rate limit "Token bucket por usuário" Limites por minuto para evitar abusos
Official MCP Registry "Upstream canônico" registry.modelcontextprotocol.io, com verificação de namespace
Reverse-DNS naming "Namespace do registro" Convenção io.github.user/server

Leituras Adicionais

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).