Antes de um agente de IA usar um link encurtado, ele deve descobrir o endereço de destino em um ambiente controlado e verificar se a ação pretendida é permitida nesse endereço. O domínio visível no link curto identifica o serviço de redirecionamento, não necessariamente a empresa, o arquivo ou o formulário que receberá a próxima interação.
Resolver o destino é uma etapa de inspeção. Não autoriza login, envio de arquivos, preenchimento de dados nem execução de instruções encontradas na página. A proposta abaixo separa descoberta, validação e ação para que uma automação não transforme um endereço desconhecido em uma permissão ampla de navegação.
Resumo rápido
- Trate links curtos como endereços cujo destino ainda precisa ser verificado.
- Inspecione cada redirecionamento antes de permitir o próximo acesso.
- Separe o resolvedor das sessões autenticadas da equipe.
- Bloqueie endereços internos e destinos fora do escopo permitido.
- Peça nova aprovação quando mudar o destino ou a ação solicitada.
Por que o endereço curto não define a autorização
Um link recebido em uma conversa pode levar a uma página, que encaminha para outra, até chegar a um arquivo ou formulário. O texto da mensagem pode descrever uma finalidade legítima, mas não comprova quem controla o destino. Por isso, a decisão precisa considerar o endereço efetivamente acessado e a operação que o agente vai executar nele.
A especificação HTTP do IETF descreve respostas de redirecionamento e o campo Location, usado para indicar outro endereço. Para o desenho da automação, a consequência é simples: receber uma resposta que aponta para outra URL deve abrir uma nova verificação. Não é suficiente aprovar apenas o primeiro domínio da cadeia.
Imagine que a pessoa autorizou consultar o catálogo público de um fornecedor. Se o endereço levar a um serviço de armazenamento que pede acesso à conta corporativa, a ação mudou. Consultar um catálogo e conceder acesso são decisões distintas. Mesmo que o documento seja útil, o agente deve parar no limite da autorização e explicar o que encontrou.
Outra distinção é entre resolver e reputar. Descobrir que o endereço termina em determinado domínio esclarece o caminho observado naquele momento. Isso não prova que o conteúdo é verdadeiro, que o arquivo é seguro ou que o remetente está autorizado a solicitar dados. Cada uma dessas perguntas exige uma regra própria no fluxo de trabalho.
Como resolver destinos com uma ferramenta restrita
O resolvedor deve ser um componente pequeno, dedicado a inspecionar endereços. Recomenda-se executá-lo sem os cookies, as credenciais e os arquivos de trabalho do navegador usado pelo agente. A entrada é a URL recebida; a saída é um relatório de destinos observados e o motivo de permitir, bloquear ou interromper a inspeção.
Antes de qualquer conexão, o código deve analisar a URL com uma biblioteca apropriada, verificar o protocolo e aplicar a política de rede. Ao encontrar um redirecionamento, repete as verificações antes de acessar o próximo destino. Recomenda-se estabelecer limites de saltos, tempo, tamanho de resposta e protocolos permitidos, definidos pela equipe responsável pelo sistema.
A orientação de prevenção de SSRF da OWASP alerta para o risco de redirecionamentos contornarem a validação e recomenda desabilitar seu acompanhamento automático no cliente. SSRF é o uso indevido de um servidor para fazer requisições a outros destinos. Na proposta deste artigo, os próximos passos são examinados explicitamente pelo código e só então podem ser executados.
Isso requer controles de rede além da interpretação do modelo. Um endereço pode tentar alcançar serviços internos, a própria máquina ou destinos que a organização não pretende expor à ferramenta. Não peça ao agente que decida isso apenas lendo o texto da URL. A infraestrutura deve restringir o acesso e verificar a resolução dos nomes conforme sua política de segurança.
Se o serviço exigir login, interação com scripts ou um desafio de acesso para revelar o destino, informe que a resolução não foi concluída. Não há necessidade de contornar a barreira. A pessoa pode obter o endereço completo por um canal conhecido ou usar um procedimento de inspeção separado, sem liberar automaticamente a sessão de trabalho.
O que registrar e mostrar antes da ação
Uma confirmação útil mostra a origem do pedido, o domínio final observado, a finalidade e o que será enviado. A pessoa precisa entender se o agente apenas lerá uma página pública ou se transmitirá informações. Mostrar uma sequência longa de URLs sem explicar o efeito da ação costuma transferir trabalho técnico para quem aprova.
| Situação encontrada | Decisão recomendada | Informação para revisão |
|---|---|---|
| Destino público previsto no escopo | Permitir a leitura autorizada | Domínio e finalidade da consulta |
| Novo domínio externo | Aplicar a política de aprovação | Destino observado e relação com o pedido |
| Pedido de login ou permissão | Interromper a automação | Tipo de acesso solicitado |
| Endereço interno ou protocolo bloqueado | Recusar a conexão | Categoria do bloqueio, sem expor dados internos |
| Destino não determinado | Pedir endereço completo | Motivo da inspeção incompleta |
O registro técnico pode associar a solicitação à cadeia observada, ao resultado da política e ao momento da inspeção. Evite reproduzir no histórico visível parâmetros que possam conter códigos de acesso ou dados pessoais. A equipe precisa conseguir investigar o caminho sem transformar os próprios registros em mais um local de exposição de informações.
A aprovação deve ser específica. “Pode abrir links” é amplo demais para um agente que também tem ferramentas de envio. Prefira algo como permitir a leitura pública no domínio aprovado, sem autenticação e sem upload. Para estruturar essa separação, consulte o guia de permissões de agentes de IA e atribua capacidades distintas à inspeção e à execução.
Se a aprovação ocorrer em outro momento, faça uma nova validação imediatamente antes da ação e compare com o destino autorizado. Uma inspeção antiga não deve funcionar como passe permanente. Quando houver mudança relevante, apresente a diferença e interrompa até a política permitir a continuação. A validade da aprovação deve ser uma regra explícita do produto.
Como separar redirecionamento, navegação e instruções
O tratamento do redirecionamento também precisa considerar o tipo de requisição. A documentação do cabeçalho Location no MDN explica que certos códigos preservam o método original, enquanto o código 303 direciona para uma requisição GET. A recomendação operacional é não usar a descoberta de destino para repetir requisições com dados de trabalho.
Uma ferramenta de resolução não deve receber documentos da empresa para descobrir onde um link termina. Se o fluxo exige transmitir conteúdo, a etapa precisa acontecer depois da verificação, com autorização própria. Essa escolha torna mais simples demonstrar que a inspeção não carrega anexos, formulários ou instruções de envio para um domínio inesperado.
Depois da navegação, o conteúdo continua sendo uma entrada externa. Uma página pode pedir que o agente ignore regras, acesse outro sistema ou envie um arquivo para um endereço indicado no texto. A orientação da OWASP sobre prompt injection trata a separação entre instruções e conteúdo não confiável como parte da defesa. Na prática, o texto encontrado não deve ampliar as permissões da ferramenta.
O endereço final também não encerra o controle de navegação. Se a página abrir outro domínio durante a tarefa, a política deve ser reaplicada. Isso vale para botões, downloads e formulários. O fluxo de aprovação humana para agentes de IA ajuda a decidir quando uma mudança de destino ou de efeito pede intervenção.
Exemplo: agência de marketing em Recife
Considere um exemplo ilustrativo de uma agência de marketing em Recife. Uma pessoa recebe um link curto em uma conversa com um possível fornecedor de materiais gráficos. Ela pede ao agente para consultar o catálogo e resumir opções de acabamento. O agente tem acesso a documentos internos da agência, mas essa tarefa só exige leitura de informações públicas.
O resolvedor inspeciona o endereço sem usar a sessão corporativa. A cadeia observada termina em um domínio que não estava no cadastro do fornecedor. O sistema mostra essa diferença e mantém o acesso suspenso conforme a política adotada. A pessoa confirma o endereço completo com o contato conhecido antes de autorizar a leitura. O cenário não representa uma empresa real.
Em outro resultado possível, a página final exige autorização para acessar arquivos da conta da agência. O agente relata a exigência e interrompe. Não é adequado aceitar a permissão para tentar obter um catálogo. A pessoa pode solicitar uma versão pública ou receber o arquivo por um canal que já faça parte do processo comercial.
Depois de um destino permitido ser validado, o agente resume o conteúdo público e identifica a fonte consultada. Se a página instruir o envio de um briefing interno para receber uma proposta, o agente apresenta isso como uma solicitação do fornecedor. A decisão de compartilhar o briefing pertence a uma nova etapa, com arquivo, destinatário e finalidade definidos.
Erros comuns
Aprovar o serviço encurtador como se fosse o fornecedor. A política deve considerar quem receberá a interação final. Um domínio conhecido na primeira etapa não explica o conteúdo nem a finalidade do destino.
Seguir toda a cadeia automaticamente. Uma checagem no início pode perder efeito se o próximo salto não for analisado. Aplique a mesma política antes de cada conexão e bloqueie quando faltar informação para decidir.
Inspecionar com a conta de trabalho conectada. Isso mistura descoberta com uma sessão que pode ter acesso a dados. Use um ambiente separado e reserve autenticação para tarefas que realmente a exigem e já foram autorizadas.
Confundir acesso de leitura com ausência de efeito. Uma consulta ainda envia uma requisição ao destino. Links com tokens ou ações embutidas merecem cautela adicional. O resolvedor também precisa de uma política sobre quais links pode consultar e quais devem ser encaminhados para revisão sem abertura.
Confiar apenas em um pedido escrito ao modelo. Restrições de rede e de ferramenta precisam existir no código. Inclua no roteiro de testes do agente de IA cadeias longas, destinos bloqueados, alterações depois da aprovação e páginas que tentam impor novas instruções.
Prometer que o link é seguro. Prefira informar o que foi verificado e o que permanece desconhecido. Resolver um endereço produz evidência sobre um caminho observado; não certifica todo o comportamento futuro do site ou de um arquivo baixado.
Perguntas frequentes
Todo link encurtado deve ser bloqueado?
Não necessariamente. Uma equipe pode permitir inspeção controlada e definir quais destinos são aceitos para cada tarefa. Quando não houver ferramenta adequada ou autorização para consultar o endereço, pedir o link completo é uma alternativa simples e compreensível para a pessoa responsável.
O cadeado do navegador confirma que o fornecedor é legítimo?
Não use esse sinal como aprovação comercial do destinatário. A verificação deve relacionar o domínio observado à empresa e à tarefa autorizada, por um cadastro ou canal conhecido. A política de envio precisa considerar também o conteúdo e a finalidade do compartilhamento.
É suficiente olhar uma prévia do link?
A prévia pode ajudar a pessoa, mas não substitui a inspeção feita pela ferramenta no contexto da operação. Apresente o destino efetivamente observado e interrompa se houver divergência. Não trate o título ou a imagem da prévia como autorização para transmitir informações.
O agente pode usar um serviço público para expandir a URL?
Somente se a política permitir compartilhar o endereço com esse serviço. A própria URL pode conter dados ou um token de acesso. Um resolvedor administrado pela equipe oferece mais controle sobre exposição, rede e registros, desde que sua implementação seja revisada.
Como agir se o destino mudou depois da aprovação?
Interrompa e mostre a mudança relevante. A autorização deve estar vinculada ao destino e à operação revisados. Uma troca de domínio, um pedido de autenticação ou um envio adicional não deve ser absorvido como simples continuação da mesma tarefa.
