Nos últimos meses, adicionamos servidores MCP em uma velocidade difícil de justificar.
GitHub.
Slack.
Jira.
Postgres.
AWS.
Documentação interna.
Ferramentas próprias.
E na maioria dos casos, a arquitetura se parece bastante com isso:
Claude Code
├── GitHub MCP
├── Slack MCP
├── Jira MCP
├── Postgres MCP
└── AWS MCP
Funciona.
Também é um pouco assustador.
Porque conforme os agentes começam a interagir com sistemas reais, surge uma pergunta inevitável:
Quem decide quais ferramentas o agente pode usar?
A resposta tradicional foi:
“O prompt.”
Mas o ecossistema está começando a convergir para outra ideia:
Prompting não é segurança. Arquitetura é segurança.
E isso está originando uma categoria completamente nova: os MCP Gateways.
O que é um MCP Gateway?
Um MCP Gateway se posiciona entre o agente e os servidores MCP.
Em vez de Claude Code, Cursor ou Copilot falarem diretamente com cada ferramenta, todas as chamadas passam primeiro pelo gateway.
A arquitetura passa a se parecer assim:
Claude Code
│
▼
MCP Gateway
│
┌────┼─────┐
▼ ▼ ▼
GitHub Slack Postgres
O gateway se torna um control plane para todas as ferramentas disponíveis para os agentes.
Cada chamada.
Cada permissão.
Cada credencial.
Cada política.
Tudo passa por ele.
Por que precisamos disso?
Porque um laptop pessoal e uma organização não têm as mesmas necessidades.
Em um projeto individual, provavelmente não importa muito se Claude tem acesso completo ao GitHub.
Em uma empresa é outra história.
Imagine:
- dezenas de desenvolvedores,
- centenas de repositórios,
- múltiplos agentes,
- infraestrutura produtiva,
- dados sensíveis,
- requisitos de conformidade.
Dar acesso direto a tudo deixa de ser razoável muito rapidamente.
1. Controle de Acesso por Ferramenta
O caso mais simples.
Suponha que você queira permitir:
github.list_issues
github.create_pr
Mas queira bloquear:
github.delete_repository
github.change_admin_settings
Com um gateway, você pode definir exatamente quais ferramentas expor.
Por exemplo:
allow:
- github.list_issues
- github.create_pr
deny:
- github.delete_repository
- github.change_admin_settings
A parte importante:
o modelo nunca vê as ferramentas proibidas.
Não pode invocá-las acidentalmente.
Não pode aluciná-las.
Simlesmente não existem.
2. Permissões Baseadas no Usuário
Nem todos os usuários precisam das mesmas capacidades.
Por exemplo:
Time de Engenharia
GitHub
Jira
Documentation
Plataforma
AWS
Kubernetes
GitHub
Terraform
Finanças
Slack
Salesforce
Analytics
O mesmo agente pode expor ferramentas completamente diferentes dependendo de quem o está usando.
Isso começa a parecer muito com um IAM tradicional.
Só que aplicado a agentes.
3. Auditoria Completa
Uma das funcionalidades mais atrativas para ambientes enterprise.
Cada invocação é registrada.
Por exemplo:
09:12
Usuário: greg
Agente: Claude Code
Ferramenta: github.create_pr
09:15
Usuário: greg
Agente: Claude Code
Ferramenta: jira.create_ticket
09:17
BLOQUEADO
Ferramenta: aws.delete_cluster
Motivo: política de segurança
Isso responde perguntas fundamentais:
- Quem executou esta ação?
- Qual agente a realizou?
- Quais ferramentas foram usadas?
- O que foi bloqueado?
- Quando ocorreu?
Para times de segurança e conformidade, isso é enorme.
4. Gestão Centralizada de Credenciais
Hoje muitos desenvolvedores fazem algo parecido com isto:
15 servidores MCP
×
20 desenvolvedores
=
300 credenciais
Não escala.
Um gateway permite centralizar credenciais.
O fluxo passa a ser:
Agente
↓
Gateway
↓
Backend
O agente nunca precisa acessar diretamente segredos sensíveis.
O gateway cuida da autenticação e as credenciais ficam centralizadas.
5. Políticas de Execução
Nem todas as operações têm o mesmo nível de risco.
Por exemplo:
Permitido automaticamente
Ler documentação
Consultar issues
Buscar logs
Requer aprovação humana
Modificar produção
Escrever na base de dados
Executar migrações
Sempre bloqueado
DROP TABLE
terraform destroy
aws delete-cluster
Isso permite introduzir níveis progressivos de autonomia.
Os agentes podem trabalhar rápido onde o risco é baixo e solicitar aprovação quando o impacto potencial aumenta.
Alguns projetos interessantes
O ecossistema ainda é muito jovem, mas já começam a aparecer implementações interessantes:
Microsoft MCP Gateway
Orientado a ambientes Kubernetes e despliegues enterprise.
Permit MCP Gateway
Focado em autenticação, autorização e auditoria.
Lasso MCP Gateway
Gateway open source com forte foco em segurança.
Pomerium MCP Gateway
Acesso baseado em identidade e políticas centralizadas.
Todos apontam para o mesmo problema:
como governar um ecossistema crescente de agentes e ferramentas.
A verdadeira história
A maioria das discussões sobre agentes ainda está centrada nos modelos.
GPT.
Claude.
Gemini.
Mas as grandes organizações já estão começando a se preocupar com outra coisa:
Como controlamos centenas de agentes acessando centenas de sistemas?
Porque o problema deixa de ser inteligência.
Passa a ser governança.
E é aí que surgem categorias completamente novas:
- Agent IAM
- MCP Gateways
- Policy Engines
- Agent Observability
- Agent Security
A intuição é bastante simples.
Se os humanos precisam de:
- autenticação,
- autorização,
- auditoria,
- políticas,
os agentes provavelmente também.
E é bem possível que em alguns anos consideremos normal ter um IAM para agentes do mesmo modo que hoje consideramos normal ter um para pessoas.
A próxima grande plataforma de infraestrutura pode não ser para humanos.
Pode ser para agentes.