Anthropic e outros modelos de linguagem podem chamar ferramentas ocultas sem permissão

Hoje, o principal risco dos LLMs agênticos está menos nos erros ocasionais de parâmetros de função e mais em outro ponto: com uma arquitetura mal desenhada, eles podem chamar uma ferramenta que ninguém formalmente lhes concedeu. Se essa função existir no ambiente, o modelo consegue adivinhar o nome dela, inventar argumentos e produzir um efeito colateral real: ler um segredo, gravar uma mensagem, acessar a API de terceiros. No papel, as permissões parecem restritas; na prática, a fronteira entre o permitido e o proibido se torna probabilística.

Em sistemas nos quais o modelo lida com dados, e-mail, documentos ou integrações corporativas, isso deixa de ser curiosidade e passa a ser risco de segurança. O problema surge na combinação entre o modelo agêntico e o ambiente do cliente, quando a lista de ferramentas permitidas e o namespace real divergem. Na demonstração, o modelo recebeu apenas read_url, mas o ambiente também continha a função read_secret.

Depois de uma dica do tipo from dialoghelper import *, o modelo concluiu que tinha acesso a read_secret e tentou chamar essa ferramenta. Se a biblioteca ou a API verificam só o formato da chamada, sem conferir rigorosamente o nome da função com o schema concedido, a requisição segue adiante. O autor mostrou comportamento semelhante não só na Anthropic, mas também em cenários específicos com Gemini, Grok e wrappers multiprovedor.

Em outras palavras, a vulnerabilidade não nasce em uma marca específica, e sim na junção entre modelo, SDK e camada agêntica. O perigo cresce bastante quando o sistema cai na chamada tríade letal: o modelo tem acesso a ferramentas externas, a conteúdo não confiável e a dados privados. Aí o prompt injection deixa de ser um incômodo e vira canal de vazamento.

Basta que um atacante insira uma instrução em um e-mail, página web ou documento para que o modelo, convicto de que a ferramenta oculta existe, alcance o segredo por conta própria e o envie para fora. O mais preocupante é que a separação arquitetural em que os desenvolvedores confiam pode gerar uma falsa sensação de segurança: a ferramenta sensível aparentemente não está no conjunto, mas fica fisicamente ao lado, no ambiente, e se torna acessível por meio de uma chamada não autorizada. Detectar essa falha é difícil.

Em muitos casos, o modelo se comporta corretamente e recusa a chamada proibida, mas de repente quebra por um detalhe do contexto: a redação da dica, o histórico de mensagens ou até o nome de um módulo. O artigo traz um exemplo revelador, em que a mesma ação ora é bloqueada, ora passa após uma menção inofensiva a dialoghelper. A decodificação estruturada reduz parte do risco, porque obriga o modelo a seguir o schema, mas também tem contrapartidas: aumento de latência, limites rígidos no número de ferramentas strict e queda de desempenho em conjuntos grandes de funções.

Por isso, não dá para depender só do bom comportamento do modelo. A verificação do nome da ferramenta precisa acontecer no lado do provedor e no código do cliente, antes da execução de fato. A conclusão prática é simples: se você constrói um agente sobre MCP, Jupyter, SDKs internos ou qualquer outro ambiente dinâmico, não basta esconder funções extras da descrição e torcer pela disciplina do modelo.

É preciso validar rigorosamente cada tool call, separar operações sensíveis de conteúdo não confiável e manter o espaço de execução mais estreito do que aquilo que o LLM enxerga. Caso contrário, um único read_secret ou add_msg adivinhado transforma uma arquitetura agêntica cuidadosa em um sistema no qual as permissões só existem até a primeira alucinação bem-sucedida. A boa notícia é que a correção não parece complicada: basta descartar qualquer chamada cujo nome não esteja no schema permitido, antes mesmo de repassá-la ao runtime.

Algumas linhas de código defensivo na biblioteca ou no gateway podem eliminar uma classe de problemas que, de outra forma, se disfarça de alucinação rara, mas na prática quebra o modelo de confiança de todo o sistema.