Capítulo 12 — Endurecimento do Protocolo e Defesas
Décima segunda postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Em que toda ameaça do capítulo anterior ganha uma defesa, nenhuma das defesas é bala de prata, e sua composição é a única coisa que produz uma postura que você consegue de fato implantar.
Por que este capítulo existe
O protocolo não vira seguro ao ser implantado. Vira seguro ao ser implantado dentro de uma pilha que compensa as suposições que o protocolo nu faz. O Capítulo 11 catalogou as ameaças; este capítulo percorre as defesas em profundidade de engenharia. Atestação criptográfica de capacidade fecha as classes de descoberta e escalada de capacidade. Disciplina de escopo OAuth 2.1 com tokens delegados pelo usuário fecha as classes de deputy e passthrough. Vidas de sessão limitadas fecham a classe de hijack. Sandbox contém os comprometimentos que prevenção falha em pegar. Aprovação humano-no-loop pega as operações destrutivas que o resto da pilha teria que automatizar para ser útil. Cada defesa deixa risco residual; a composição é o que torna os residuais pequenos o suficiente para defender na prática.
12.1 AttestMCP: atestação criptográfica de capacidade
A primeira defesa endereça um problema que perpassa quase toda ameaça: o host não tem jeito de verificar que o servidor com quem está falando é o que ele alega ser. AttestMCP — também chamado MCPSec ou manifestos de capacidade assinados — adiciona uma camada de atestação criptográfica sobre a estrutura de mensagem do protocolo. Um publisher mantém uma chave de assinatura de vida longa registrada num diretório ou log de transparência. O manifesto completo de capacidade é hasheado e assinado em tempo de release. O host verifica a assinatura no initialize contra a chave do publisher em arquivo, e admite o servidor, o quarentena, ou recusa a conexão.
Os benefícios são reais. Typosquats não conseguem produzir uma assinatura válida do publisher legítimo. Escalada de capacidade via notificações list_changed vira detectável porque um novo manifesto exige uma nova assinatura. Política de granularidade fina — "confie em servidores publicados pelo GitHub para repositórios mas não para email" — vira aplicável porque a identidade do publisher é agora verificável em vez de afirmada. Os custos também são reais: publishers precisam rodar infraestrutura de assinatura, logs de transparência precisam de operador confiável, e a camada de política do host precisa entender revogação. O enquadramento honesto é que o AttestMCP é engenharia substancial, não um checkbox. E tem uma lacuna que vale nomear: o manifesto assina o que o servidor diz sobre si mesmo, não o que ele faz em runtime. Uma declaração assinada de uma tool benigna ainda pode embarcar uma implementação que exfiltra. Atestação é necessária mas insuficiente, razão pela qual o resto do capítulo existe.
12.2 Escopos OAuth 2.1 e vidas de sessão limitadas
O segundo cluster aperta o modelo de credencial e sessão. Os fluxos do OAuth 2.1 são maduros; a engenharia está em usá-los corretamente. A primeira disciplina é escopos estreitos — requisite só o que a superfície de tool declarada precisa. Quanto mais apertado o escopo, menor o raio de explosão. A disciplina é mais difícil do que parece porque serviços a montante frequentemente definem escopos grosseiramente e o caminho estreito é tedioso; escopos amplos funcionam de primeira e parecem progresso. O custo de escopos estreitos é pago pelo engenheiro; o custo de escopos amplos é pago pelo usuário quando algo dá errado.
A defesa contra Confused Deputy que disciplina de escopo sozinha não fornece é tokens delegados pelo usuário. Onde o upstream suporta, cada usuário completa seu próprio fluxo OAuth, e o servidor age sobre o token do usuário em vez da sua identidade de serviço. O deputy desaparece porque o servidor não está mais agindo por autoridade própria. Token passthrough tem conserto diferente: não passe tokens. O servidor mantém suas próprias credenciais, estabelecidas em tempo de registro, e a fronteira entre host e servidor nunca carrega token. Vidas de sessão limitadas endereçam hijack: minutos para operações de alto risco, horas para rotineiras, com identidade de workflow durável em cima para que uma tarefa de várias horas possa renovar sessões de transporte sem perguntar de novo ao usuário a cada quinze minutos. Vinculação de capacidade por sessão e reconfirmação de capacidade na renovação de sessão completam a disciplina — ambas são trabalho de gestão de estado que o host precisa fazer explicitamente, e muitas implementações não fizeram.
12.3 Sandbox e isolamento em runtime
O terceiro cluster reconhece que nem toda ameaça pode ser prevenida e que uma postura defensável precisa conter dano quando prevenção falha. Sandbox de processo para servidores locais — seccomp no Linux, App Sandbox no macOS, AppContainer no Windows, gVisor para isolamento mais forte — nega acesso a filesystem, rede e processo por padrão e concede apenas os acessos específicos que o servidor precisa. Um servidor comprometido tentando ler um arquivo de senhas ou exfiltrar para um endpoint atacante encontra a operação recusada na camada do SO, não porque o código do servidor se conteve mas porque o sandbox se conteve. Política de rede para servidores remotos — TLS mútuo, endpoints em allowlist, filtragem de egresso — estreita a superfície que um servidor remoto comprometido pode alcançar. Isolamento de conteúdo dentro do host trata conteúdo retornado com suspeita apropriada antes que aterrisse no contexto do modelo: marcadores de não-confiança, sanitização de HTML, recusa a seguir URLs embutidas. Sandbox de chamada de tool via políticas conscientes de capacidade permite que o host examine argumentos de chamada e decida se permite, nega ou escala para aprovação do usuário. Um risco específico que vale nomear é exfiltração por canal lateral por tools legítimas — um modelo malicioso codificando credenciais numa query de busca — que a camada de política pega inspecionando argumentos em vez de endpoints. Isolamento de cadeia de suprimentos fecha o loop: o hash do binário é verificado em instalação e atualização contra um valor assinado no log de transparência, então um binário adulterado não consegue rodar mesmo que o manifesto passe.
12.4 Portões de aprovação humano-no-loop
O quarto cluster reconhece que algumas operações nunca deveriam ser automatizadas. Chamadas destrutivas, irreversíveis ou de alto impacto — mandar dinheiro, apagar arquivos, modificar produção — merecem uma decisão humana explícita no momento em que acontecem. O mecanismo é o portão HITL, e a engenharia está em torná-lo eficaz sem tornar o sistema inutilizável. Categorize por reversibilidade: operações somente-leitura procedem automaticamente; operações que mudam estado passam pelo portão. Apresente de modo significativo: um modal dizendo "Permitir execução de tool?" é carimbo de borracha; um portão útil mostra a tool, os argumentos completos, a consequência em linguagem clara, e a proveniência. Evite fadiga de aprovação com aprovação contextual em lote, em que um usuário que inicia "mande faturas para clientes do último trimestre" aprova o lote uma vez em vez de cada email vinte vezes. Roteie operações de alta aposta para fora-de-banda — token de hardware, segundo dispositivo, autenticação step-up tomada emprestada da indústria financeira. Mantenha operações visíveis, auditáveis e desfazíveis. Chamadas dirigidas por sampling passam pelos mesmos portões que chamadas iniciadas pelo agente; o canal lateral de inferência iniciada pelo servidor não pode terminar em efeito colateral sem o usuário notar.
O que o Capítulo 12 prepara
A metade de segurança da fotografia de engenharia está completa. A outra metade — frameworks, padrões de deployment, características de desempenho, e os testes que confirmam que o sistema funciona em produção — é o que os capítulos restantes tomam. O Capítulo 13 abre esse arco percorrendo os frameworks e integrações de nuvem que aterrissaram durante 2025 e 2026: Strands com Amazon Bedrock, os padrões de camada de estado AWS, o Microsoft Agent Framework, LangChain e Semantic Kernel. Os frameworks importam porque ninguém constrói MCP de produção a partir de protocolo cru, e as escolhas entre eles moldam a postura de engenharia e segurança de modos que a camada de protocolo sozinha não determina.
Próximo — Capítulo 13: Frameworks e Integração com Nuvem. Strands com Bedrock, a camada de estado AWS, o Agent Framework da Microsoft, LangChain, Semantic Kernel, e os três padrões de integração em produção em que times insistem em chegar independentemente.
