Seu agente tem duas entradas não confiáveis

Um programa tradicional tem uma fronteira de confiança: a entrada que um usuário lhe entrega. Você valida nessa borda e está praticamente pronto. Um agente acrescentou silenciosamente mais duas, e a maior parte das ferramentas construídas em torno de agentes só trata uma delas como real.

A primeira entrada nova é o código que o modelo escreve e que seu processo executa. A segunda é a saída de ferramenta que o modelo lê e sobre a qual ele então age. Ambas atravessam para dentro do seu sistema vindas de algum lugar que você não controla – a distribuição de amostragem de um modelo de linguagem, ou o servidor de um terceiro – e ambas são tratadas como confiáveis no momento em que chegam. A razão pela qual a segurança de agentes parece tão instável agora é que a indústria tem uma resposta crível para a primeira entrada e continua fingindo que a segunda é o mesmo problema. Não é.

Pontos principais

• Agentes têm duas entradas não confiáveis, não uma. Código gerado pelo modelo que seu runtime executa, e saída de ferramenta/servidor que seu modelo ingere e sobre a qual age. Elas falham de jeitos diferentes e precisam de defesas diferentes – confundi-las é o motivo de as pessoas se sentirem em sandbox enquanto continuam exploráveis.¹²
• A execução de código não confiável finalmente tem uma resposta crível de isolamento. O micropython-wasm de Simon Willison roda Python escrito pelo modelo dentro de um sandbox WebAssembly com limites de memória e CPU e acesso controlado a arquivos e rede – as características de que um sandbox de verdade precisa, sobre um substrato “testado em navegadores por quase uma década”.¹
• Envenenamento de ferramentas não é um problema de execução de código, então um sandbox de código não faz nada contra ele. Instruções maliciosas escondidas na descrição de uma ferramenta MCP são “invisíveis para os usuários, mas visíveis para os modelos de IA”, e podem sequestrar um agente mesmo que a ferramenta envenenada nunca seja executada.²³
• O problema mais profundo é uma lacuna de confiança entre o momento da conexão e o tempo de execução. As descrições de ferramentas são revisadas uma vez, na aprovação; as respostas de ferramentas fluem direto para o contexto do modelo sem nenhuma verificação equivalente – e um servidor malicioso pode mudar a descrição depois que você a aprovou.²

Duas entradas, dois modos de falha

Segure as duas entradas lado a lado, porque a assimetria é o ponto inteiro.

Quando um modelo escreve código e você o executa com exec(), o modo de falha é o código faz algo com a sua máquina – lê um arquivo que não deveria, abre um socket, deixa a CPU girando para sempre, corrompe o estado. O raio da explosão é o seu processo e tudo o que ele consegue alcançar. A defesa é antiga e bem compreendida: isolamento. Rode o código em algum lugar em que ele não possa tocar no que importa.

Quando um modelo lê a saída de uma ferramenta e age sobre ela, o modo de falha é as palavras mudam o que o modelo decide fazer. Nada executa no seu host no sentido clássico; em vez disso, um texto que chegou como “dado” é interpretado como “instrução”, e o agente – segurando suas credenciais – a cumpre. O raio da explosão é tudo o que seu agente está autorizado a fazer. Nenhuma quantidade de isolamento de processo ajuda, porque o agente deveria mesmo poder ler aquela ferramenta e agir sobre ela. O exploit pega carona no caminho legítimo.

Um sandbox de código é um muro em volta da primeira entrada. Ele é necessário, e finalmente está ficando bom. Ele também é completamente silencioso sobre a segunda.

A entrada que finalmente tem um sandbox

Em 6 de junho de 2026, Simon Willison lançou o micropython-wasm, um pacote alfa para rodar Python em um sandbox WebAssembly, depois de anos tentando abordagens que nunca encaixavam bem.¹ A motivação é exatamente a primeira entrada não confiável: ele quer rodar código gerado por LLM dentro do seu Datasette Agent sem arriscar o host, e, como ele mesmo diz, “um plugin com bug ou malicioso poderia quebrar tudo ou vazar dados privados”.¹

O que o torna digno de atenção é a lista de verificação que ele de fato satisfaz, porque essa lista é a definição de um sandbox utilizável:

• Limites de memória e CPU, para que um while True: s += "x" escrito pelo modelo não possa exaurir o host. A CPU é limitada com o mecanismo de “fuel” do wasmtime – sobre o qual Willison é honesto, observando que as unidades são “difíceis de raciocinar”.¹
• Acesso controlado a arquivos e rede, negado por padrão em vez de aberto por padrão.
• Um modelo de isolamento limpo: o código roda em uma thread separada atrás de uma fila de requisição/resposta, com o interpretador WASM bloqueando em uma função do host até receber trabalho – de modo que o código não confiável nunca compartilha o espaço de endereçamento do host.¹
• Um substrato com histórico. Ele escolheu WebAssembly porque foi “projetado desde o início para suportar todas as características com que me importo e foi testado em navegadores por quase uma década”, e MicroPython porque o Pyodide, voltado ao navegador, não tem suporte no lado do servidor.¹

A honestidade é a marca do bom trabalho de segurança. Willison lança isso como alfa e escreve que “não está pronto para recomendá-lo a ninguém que não esteja disposto a assumir um risco significativo”.¹ Essa é a postura do portão da evidência – afirmar exatamente o que você verificou e nada mais. O ponto não é que esse pacote em particular seja a resposta; é que a forma da resposta para código não confiável agora é clara e reproduzível: uma fronteira de isolamento real com limites de recursos e E/S negada por padrão. A primeira entrada está se tornando um problema de engenharia resolvido.

A armadilha é acreditar que resolvê-la deixa você seguro.

A entrada que não tem

A segunda entrada não roda código, então o muro não faz nada. Em 1º de abril de 2025, a Invariant Labs divulgou o ataque de envenenamento de ferramentas: “instruções maliciosas são embutidas em descrições de ferramentas MCP que são invisíveis para os usuários, mas visíveis para os modelos de IA”.² A assimetria é o exploit – “os modelos de IA veem as descrições completas das ferramentas, incluindo as instruções ocultas, enquanto os usuários normalmente veem apenas versões simplificadas na sua interface”.² Uma ferramenta que diz, na interface, “soma dois números” pode carregar, na descrição que o modelo de fato consome, uma instrução para ler ~/.ssh/id_rsa e exfiltrá-lo por um parâmetro oculto.² A OWASP agora cataloga isso como uma classe de ataque nomeada.³

Duas propriedades o tornam perverso de um jeito que o isolamento não alcança:

Ele dispara sem que a ferramenta seja chamada. As instruções envenenadas vivem na descrição, que o modelo ingere quando considera o conjunto de ferramentas – então o ataque pode acontecer mesmo que a função nunca execute.³ Não há nenhum evento de código para colocar em sandbox.

A confiança é concedida uma vez e abusada depois. As descrições de ferramentas são revisadas no momento da conexão, quando você aprova um servidor. As respostas então fluem direto para o contexto do modelo em tempo de execução sem nenhuma verificação equivalente – e, na descoberta do “rug pull” da Invariant, “um servidor malicioso pode mudar a descrição da ferramenta depois que o cliente já a aprovou”.² Sua aprovação única não protege nada contínuo.

A demonstração canônica não é hipotética. Pesquisadores envenenaram uma issue do GitHub com texto injetado; quando um desenvolvedor pediu ao assistente para revisar as issues abertas, o agente ingeriu a issue, seguiu as instruções ocultas, usou o token do desenvolvedor para ler repositórios privados e vazou o conteúdo em um pull request público.³ Cada ação individual estava autorizada. O agente fez exatamente aquilo para que um agente serve. É por isso que um sandbox de código é irrelevante aqui – nada não confiável executou; um texto não confiável simplesmente foi promovido a instrução dentro de um processo que segura credenciais reais. É a mesma lição que Ken Thompson deixou em Reflections on Trusting Trust: o perigo não é o código que você inspeciona, é a confiança que você estende sem inspecionar.

Defendendo a segunda entrada

Se o isolamento é a defesa para código, a defesa para saída de ferramenta é tratar a fronteira entre dado e instrução como real, em tempo de execução, toda vez – a coisa que o modelo de aprovação na conexão pula. A própria orientação da Microsoft sobre MCP chega ao mesmo lugar, recomendando “prompt shields” que detectam e filtram instruções injetadas, mais o spotlighting, em que “incluir delimitadores na mensagem de sistema demarca explicitamente a localização do texto de entrada” para que o modelo distinga conteúdo de comando.⁴ Concretamente:

• Verifique as descrições de novo em tempo de execução, não só na aprovação. Fixe a definição de ferramenta que você aprovou e detecte quando a descrição de um servidor muda por baixo de você. O rug pull só funciona porque ninguém olha duas vezes.²
• Marque explicitamente a fronteira dado/instrução. Respostas de ferramentas são dados, não diretivas – e a versão prática é o spotlighting: delimitar a saída de ferramenta no contexto para que o modelo seja informado, estruturalmente, de que aquilo é conteúdo sobre o qual raciocinar, e não comandos a seguir.⁴ Isso combina com autorização em nível de ação nas ferramentas MCP, de modo que mesmo um agente sequestrado não consiga alcançar as chamadas de alta consequência.
• Aplique o menor privilégio ao caminho autorizado. O exploit do GitHub funcionou porque um único agente segurava tanto “ler repositórios privados” quanto “abrir PR público” – e o menor privilégio é exatamente o que a Microsoft nomeia como higiene fundamental contra esses ataques.⁴ A segurança por compartimentalização de Joanna Rutkowska é o mesmo instinto no nível da arquitetura: assumir que um domínio está comprometido e garantir que ele não alcance os outros. Um agente que lê issues não deveria ser o agente que segura o caminho de exfiltração.
• Observe a saída, porque a exfiltração é o prêmio. A maioria desses ataques termina no mesmo passo – dados saindo. Uma visão de egresso silencioso captura a consequência mesmo quando a injeção escapa pela porta da frente.

Nenhuma dessas coisas é um muro. São portões em um caminho que o agente foi feito para percorrer – o tipo mais difícil e menos satisfatório de segurança, e o tipo que a segunda entrada realmente exige.

O que eu tiro disso

O modelo mental que estou guardando é que “meu agente está em sandbox?” é a pergunta errada, porque ela assume silenciosamente que há uma fronteira a defender. Há duas. O código que meu modelo escreve precisa de um muro – e, graças a trabalhos como o de Willison, construir esse muro está virando uma tarefa normal de engenharia com uma especificação clara. A saída de ferramenta que meu modelo lê precisa de algo totalmente diferente: um runtime que nunca deixe um dado virar silenciosamente uma instrução, e um modelo de autorização tão apertado que um agente sequestrado ainda assim não consiga fazer muita coisa. Confundi-los é como você acaba se sentindo protegido – “olha, o código roda em WASM” – enquanto continua escancarado pela entrada em que ninguém pôs um portão.

A continuidade mais profunda é que os agentes não inventaram tanto uma nova categoria de vulnerabilidade quanto acrescentaram novos lugares para uma antiga morar. Entrada não confiável sempre foi a raiz da segurança; a era dos agentes só lhe deu duas portas novas – uma que você consegue trancar com isolamento, uma que você só consegue vigiar com disciplina. Construa o muro e o portão. Um muro sozinho, em um sistema com duas entradas, é meia defesa que parece inteira.

Perguntas frequentes

Quais são as duas entradas não confiáveis em um agente de IA?

Código gerado pelo modelo que seu runtime executa, e saída de ferramenta ou servidor que seu modelo lê e sobre a qual então age. A primeira pode danificar o host diretamente; a segunda pode sequestrar as decisões do agente usando as credenciais e permissões que o agente já tem. Elas exigem defesas diferentes – isolamento para código, separação dado/instrução em tempo de execução e autorização rigorosa para saída de ferramenta.¹²

Um sandbox de código protege contra envenenamento de ferramentas MCP?

Não. O envenenamento de ferramentas não executa código no seu host – ele embute na descrição de uma ferramenta instruções que o modelo trata como confiáveis, e pode disparar mesmo que a ferramenta nunca seja chamada.²³ Um sandbox isola a execução, então não faz nada contra um ataque que pega carona nas ações legítimas e autorizadas do agente.

O que é um ataque de envenenamento de ferramentas?

Divulgado pela Invariant Labs em abril de 2025, é um ataque em que “instruções maliciosas são embutidas em descrições de ferramentas MCP que são invisíveis para os usuários, mas visíveis para os modelos de IA”.² Como o modelo vê a descrição completa enquanto o usuário vê um rótulo simplificado na interface, instruções ocultas – por exemplo, ler chaves SSH e exfiltrá-las – podem sequestrar o agente. A OWASP agora a rastreia como uma classe de ataque nomeada.²³

O que é a lacuna de confiança entre conexão e execução?

As descrições de ferramentas são revisadas uma vez, quando você aprova um servidor (momento da conexão). As respostas de ferramentas então fluem para o contexto do modelo em tempo de execução sem nenhuma verificação equivalente, e um servidor malicioso pode mudar uma descrição depois da aprovação (um “rug pull”).² A correção é verificar em tempo de execução, não só na aprovação.

Fontes