Radar Tech: SSRF na ferramentaria de IA do Google acende alerta para arquitetos

Subtítulo: Vulnerabilidade de Server-Side Request Forgery em tooling oficial de IA mostra por que agente que busca URLs pede decisão de arquitetura de segurança — e não um filtro solto.

Nas últimas 24h, um relato ganhou força na comunidade de segurança: uma vulnerabilidade de SSRF (Server-Side Request Forgery) foi reportada em ferramentaria oficial de IA do Google. O detalhe que chama a atenção não é só a exposição em si, mas o vetor: a falha vive na camada em que um agente de IA recebe ou fabrica uma URL e faz o servidor buscá-la. No fim, é exatamente o tipo de superfície que a maioria dos pipelines de agentes está construindo agora, em muitos casos sem uma decisão explícita de arquitetura.

O que é o risco, de novo

SSRF acontece quando o aplicativo faz uma requisição de rede a partir do servidor para um destino parcialmente controlado pelo atacante. Em um agente de IA com uma tool do tipo fetch_url, o fluxo típico é:

• O modelo recebe uma mensagem do usuário (ou gera, a partir de contexto ambíguo) uma chamada de ferramenta apontando para uma URL.
• Um "fetcher" executa essa requisição server-side.
• Se não há validação séria de destino, resolução e redirecionamentos, o fetcher pode alcançar o metadata service da nuvem (a famosa 169.254.169.254) e vazar credenciais na resposta entregue ao modelo.

O que torna os agentes um caso à parte é a combinação: a URL vem de saída não-determinística do modelo; o fetcher roda com as credenciais do serviço; e redirects + DNS rebinding escondem o destino real da requisição. Um único filtro na UI, ou uma "validação" na entrada, não cobre isso — é um problema arquitetural, não um bug de uma linha.

O que fazer na prática

A resposta defensiva não é desligar a tool, e sim tomar uma decisão explícita (ADR) de como ela é isolada. Na prática, as camadas que fazem diferença são:

• Validação & allowlist na aplicação: só http/https, host em allowlist explícita, normalização de IPs disfarçados (decimal, hex, userinfo) e bloqueio de ranges internos/link-local antes de qualquer resolução.
• Pinning de DNS (anti-rebinding): resolver uma única vez e usar exatamente o mesmo IP na conexão, fechando a janela TOCTOU.
• Egresso segmentado: rota única de saída via proxy/política de rede que nega CIDs privados, e bloqueio do metadata service (IMDS/169.254.169.254).
• Tratamento de redirects: revalidar o destino final a cada hop — nunca confiar só na primeira URL.
• Sanitização da resposta: truncar/tipar o conteúdo antes de devolver ao modelo.

Nenhuma dessas camadas, sozinha, resolve. A utilidade está em combiná-las — é disso que trata um bom ADR de segurança.

Para o marketplace

Para equipes que querem deixar isso concreto, publicamos hoje no catálogo um pacote de prompts de arquitetura que leva um agente de IA a escrever um ADR completo de mitigação de SSRF para fetch tooling de agentes — com regras de borda, exemplos few-shot, harness de verificação e templates para Kubernetes/Serverless. São múltiplos arquivos complementares, não um prompt solto.

Se você mantém um agente que busca URLs de usuários, vale a pena tratar o assunto como decisão de arquitetura antes que a notícia de hoje seja "ameaça ativa" na sua própria base.

Post do Radar Tech — acompanhamento diário dos tópicos mais comentados em engenharia de software e segurança da informação.