A nova especificação MCP transfere responsabilidades de segurança para desenvolvedores. Descubra os riscos e como atenuá-los em produção.
A nova especificação do Model Context Protocol (MCP) da Anthropic, lançada em junho de 2026, transfere as responsabilidades de segurança diretamente para os desenvolvedores. Antes, o protocolo se encarregava. Agora, é você.
Essa mudança não é recente. As equipes que implantam Claude com MCP em produção, como Simple Booking no setor hoteleiro, X com seus MCP servers para agentes IA, já se fazem a pergunta: onde exatamente estão as falhas?
O shift de responsabilidade: de onde vem o problema
A nova especificação MCP é enterprise-ready, é verdade. Mas essa palavra esconde uma realidade: a Anthropic voluntariamente transferiu parte dos controles de segurança para a camada do desenvolvedor para ganhar flexibilidade.
Concretamente, isso significa três coisas:
1. Sem autenticação implícita
Antes, MCP incluía mecanismos de segurança por padrão. Agora, você é que deve construir a cadeia de autenticação. Uma agência e-commerce Shopify conectando Claude a uma base de clientes precisa gerenciar como um agente Claude acessa dados sensíveis, nomes, emails, números de telefone. Sem mágica aqui.
2. As permissões granulares se tornam seu problema
MCP não diz mais "essa ferramenta pode ler mas não escrever". Você é que diz. Um agente pode potencialmente executar a ação para a qual não tem autorização se você não tiver colocado as barreiras. Simple Booking enfrenta esse dilema: seus conectores MCP integram um CRS (Central Reservation System), que afeta diretamente as reservas de clientes. Uma permissão mal configurada = uma reserva modificada por engano.
3. As injeções de prompt se tornam mais críticas
Claude é inteligente, mas se um agente MCP aceita uma instrução do exterior sem validação, "chame a ferramenta X com o parâmetro Y", você acaba de criar uma via de entrada para um atacante. Os adversários não procuram hackear o protocolo. Eles procuram manipular seu agente.
Os quatro obstáculos concretos que você enfrenta
Obstáculo 1: credenciais expostas em variáveis de ambiente
O clássico. Seu servidor MCP precisa de uma chave API para se comunicar com um banco de dados. Você a coloca em .env. Tudo bem até aqui. Exceto que seu container Docker ou sua função AWS Lambda expõe essas variáveis em logs se algo der errado.
Com MCP, cada erro de conexão com o servidor remonta a Claude. Claude registra isso. E se Claude está em modo debug ou se os logs não são criptografados, tchau sua chave.
Mitigação: use um gerenciador de segredos (Vault, AWS Secrets Manager). Injete as credenciais em tempo de execução, nunca em hardcoded.
Obstáculo 2: confiança cega no servidor MCP
Você implanta um servidor MCP que expõe 15 ferramentas. Claude está conectado. Um dev júnior adiciona uma nova ferramenta que deleta registros de clientes. Sem revisão de acesso, Claude pode chamá-la.
Pior: se esse servidor está em sua rede interna e alguém compromete outra máquina na rede, podem fazer pivot para enviar comandos MCP falsificados.
Mitigação: cada ferramenta MCP deve ter uma lista explícita de quem pode chamá-la. Claude? Sim, mas apenas se atender aos critérios X. Audite as ferramentas regularmente.
Obstáculo 3: timeouts infinitos que travam
Um servidor MCP responde lentamente ou não responde. Claude espera. Enquanto isso, uma requisição do usuário fica pendurada, a sessão permanece aberta, a memória cresce. Não é uma falha de segurança direta, mas cria vetores de DoS.
Pior se for intencional: alguém envia uma requisição que força MCP a fazer uma operação muito longa (um scan de banco de dados gigantesco, um cálculo custoso).
Mitigação: timeout rigoroso em cada chamada MCP. 5s, 10s no máximo. Sem infinito.
Obstáculo 4: sem logging ou logging insuficiente
Se Claude chama uma ferramenta MCP e você não registra a ação, timestamp, parâmetros, resultado, não tem nenhuma rastreabilidade. Uma agência hoteleira que descobre 500 reservas canceladas não terá nenhuma pista para rastrear o que aconteceu.
As defesas que você deve implementar
1. Autenticação forte entre claude e seu servidor MCP
MCP usa JSON-RPC em uma conexão stdio ou HTTP. Se for HTTP, use HTTPS + um token Bearer válido. Melhor ainda: mTLS com certificados cliente.
Teste: seu servidor MCP deve rejeitar toda requisição sem autenticação válida. Sem exceções.
2. Autorização por papel (rbac) ou por atributos (abac)
Defina explicitamente quem pode chamar qual ferramenta.
| Papel do Agente | Ferramentas autorizadas | Parâmetros limitados |
|---|---|---|
| ReadOnlyAnalyst | GetBookings, GetReviews | Nenhum parâmetro sensível |
| ReservationManager | CreateBooking, ModifyBooking | Modificações < 3 dias antes da chegada |
| Admin | Todas | Sem limite |
Implemente isso em seu servidor MCP. Antes de executar uma ferramenta, verifique o papel de Claude (ou mais precisamente, o contexto da sessão que a utiliza).
3. Validação e sanitização rigorosa
Cada parâmetro recebido por MCP deve ser validado:
- Tipo correto (string, número, etc.)
- Comprimento limitado (não 10 MB de texto em um campo)
- Formato validado (uma data é realmente uma data, um email é realmente um email)
- Nenhum caractere escapado que pudesse fazer uma injeção SQL
// Exemplo: endpoint que cria uma reserva
// RUIM
app.post('/MCP/create-booking', (req, res) -> {
const booking = req.body; // Perigo direto
db.insertBooking(booking);
});
// BOM
app.post('/MCP/create-booking', (req, res) -> {
const schema = z.object({
clientId: z.string().uuid(),
checkIn: z.string().date(),
nights: z.number().min(1).max(365),
roomType: z.enum(['single', 'double', 'suite'])
});
const validated = schema.parse(req.body); // Throw se inválido
db.insertBooking(validated);
});
4. Logging exhaustivo com contexto
Cada chamada MCP deve ser registrada com:
- Timestamp exato
- Identidade do agente (ou do contexto que a utiliza)
- Ferramenta chamada + parâmetros completos
- Resultado (sucesso, erro, exceção)
- Duração da execução
- Endereço IP de origem (se relevante)
Armazene esses logs em um sistema imutável (CloudWatch, Splunk, ou um simples arquivo append-only criptografado).
5. Monitoramento e alertas em tempo real
Detecte anomalias:
- Muitas chamadas para uma ferramenta em pouco tempo -> tentativa de DoS
- Uma ferramenta chamada com parâmetros anormais -> ataque de fuzz
- Erros repetidos -> reconhecimento ou scanning de vulnerabilidades
Configure um alerta se Claude chamar "GetUserData" 100 vezes em 30s.
O caso de escola: X e seus MCP servers
X (antigo Twitter) lançou MCP servers para que Claude, Cursor, Grok Build e outras ferramentas de IA possam acessar X diretamente. É a mesma lógica que Simple Booking e as reservas de hotéis.
A diferença: os dados no X são públicos por padrão. Um agente pode recuperar tweets sem danos. Mas se você tivesse um servidor MCP do X que expusesse DMs privados ou analytics internas, o cenário mudaria completamente.
Anthropic e X assumem que os desenvolvedores que integram esses servers saberão colocar barreiras. Spoiler: nem sempre é o caso.
Perguntas frequentes
Devo criptografar a comunicação MCP mesmo em localhost?
Sim, se dados sensíveis trafegarem. Se for apenas cálculo inofensivo (converter Celsius em Fahrenheit), não. Mas assim que há cliente, conta, pagamento: criptografe.
Qual é a diferença entre MCP e uma API REST clássica do ponto de vista de segurança?
Fundamentalmente: nenhuma. MCP é apenas uma convenção JSON-RPC. Os mesmos princípios de segurança se aplicam. A diferença é que muitos devs pensam que porque é "para IA", é menos crítico. Erro.
Como testo a segurança do meu servidor MCP?
Faça fuzzing: envie parâmetros aleatórios, strings gigantes, nulls, caracteres estranhos. Use ferramentas como Burp Suite para interceptar chamadas MCP. Tente injeção SQL em cada parâmetro. Meça timeouts. Procure bypass de papel.
Existe uma certificação ou norma para MCP seguro?
Ainda não. MCP é muito recente. Anthropic publica recomendações mas nada oficial. Em vez disso, aplique os padrões clássicos de segurança de API: OWASP Top 10, funciona.
Como gerencio MCP se o agente claude precisa de direitos de administrador?
Cenário de pesadelo: você deve dar a Claude a capacidade de deletar dados. Opção 1: dê a ela uma ferramenta separada "DeleteWithConfirmation" que solicita aprovação humana (você diz ao sistema "aprove o agente para essa ação"). Opção 2: ferramentas granulares com papéis muito limitados. Opção 3: não faça isso e use um humano para operações destrutivas.
A autenticação entre claude e MCP é suficiente, ou também preciso proteger claude -> anthropic?
Ambas. Você deve confiar no canal entre Claude e seu servidor. Mas também deve confiar na Anthropic para não registrar/expor seus dados. Anthropic tem garantias de confidencialidade para planos Enterprise. Verifique seu contrato.
Conclusão
A nova especificação MCP da Anthropic é mais flexível mas menos segura por padrão. A segurança não está incorporada. Depende de você.
Os três reflexos que você deve ter:
- Autenticação forte entre Claude e MCP, HTTPS + tokens, mTLS se possível.
- Autorização granular, cada ferramenta tem uma lista explícita de quem pode chamá-la e como.
- Observabilidade completa, cada chamada é registrada, auditável, alertável.
Se você implanta MCP em produção sem esses três pilares, está jogando roleta russa. E spoiler: a bala acaba entrando na câmara.
Precisa de ajuda para proteger sua implementação MCP? Vamos conversar sobre sua arquitetura em fstck.co, temos casos reais em hotelaria, e-commerce e fintech.
