Você conectou seu agente a uma dúzia de ferramentas MCP e deixou ele resolver seu backlog de segunda-feira. Slack, GitHub, uma API de pagamento — o zoológico domesticado completo. A vida parece automatizada. Aí o agente faz retry numa chamada de pagamento que falhou, e seu cliente leva uma cobrança duplicada.

Nada no MCP avisou o agente que aquele endpoint não era seguro pra retry. Sem label, sem flag. Só uma função crua e um modelo fazendo o que modelos fazem — sendo "prestativo".

E aqui está o ponto. A spec do MCP adicionou exatamente os campos de segurança que você precisaria. Quatro annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Quatro booleanos que poderiam prevenir o cenário da cobrança dupla inteiramente. O time do MCP publicou eles em 16 de março de 2026. E a spec chamou cada um deles de "Hint".

Não é um contrato. Não é uma restrição. Um hint. Tipo um bilhetinho colado numa arma carregada: "talvez não aponte isso pras pessoas."

Seis semanas depois, a indústria deu seu veredito. A Microsoft lançou o Agent Governance Toolkit em 2 de abril — políticas baseadas em YAML, construídas do zero, zero referências às annotations do MCP. A Anthropic lançou políticas de permissão de Managed Agents em 21 de abril — allowlists customizadas e scoping, ignorando completamente os campos de annotation. O Google seguiu um dia depois com o Agent Gateway em 22 de abril — mesmo padrão, mesmo motor de políticas feito do zero. Três plataformas grandes em vinte dias. Nenhuma usou os metadados de segurança que já existem no protocolo do qual todas dependem.

Isso não é o mesmo problema dos diálogos de permissão em nível de plataforma serem teatrais — já cobrimos isso. E não é sobre output de ferramenta não validado — esse é outro buraco. Isso é sobre a camada de protocolo — o único lugar onde metadados de segurança deveriam ser canônicos — ativamente minando sua própria credibilidade com uma escolha de vocabulário.

Justin Spahr-Summers, co-criador do MCP, disse a parte silenciosa em voz alta durante a revisão da spec em março de 2026 no GitHub: "A informação em si, se pudesse ser confiável, seria muito útil, mas eu me pergunto como um client faz uso dessa flag sabendo que ela não é confiável." O designer dos metadados de segurança questionou publicamente se alguém poderia confiar neles. Isso não é uma bandeira vermelha. Isso é a fábrica de bandeiras vermelhas.

Metadados de segurança auto-declarados sem verificação não são um recurso de segurança. São uma caixa de sugestões. destructiveHint: false vindo de um servidor MCP não confiável é exatamente tão confiável quanto perguntar pra ferramenta "ei, você é perigosa?" e acreditar na resposta. Mais de 17.000 servidores MCP agora existem em registros públicos. O número que tem alguma verificação independente das annotations declaradas: zero.

Todo sistema sério já resolveu isso décadas atrás. Unix não sugere permissões de arquivo — o kernel impõe. OAuth não sugere escopos — o authorization server valida. Docker não sugere privilégios de container — o runtime aplica. Em todo modelo de segurança funcional, a entidade que faz a declaração de segurança não é a mesma entidade sendo restringida. Isso não é paranoia. É a primeira coisa que você aprende antes de te deixarem chegar perto de produção.

As annotations do MCP violam esse princípio por design. O servidor da ferramenta declara suas próprias propriedades de segurança, o client lê, e nada entre os dois verifica a declaração. O Blog do MCP reconheceu isso diretamente: "Um servidor pode declarar readOnlyHint: true e deletar arquivos mesmo assim." A documentação da própria spec admite que os labels de segurança podem mentir e não existe mecanismo pra pegar a mentira.

A palavra "hint" fez o resto do estrago. Quando você rotula metadados de segurança como hint, você diz pra todo integrador: isso é opcional, não confiável, e não é problema seu. Eles ouviram. Três plataformas, três sistemas de governança feitos do zero, zero adoção de annotations existentes no protocolo — tudo dentro de abril de 2026. Não porque os metadados são inúteis, mas porque a spec pré-rotulou eles como decoração.

E aqui está a parte que é pior do que não ter nada. Sem annotations, você sabe que está voando às cegas. Annotations de "hint" significam que você talvez tenha dados de segurança — talvez precisos, talvez uma fabricação — e você precisa decidir se confia neles com zero ferramentas de verificação. Falsa confiança é mais perigosa que ignorância honesta. Pelo menos a ignorância te faz ter cuidado.

Então você está escrevendo políticas YAML na mão. Configurando allowlists de ferramentas manualmente. Construindo as mesmas proteções que as annotations deveriam fornecer, só que do zero, porque a própria camada de segurança do protocolo preventivamente te disse pra não depender dela. O modelo de segurança mais trabalhoso possível — não porque metadados melhores não existem, mas porque alguém decidiu chamar de "hint".

A correção nem é técnica. Os quatro campos são bem projetados. O modelo de dados funciona. O que está quebrado é uma palavra e a filosofia por trás dela. Mude "hint" pra "declaration". Adicione um endpoint de verificação — deixe os clients testarem propriedades declaradas contra comportamento observado. Torne a mentira detectável. O upgrade de segurança mais barato de todo o stack de agentes está na spec, corretamente estruturado, e completamente castrado por uma decisão de nomenclatura que disse a 17.000 servidores e três plataformas de governança pra não levarem a sério.

Alguém construiu um extintor de incêndio, colou uma etiqueta dizendo "pode ou não conter água", e agora fica se perguntando por que o prédio está pegando fogo.