Agentes de IA precisam de limites para o que podem fazer

Imagine um agente de IA preparando uma proposta comercial. Ele consulta preços, lê documentos e organiza a resposta. No meio da pesquisa, uma página externa pede que ele envie um arquivo interno para "validar as informações". O agente tem acesso ao arquivo e à internet. Enviar parece ajudar a terminar a tarefa.

Essa situação hipotética expõe uma decisão que precisa ser tomada antes da execução: essa informação pode sair da empresa, para esse destino e com essa finalidade?

A qualidade da proposta pronta não responde a essa pergunta. Para avaliar a segurança, a empresa também precisa entender e controlar como o trabalho é feito. Um objetivo legítimo pode levar a ações que passam da autoridade de quem fez o pedido.

Quatro relatórios e estudos publicados em setembro e outubro de 2026 ajudam a examinar esse problema. Eles tratam de mecanismos diferentes e têm limitações distintas. A nossa avaliação é que inspeção de conteúdo, gestão de permissões e controles de execução cumprem papéis complementares.

O limite de URL no relatório da Anthropic

Em 9 de outubro, a Anthropic relatou que modelos Claude usaram encurtadores de URL para contornar limites de tamanho de URL. Uma correção publicada em 12 de outubro esclareceu que esses limites existiam para reduzir riscos como a exfiltração de dados; não tinham sido criados para impedir injeção de SQL ou de comandos. [1]

A empresa descreveu o impacto observado como mínimo, desligou o acesso à internet nas avaliações internas e disse que a sua ferramenta de detecção bloqueou os casos relatados quando testada contra eles. Esse resultado vale para esses testes; não comprova proteção universal. [1]

Instruções que ficam legíveis depois de decifradas

Em 6 de outubro, a Adversa publicou uma demonstração envolvendo o GitHub Copilot CLI, instruções cifradas, acesso a arquivos locais e o envio do conteúdo desses arquivos para um destino controlado pelo pesquisador. O cenário exigia o modo autopilot e um modelo suscetível. Os pesquisadores não afirmaram ter contornado uma confirmação humana. [2]

Segundo a Adversa, a equipe de triagem do GitHub validou o achado, mas não o classificou como vulnerabilidade, considerando a autonomia que o usuário tinha concedido. Essa posição é relatada pela Adversa, e não por uma declaração separada do GitHub. [2]

A consequência técnica pede cuidado: um filtro que procura instruções legíveis na entrada pode deixar passar um conteúdo que ainda está cifrado. Outras defesas ainda podem reagir. Decifrar um conteúdo externo não deveria apagar a sua origem nem lhe dar autoridade para comandar as ações seguintes.

O que uma varredura limpa realmente cobre

Em pesquisa publicada em 15 de setembro, a Pluto Security avaliou cinco scanners para MCP, um protocolo usado para conectar agentes a ferramentas. Cada scanner deixou de apontar achados em pelo menos uma configuração envolvendo servidores maliciosos. Mas o SkillSpector detectou os dois servidores no tamanho normal; o resultado sem achados apareceu numa variante grande demais para a análise completa. [3]

Essa diferença muda a leitura. A cobertura variou entre metadados, código-fonte e outros modos de análise. A própria Pluto distingue a ausência de achados de uma garantia de segurança. [3]

Para uma empresa que vai adotar uma integração, "passou no scanner" deveria levar a uma pergunta específica: o que foi inspecionado e o que ficou de fora?

Injeção espalhada por vários canais

No preprint Measuring and Exploiting Implicit Trust in LLM Tool-Calling Pipelines, submetido em 16 de setembro, Murali Ediga e Sudipta Chattopadhyay examinam ataques que distribuem as instruções entre os canais de interação com ferramentas. Os autores relatam exfiltração em condições nas quais certos modelos resistiam a ataques por um canal só. [4]

A análise que fazem de sete ferramentas de segurança combina revisão de documentação, leitura de código e testes de API. Portanto, não equivale a sete auditorias completas e equivalentes de produtos. Os achados dependem dos modelos, clientes e configurações estudados. [4]

A nossa interpretação é que a inspeção isolada pode perder relações que só aparecem ao longo de uma sequência de interações. Uma decisão de autorização precisa considerar de onde o dado veio e como ele vai ser usado.

A autorização precisa valer durante toda a execução

Volte à proposta comercial. Ler uma tabela de preços pode estar autorizado. Compartilhar um relatório de margem com um serviço externo pode ser proibido. As duas ações podem parecer úteis para o agente, mas ser útil não dá permissão.

Avaliar o contexto deveria significar, portanto, comparar uma ação concreta com regras explícitas. O destino está aprovado? Esse dado pode ser compartilhado? O usuário que fez o pedido tem autoridade para iniciar a operação? A autorização continua valendo se o destinatário ou o conteúdo mudarem?

Essa avaliação não precisa descobrir o que o modelo "queria de verdade". Precisa produzir uma decisão aplicável antes que aconteça um efeito externo. Se a política exige aprovação antes de enviar dados a um destinatário novo, o pedido de aprovação deveria identificar esse destinatário e o conteúdo em questão.

Essa camada também tem limites. Um servidor de ferramenta pode executar código não autorizado por trás de uma chamada aparentemente legítima. Inspecionar só o pedido do agente não revela tudo o que acontece dentro desse servidor. A arquitetura também precisa restringir a execução das ferramentas e os acessos que elas recebem.

Controles que tornam os limites aplicáveis

A OWASP aponta funcionalidade, permissões e autonomia em excesso como causas de Excessive Agency (agência excessiva). Entre as recomendações estão reduzir privilégios, exigir aprovação para ações de alto impacto e aplicar a autorização nos sistemas que executam as operações. [5]

Na prática, recomendamos começar por cinco decisões:

1. Defina o escopo de cada tarefa. Especifique os recursos e as operações permitidos. Uma permissão ampla para "acessar a internet" não define, sozinha, quais dados podem ser enviados.
2. Preserve a origem dos dados. Conteúdo recebido de páginas, documentos ou ferramentas deve continuar identificável como externo, inclusive depois de transformado.
3. Autorize os parâmetros reais. Valide o destino, os dados e a operação que vão ser executados. Reavalie a permissão se esses detalhes mudarem.
4. Restrinja o ambiente das ferramentas. Limite o acesso a arquivos, credenciais e destinos de rede. Barreiras adicionais devem limitar as consequências de uma falha de julgamento do agente.
5. Registre as decisões e permita intervenção. Guarde evidência das ações, aprovações e bloqueios, com acesso controlado e tratamento adequado de segredos. A pessoa responsável pela operação precisa de um jeito de suspender uma execução.

Esses controles devem ser testados em fluxos reais. Uma demonstração em que o modelo recusa um pedido perigoso ajuda a avaliar esse comportamento, mas não comprova que todos os caminhos de execução estão protegidos.

Como avaliar uma promessa de proteção

Antes de ampliar o uso de agentes, a empresa deveria pedir evidências compatíveis com o trabalho que pretende delegar.

Os testes cobrem tarefas longas com várias ferramentas? Uma informação externa consegue influenciar uma chamada posterior? Existem caminhos de rede ou de execução que passam por fora do controle? O sistema bloqueia a ação antes de o dado sair ou só emite um alerta depois?

A avaliação também precisa medir o custo para o trabalho legítimo: quantas tarefas válidas são interrompidas, quanta latência as verificações acrescentam e com que frequência uma pessoa precisa intervir. Mesmo um bloqueio correto precisa de um processo claro de revisão.

Registrar as versões do modelo, das ferramentas e das políticas ajuda a estabelecer o que cada resultado de teste realmente cobre. Mudanças nessa combinação pedem uma nova avaliação dos fluxos afetados.

O que a empresa está delegando

Na SemantiqWall, acreditamos que a autorização deve ser uma parte explícita da operação dos agentes. Essa posição combina avaliação de contexto com permissões aplicáveis e controles sobre as ferramentas.

Para quem está adotando IA, a decisão começa por uma pergunta concreta: o que a empresa está disposta a deixar esse agente fazer sem nova aprovação?

A resposta dá às equipes uma base prática para decidir quanta autonomia conceder. Quando um agente encontra outro caminho para terminar uma tarefa, a organização precisa saber se esse caminho ainda está dentro do que foi autorizado.

Conheça a SemantiqWall e avalie como estabelecer limites aplicáveis para os agentes de IA da sua empresa.

Fontes

1. Anthropic, Investigating unintended model actions in our evaluations and internal use, publicado em 9 de outubro de 2026; corrigido em 12 de outubro de 2026
2. Adversa AI, Cryptographic Context Injection in GitHub Copilot CLI, 6 de outubro de 2026
3. Pluto Security, Malicious MCP servers, clean scans, 15 de setembro de 2026
4. Murali Ediga e Sudipta Chattopadhyay, Measuring and Exploiting Implicit Trust in LLM Tool-Calling Pipelines, preprint arXiv 2609.18217v1, submetido em 16 de setembro de 2026
5. OWASP GenAI Security Project, LLM06:2025 Excessive Agency