Para impedir que um agente acesse endereços internos por URLs encontradas em documentos, aplique a restrição no serviço que faz a conexão. Valide o endereço, resolva o nome de domínio, confira os destinos de rede e bloqueie redirecionamentos não autorizados. Complete a verificação com uma política de saída de rede que impeça o acesso aos serviços internos.
Uma instrução no prompt pode orientar o comportamento do agente, mas a decisão final precisa estar no componente que baixa a página, imagem ou anexo. Esse componente deve tratar todo link extraído de PDF, planilha, mensagem ou resultado de busca como entrada não confiável. A revisão abaixo acompanha o caminho entre o documento e a conexão, com foco no destino efetivo de cada requisição.
Resumo rápido
- Extraia links como dados e encaminhe cada solicitação a um serviço de busca controlado.
- Prefira destinos previamente aprovados quando o processo permitir.
- Valide protocolo, domínio, porta e todos os endereços obtidos na resolução.
- Confira novamente o destino em cada redirecionamento permitido.
- Teste o bloqueio com serviços simulados e evidência de que nenhuma conexão interna ocorreu.
Como o link de um documento vira uma conexão interna
Imagine que um documento contém um endereço apresentado como “comprovante da proposta”. O agente pede que sua ferramenta abra esse endereço para completar a análise. A requisição parte do servidor da aplicação, que pode alcançar serviços indisponíveis para quem enviou o documento. É nesse deslocamento de origem que surge o problema.
A orientação da OWASP sobre SSRF, sigla para falsificação de requisição do lado do servidor, descreve esse abuso do aplicativo para interagir com destinos indevidos. No caso do agente, a URL pode chegar como parte de um conteúdo que ele recebeu para ler, sem uma solicitação direta do usuário para acessar a rede interna.
O risco não depende de uma frase maliciosa explícita. Um rodapé, imagem remota ou link em tabela pode acionar um caminho automático de download. Por isso, inventarie os componentes que abrem endereços: leitor de páginas, conversor de documentos, carregador de imagens e ferramenta de pesquisa. Todos precisam passar pelo mesmo controle de destino.
A proteção tem um limite concreto: decidir para onde a aplicação pode conectar. A análise de instruções escondidas no conteúdo é outro trabalho, tratado no guia de injeção indireta em pipelines RAG. Aqui, mesmo um texto aparentemente inocente deve enfrentar a mesma validação de rede.
Defina uma política de destinos antes de filtrar URLs
Comece pelo processo de negócio. Um agente que consulta apenas portais de fornecedores conhecidos pode receber uma lista de domínios aprovados. Outro, dedicado a pesquisa aberta, precisa buscar páginas públicas variadas. Essas situações exigem políticas diferentes, mas ambas podem proibir acesso à rede interna e a destinos especiais.
Para portais conhecidos, considere receber um identificador de fornecedor e montar a URL no servidor a partir de um cadastro revisado. Essa é uma proposta de desenho para reduzir a liberdade da entrada. O documento deixa de determinar host e porta, e passa a informar apenas o identificador do recurso necessário.
| Origem do endereço | Política sugerida | Verificação necessária |
|---|---|---|
| Fornecedor cadastrado | Domínio e caminho aprovados | Destino resolvido e redirecionamentos |
| Pesquisa na web pública | Somente destinos públicos permitidos | Classificação de todos os IPs e saída controlada |
| Link para sistema interno | Recusar no buscador público | Encaminhar à integração própria, se autorizada |
| Protocolo desconhecido | Recusar | Não delegar a outro programa automaticamente |
| Endereço com interpretação ambígua | Recusar e registrar o motivo | Evitar normalizações sucessivas incompatíveis |
Documente protocolos e portas aceitos. Para um buscador de documentos públicos, permitir apenas HTTPS nas portas previstas pode ser uma escolha adequada. Se houver necessidade de HTTP, registre a exceção e seus controles. A política deve nascer do uso real, sem transformar compatibilidade com qualquer endereço em requisito automático.
Separe integrações internas de navegação aberta. Um conector de estoque pode acessar um serviço privado específico com contrato próprio. Isso não exige que o leitor de documentos tenha o mesmo alcance. O inventário dessas rotas pode seguir a organização apresentada em ferramentas isoladas para agentes com MCP.
Valide o endereço com um analisador consistente
Use uma biblioteca de análise de URLs para separar esquema, hostname, porta e demais componentes. Evite procurar apenas uma palavra no texto completo ou aceitar tudo que começa com o nome de um domínio. Compare o hostname interpretado pelo analisador com o domínio aprovado, usando uma regra explícita para subdomínios.
A documentação de urllib.parse, do Python, alerta que analisar uma URL não equivale a validá-la. Portanto, receber componentes sem erro não significa que o destino atende à política. Faça verificações explícitas de esquema, hostname, porta e componentes que a aplicação não utiliza.
Rejeite credenciais embutidas no endereço quando elas não fizerem parte do processo aprovado. Elas podem tornar a leitura visual confusa e ainda introduzir dados sensíveis nos logs. Evite aceitar formatos alternativos de endereço que o time não consegue interpretar e testar com o cliente HTTP utilizado.
Defina uma única representação para comparar e executar a requisição. Se um componente valida uma forma e outro transforma a URL depois, a comparação perde valor. Teste também espaços, caracteres de controle, nomes internacionalizados e portas inválidas. A resposta esperada para uma entrada ambígua deve ser recusa compreensível, sem tentativa automática de adivinhar o destino.
Faça a revisão por componente. O extrator de PDF pode retornar texto; o planejador pode selecionar links; apenas o buscador controlado deve abrir a conexão. Essa divisão permite demonstrar que um link fora da política permaneceu um dado no documento, em vez de virar uma visita de rede.
Confira DNS, endereço efetivo e redirecionamentos
DNS é o sistema que associa nomes de domínio a endereços de rede. A política precisa examinar os resultados obtidos, inclusive nas famílias IPv4 e IPv6. Um domínio com aparência pública não prova que todos os endereços que ele resolve sejam destinos permitidos para o buscador.
A IANA mantém um registro de blocos IPv4 de uso especial, com propriedades que ajudam a distinguir suas finalidades. Use registros e bibliotecas mantidos, em vez de uma lista improvisada de poucos prefixos. A classificação deve abranger também IPv6 e as condições específicas da infraestrutura.
A biblioteca ipaddress do Python oferece análise e propriedades de endereços IPv4 e IPv6. Sua documentação registra diferenças entre propriedades como endereço privado e global. Não suponha que “não privado” significa automaticamente “permitido”. Defina quais categorias sua aplicação recusa e teste a versão de biblioteca usada.
Entre a validação e a conexão existe outro cuidado: o cliente de rede precisa usar o destino que foi validado. Se resolver o domínio novamente por outro caminho, pode conectar a um endereço diferente. Essa é uma condição que exige revisão da biblioteca e da arquitetura, preservando a validação do certificado TLS e o hostname esperado.
Para redirecionamentos, prefira desativar o seguimento automático quando não for necessário. Quando o processo exigir essa função, valide cada próximo endereço antes da conexão e estabeleça um limite de etapas. Uma URL aprovada pode responder indicando outro destino; a aprovação inicial não deve ser herdada por essa nova visita.
Inclua proxies na revisão. Se o proxy resolve nomes ou abre a conexão final, a política precisa ser aplicada nesse ponto ou receber uma garantia equivalente da infraestrutura. Não presuma que uma checagem local cobre o caminho inteiro quando outro serviço decide o endereço efetivo.
Exemplo: análise de propostas em uma gráfica de Recife
Considere uma gráfica fictícia de Recife que recebe propostas de fornecedores em PDF. O agente extrai prazo, especificação do papel e links de fichas técnicas. Um documento traz um link que aparenta apontar para uma ficha, mas seu destino efetivo pertence à rede privada. O exemplo é ilustrativo e não descreve um incidente real.
A equipe estabelece que fichas técnicas podem ser baixadas apenas pelo buscador público. O extrator não abre imagens remotas. O planejador envia o endereço ao buscador, que analisa os componentes e resolve o domínio. Quando o destino não atende à política, a ferramenta devolve uma recusa com código de motivo e identificação do documento.
O agente continua a tarefa com os dados disponíveis e informa que não conseguiu consultar aquela ficha. Não deve resumir conteúdo que não leu nem concluir que o fornecedor é fraudulento. A recusa prova apenas que o endereço não passou pela política aplicada naquele momento.
Para validar o fluxo, a gráfica usa um servidor simulado em uma rede de testes. Um cenário fornece página pública permitida; outro tenta apontar para o destino interno simulado; outro começa em uma página permitida e redireciona. O aceite exige resposta correta ao usuário e evidência técnica de que o serviço interno não recebeu a conexão proibida.
Se a ficha precisar realmente de acesso interno, a operação segue outro caminho documentado, por integração específica. O documento não ganha poder para ampliar a conectividade do buscador. O responsável comercial recebe uma pendência clara para resolver a falta da informação.
Como testar o bloqueio e observar a operação
Monte uma matriz de entradas e decisões esperadas antes de implementar. Inclua URL pública aprovada, hostname não aprovado, endereço de loopback, rede privada, endereço de uso especial, IPv6, redirecionamento e falha de resolução. Use destinos simulados sob controle da equipe, sem sondar serviços reais de terceiros ou da nuvem.
Meça dois eventos: a decisão tomada pelo buscador e a conexão efetivamente observada. Um log de “bloqueado” não basta se algum carregador auxiliar já buscou uma imagem antes da recusa. Observe os acessos do servidor de teste e, quando disponível, os registros de saída da infraestrutura.
Configure limites de tempo e tamanho do download. Esses limites são complementos operacionais: um destino permitido ainda pode responder lentamente ou entregar conteúdo excessivo. Trate também arquivos recebidos com a validação específica do formato, descrita no guia de anexos compactados perigosos.
Registre a versão da política, a ferramenta solicitante, o hostname, o motivo da decisão e um identificador de correlação. Evite armazenar a URL completa quando parâmetros puderem conter dados pessoais ou credenciais. A pessoa que investiga deve conseguir relacionar a falha ao documento sem expor informações desnecessárias.
Antes de liberar uma alteração, repita a matriz com o cliente HTTP e o proxy reais da aplicação. Mudanças nesses componentes podem afetar resolução, redirecionamento e interpretação. Inclua na aprovação a evidência do bloqueio na rede, além da resposta produzida pelo agente.
Erros comuns
Filtrar apenas o texto visível: a legenda do link e o endereço real podem ser diferentes. A validação deve receber a URL que será usada na conexão, incluindo links extraídos de imagens ou conversões de documentos.
Bloquear somente uma faixa privada: isso deixa outras categorias e IPv6 fora da análise. Mantenha uma política de classificação completa e testes que cubram as famílias de endereço aceitas pelo buscador.
Confiar na primeira URL: um redirecionamento cria outra decisão de destino. Não encaminhe automaticamente autenticação e outros cabeçalhos sensíveis para hosts diferentes. Configure o cliente de forma coerente com a política.
Usar o modelo como barreira final: instruções podem orientar a escolha da ferramenta, mas não substituem a recusa na camada que abre a conexão. A mesma regra deve valer para chamadas diretas e tarefas automáticas.
Perguntas frequentes
Uma lista de domínios aprovados resolve tudo?
Ela reduz a superfície quando o processo permite destinos conhecidos. Ainda é necessário verificar resolução, redirecionamentos e caminho da conexão. O nome aprovado precisa levar a um destino permitido no momento da busca.
Posso permitir links internos enviados por funcionários?
Use uma integração interna específica, com destinos e finalidade definidos. Documentos recebidos de funcionários também podem incorporar conteúdo externo. Evite usar a identidade de quem enviou como substituta da política do buscador.
O agente deve apagar o link bloqueado?
Não é necessário alterar o documento original. Preserve a evidência conforme a política da empresa e registre a recusa. Na resposta, explique que o conteúdo daquele endereço não foi consultado e identifique a informação pendente.
Como diferenciar bloqueio de falha temporária?
Use códigos distintos para destino proibido, resolução indisponível, tempo esgotado e erro do serviço remoto. A aplicação decide quais falhas permitem nova tentativa, sem transformar uma recusa de política em repetição automática.
