SSRF em agentes de IA: como proteger consultas a URLs

Uma ferramenta de leitura também pode alcançar o sistema errado

Um agente recebe um link em uma solicitação e chama a ferramenta de consulta. A ferramenta roda em um servidor que possui acesso à rede interna. O endereço pode levar a um serviço que o remetente nunca conseguiria consultar diretamente.

Esse é o risco de Server-Side Request Forgery, ou SSRF: uma aplicação é induzida a fazer requisições para destinos indevidos usando sua posição na rede. Em agentes, o endereço pode surgir em documentos, resultados de busca, argumentos de ferramentas ou na própria saída do modelo.

A orientação “consulte apenas fontes confiáveis” ajuda a definir o trabalho, mas o controle precisa existir no cliente HTTP e na infraestrutura que executam a consulta.

Este guia trata da fronteira de rede de uma ferramenta que busca conteúdo por URL. A segurança de agentes cobre permissões e progressão de autonomia. Aqui, o artefato final é uma política de destinos aplicada antes e durante a conexão.

Separe consulta pública de integração autenticada

Uma ferramenta de navegação pública não deveria herdar os acessos de um conector interno.

Para consultar o CRM, prefira uma operação delimitada como consultar_oportunidade_por_id. O adaptador fixa origem, rota e autenticação, valida o objeto e devolve somente os campos autorizados. O modelo não precisa montar uma URL completa para essa função.

Para pesquisar páginas públicas, use outro ambiente, sem tokens internos, cookies corporativos ou acesso lateral à infraestrutura. O catálogo de ferramentas deve registrar essa separação, inclusive os destinos alcançáveis por cada capacidade.

Essa distinção reduz a chance de uma consulta externa carregar uma credencial que pertence a outro sistema. Também torna mais simples interromper a navegação pública sem suspender integrações empresariais autorizadas.

Escolha entre destinos conhecidos e navegação aberta

A orientação da OWASP distingue aplicações que chamam serviços conhecidos de aplicações que precisam acessar destinos externos variáveis. As duas situações exigem políticas diferentes.

Destinos conhecidos

Use uma lista explícita de hosts e operações permitidos. Sempre que possível, aceite um identificador ou domínio validado e construa a requisição no adaptador com protocolo, porta e caminho fixados.

A permissão precisa ser precisa. Comparar se um texto “contém” o nome da empresa pode aceitar um host diferente. Também não convém liberar todos os subdomínios quando somente um serviço foi homologado.

Navegação pública

Quando os destinos variam, a lista de hosts pode ser inviável. A defesa passa a depender de isolamento forte de saída, validação de endereços públicos e proibição de alcançar redes internas, serviços de metadados e destinos especiais.

Mesmo um endereço público pode pertencer à própria empresa ou expor um serviço administrativo. A equipe precisa manter as restrições adicionais do seu ambiente. Uma checagem genérica de IP público não define toda a política empresarial.

Valide a URL com o mesmo contrato usado para conectar

Uma URL reúne componentes com significados diferentes. Esquema, host, porta, caminho, credenciais embutidas e query precisam ser tratados separadamente por um parser adequado à tecnologia usada.

Para um buscador limitado a páginas HTTPS, uma política pode exigir:

• somente https;
• ausência de usuário e senha na URL;
• porta autorizada;
• host interpretado de forma inequívoca;
• rejeição de formatos ambíguos ou malformados;
• limites de comprimento e parâmetros;
• caminho compatível com a função, quando o destino for conhecido.

Não use uma expressão regular isolada como implementação completa de segurança. Se diferentes componentes interpretam a mesma entrada de formas distintas, o sistema deve rejeitar a ambiguidade, em vez de escolher silenciosamente a interpretação mais conveniente.

Normalize somente o que o contrato autoriza. A validação precisa corresponder aos bytes e ao destino que serão efetivamente usados pelo cliente. Um proxy ou serviço intermediário que interpreta novamente o endereço também participa dessa fronteira.

Confira o DNS e vincule a conexão ao endereço aprovado

Um domínio aparentemente permitido pode resolver para um endereço que a ferramenta não deveria acessar. A política deve examinar os resultados IPv4 e IPv6 relevantes e rejeitar destinos fora das redes autorizadas.

No perfil de navegação pública, isso inclui loopback, redes privadas, link-local, endereços de metadados e outras faixas especiais. Se uma resposta DNS mistura um endereço aceito e outro proibido, não deixe o cliente escolher o segundo por fallback.

Há ainda uma distância perigosa entre verificar DNS e abrir a conexão. Se o cliente fizer outra resolução sem controle, pode acabar conectando a um endereço diferente do que foi validado. Esse problema aparece nas defesas contra DNS rebinding.

A implementação deve conectar somente a endereços aprovados, preservando o hostname original para Host, SNI e validação do certificado TLS. Desativar a verificação do certificado para facilitar esse vínculo cria outro problema de segurança.

A OWASP recomenda aplicar a política também em retentativas e conexões alternativas. Use uma biblioteca, proxy ou mecanismo de transporte que sustente essa garantia. Um teste de parser em memória não prova que o cliente real a respeita.

Bloqueie redirecionamentos automáticos por padrão

Um destino inicialmente aceito pode responder com redirecionamento para outro host ou endereço. Se a biblioteca segue o novo endereço sem passar pela política, o primeiro bloqueio perde efeito.

A opção mais simples é desativar o seguimento automático. Quando o processo realmente exige redirecionamentos, trate cada salto como uma nova decisão de destino, com limite de quantidade e a mesma validação de URL, DNS e conexão.

Cabeçalhos e credenciais também precisam de escopo. Nunca encaminhe automaticamente autorização corporativa, cookies ou dados sensíveis a um novo host. A ferramenta de navegação pública deve começar sem esses segredos.

O guia de paginação de APIs aborda URLs de continuação. Elas também precisam vir do envelope oficial do serviço e respeitar o adaptador; uma URL dentro do conteúdo de um registro não ganha autoridade para receber credenciais.

Faça a rede sustentar a decisão da aplicação

A validação de entrada pode falhar. Restrinja a saída na infraestrutura para que o processo de consulta não consiga alcançar livremente redes e serviços proibidos.

O desenho pode usar um serviço de fetch isolado, regras de firewall e um proxy de saída que aplique a política. O importante é comprovar que não existe outro caminho de rede sem o mesmo controle.

Inclua na revisão:

• rotas para serviços internos e administrativos;
• resolução DNS usada pelo processo;
• tratamento de IPv6;
• proxy configurado e possibilidade de contorná-lo;
• acesso a serviços de metadados da nuvem;
• bibliotecas que seguem redirects ou usam protocolos adicionais;
• credenciais e volumes montados no ambiente de consulta.

Controles do provedor de nuvem podem acrescentar defesa, mas não substituem a política de saída. A abordagem de Zero Trust para agentes ajuda a manter identidade, recurso e acesso verificáveis em cada fronteira.

Limite também o que uma resposta aceita pode consumir

Um destino permitido ainda pode devolver um conteúdo enorme, lento ou incompatível. Defina timeout de conexão e leitura, quantidade máxima de bytes, limite após descompressão e tipos de conteúdo esperados.

Quando houver navegador ou renderizador, considere os recursos secundários que ele tenta carregar. Validar apenas a URL inicial não limita automaticamente scripts, imagens e novas requisições da página. O mesmo ambiente de saída deve controlar essas conexões.

O conteúdo devolvido continua não confiável. A proteção contra SSRF controla o destino alcançado; a proteção contra prompt injection trata instruções indevidas presentes no material lido. As duas barreiras precisam funcionar independentemente.

Laboratório local de política, sem chamadas de rede

Em 20 de outubro de 2026, a Júpiter executou uma fixture em Python com um domínio fictício, docs.example.com, e respostas DNS fornecidas pelo próprio teste. Nenhuma URL foi acessada.

O perfil aceitou somente HTTPS, host exato, porta padrão, caminho iniciado em /public/, ausência de credenciais, query e fragmento e uma lista não vazia de endereços públicos.

Foram conferidos dez casos estáticos. O endereço compatível com a política foi permitido. Os demais foram recusados por protocolo, host diferente, credencial embutida, loopback IPv4, loopback IPv6, resposta DNS mista, ausência de DNS, porta alternativa ou caminho fora do perfil. Um destino adicional de redirecionamento, representado por uma entrada separada, também foi bloqueado.

O laboratório verifica decisões sobre entradas sintéticas. Não implementa um buscador seguro de produção e não comprova defesa contra rebinding, diferenças entre parsers, normalização de caminho, proxies ou subrequisições de navegador. O transporte real precisa de testes específicos, com destinos controlados e autorização.

Critérios para homologar a ferramenta

Antes de liberar, peça evidência de que uma requisição proibida não chegou ao destino de teste. A mensagem “bloqueado” no agente, sozinha, não comprova isso.

Registre identidade solicitante, versão da política, classe do destino, decisão, motivo, quantidade de redirecionamentos e resultado do transporte. Proteja query strings, tokens e conteúdo sensível nos logs.

O responsável técnico deve testar host permitido que resolve para endereço proibido, mudança de endereço entre validação e conexão, IPv6, fallback, redirects, limites de resposta e rotas alternativas de saída. Execute esses testes em ambiente próprio, sem sondar infraestrutura de terceiros.

O dono do processo aprova os destinos necessários. A segurança valida a política e a evidência de bloqueio. Exceções precisam de finalidade, prazo e responsável; não devem nascer de um argumento improvisado pelo modelo.

Fonte oficial verificada em 20 de outubro de 2026

• OWASP: Server-Side Request Forgery Prevention Cheat Sheet, para listas de destinos, validação de endereço, DNS rebinding, redirecionamentos, isolamento de rede e metadados de nuvem.

A separação entre navegação pública e integração autenticada e a ficha de homologação são recomendações de arquitetura da Júpiter. Comece pela ferramenta que hoje aceita uma URL livre e confira, no transporte e na rede, quais destinos ela realmente consegue alcançar.