Radar Tech: o agente seguiu uma instrução que ninguém aprovou — o contrato da ferramenta mudou embaixo dos panos

O que apareceu nas últimas 24 horas

Um levantamento técnico que circulou hoje fixou, com hash, o contrato de cada ferramenta exposta por 24 servidores MCP — os mais instalados do npm mais alguns fornecedores corporativos — e comparou esse contrato a cada nova versão, durante dois meses. O resultado: 336 mudanças de contrato, distribuídas em janelas de algumas semanas a seis meses.

O conceito que quase ninguém tinha nomeado até aqui é simples. Um servidor MCP (Model Context Protocol) entrega ferramentas ao agente de IA. Cada ferramenta tem três peças: o nome, a descrição — que é literalmente a instrução que o modelo lê para decidir se e como chamar a ferramenta — e o input schema, o contrato de quais argumentos são válidos. Quando você instala o servidor, aprova um conjunto específico dessas três peças. Depois o servidor publica uma versão nova. Os nomes continuam iguais, então nada "quebra". Mas a descrição pode agora dizer outra coisa, o schema pode exigir um parâmetro novo, ou soltar uma restrição e aceitar mais do que antes.

A partir daí, o agente está seguindo instruções que você nunca viu e nunca aprovou — e ninguém avisa.

Os números que importam

Alguns exemplos do levantamento dão o tom:

• Um banco de dados como serviço regenerou os schemas das 20 ferramentas de uma vez numa versão 3.0: mudança de dialeto de JSON Schema, reescrita de descrições e 5 restrições realmente apertadas escondidas entre 15 mudanças puramente de notação. As notas de release estavam vazias.
• Uma plataforma de conteúdo alterou 45 input schemas entre duas versões; 32 eram apertos de restrição — novos limites, tipos mais estreitos. O mantenedor explicou que a validação passou a existir também no schema, e que o backend já a aplicava. Justo — e exatamente o ponto: chamadas que antes passavam agora são rejeitadas no nível do schema, e nenhuma nota de versão menciona isso.
• Um fornecedor de e-commerce removeu dois validadores específicos e os substituiu por um genérico. Um agente que chama o nome antigo recebe erro de protocolo. Outro fornecedor de CRM removeu create-association e criou uma versão em lote — o pacote npm publica releases, mas o repositório no GitHub está morto: não há canal onde isso seja anunciado.
• Um serviço de banco gerenciado mudou o entrypoint do stdio de dist/transports/stdio.js para dist/cli.js. O contrato das ferramentas ficou intacto, mas toda configuração de lançamento fixada quebra.
• Um gateway de um servidor oficial muito usado alterou 124 de 131 definições de ferramenta numa única versão maior. O mantenedor descreveu como "praticamente um no-op além dos output schemas" — o que é verdade do ponto de vista dele, e ainda assim são 124 contratos diferentes do ponto de vista de quem consome.

Três padrões se repetem: a onda de notação (o fornecedor troca de SDK e todos os bytes mudam de uma vez — sem canonicalização, parece que tudo quebrou); a quebra por consolidação (ferramentas específicas viram uma genérica); e, a mais perigosa, o afrouxamento silencioso (uma restrição cai, um tipo alarga, nada quebra — e a superfície do seu agente ficou maior do que a que você aprovou).

Por que isso é uma história de arquitetura, não de segurança de fornecedor

A reação fácil é "fornecedor deveria anunciar". Mas o problema não se resolve pedindo boas maneiras: metade dos casos acontece em pacotes cujo repositório está morto ou cujas notas de release são vazias. A parte que está sob o seu controle é a outra metade da frase: fixar o que você aprovou, comparar o que chega, classificar o que mudou.

Isso é o mesmo raciocínio que já aceitamos para dependências — lockfile, SBOM, pin de imagem por digest — e que ainda tratamos como exceção quando o artefato é texto em linguagem natural que vai parar dentro do prompt do modelo. A descrição de uma ferramenta não é documentação: é código que roda no contexto. Mudá-la sem aprovação é mudar o comportamento do agente.

E há uma assimetria que explica por que o problema é chato: uma mudança de schema aparece como erro no primeiro teste; uma mudança de descrição não aparece em teste nenhum. O agente continua funcionando — só passa a escolher a ferramenta errada, a preencher um campo que ninguém pediu, ou a preferir o caminho que a nova frase sugeriu.

O que fazer na semana seguinte

• Trate o contrato como artefato versionado. Nome, descrição e schema, canonicalizados, com hash e data de aprovação, dentro do repositório. É o seu lockfile de ferramentas.
• Classifique a mudança por direção, não por tamanho de diff. Aperto de restrição, afrouxamento, expansão de parâmetro opcional, notação e cosmético são categorias com consequências diferentes — o mesmo diff que gera 20 alertas inúteis pode esconder um afrouxamento real.
• Faça disso um portão de CI, não um relatório mensal. Se o upgrade muda o contrato, ele não entra sem revisão — ou entra num ambiente onde o pior caso é um erro, não uma ação.
• Escreva a regra de resposta antes do incidente. Quem aprova um afrouxamento? Quem é o dono do servidor interno? O que acontece se o gate de manifesto do fornecedor ficar indisponível? (Um dos casos do levantamento é instrutivo: o servidor se recusa a subir se a versão não bater com o manifesto remoto — e pula a verificação inteira se o serviço estiver fora do ar. Fail-open disfarçado de fail-closed.)

A leitura do dia

MCP resolveu o problema de como conectar um agente a um sistema. Não resolveu — e não vai resolver sozinho — o problema de o que esse agente foi autorizado a ler e a executar. A pergunta de arquitetura do dia não é "meu servidor MCP está atualizado?", mas: se a descrição de dez ferramentas que meu agente usa mudasse hoje, em quanto tempo eu saberia — e alguém teria aprovado?

Se a resposta for "não sei", o seu agente está montado sobre uma suposição auditada por ninguém. E toda suposição desse tipo é, um dia, o incidente que ninguém previu.

Nota: toda decisão de fixação de contrato, aprovação de versão e resposta a incidente deve ser revisada por quem responde pelo sistema. Uma saída de IA organiza a decisão e aponta as lacunas — não substitui o julgamento de quem assume o risco.