Hackeando o Google Bard – Da injeção de prompt à exfiltração de dados
Um pesquisador de segurança mostra como o Google Bard pode ser enganado para exfiltrar partes da conversa privada de um usuário ao ler um Google Doc compartilhado com instruções ocultas e transformá-las em URLs de imagens Markdown que fazem callback. Os comentaristas usam isso como ponto de partida para examinar a injeção de prompt como uma fraqueza fundamental das arquiteturas atuais de LLMs, argumentando que prompts de sistema, fine-tuning ou modelos detectores não conseguem impedir tais ataques de forma confiável. Muitos concluem que, até que as arquiteturas evoluam para separar instruções de dados, os LLMs devem ser tratados como componentes não confiáveis e fortemente isolados em sandbox, especialmente quando conectados a e-mail, documentos ou outros sistemas sensíveis.
Vulnerabilidade do Bard e exfiltração de dados
- O Bard renderiza imagens Markdown e pode ler Google Docs como contexto.
- Um Doc compartilhado pode incluir instruções ocultas que fazem o Bard gerar URLs de imagens codificando partes da conversa privada.
- Quando a interface do Bard carrega essas imagens, a conversa da vítima é enviada ao servidor do atacante.
- Alguns leitores inicialmente entenderam errado; outros esclareceram que os dados exfiltrados são a conversa anterior do usuário com o Bard, e não novos dados aleatórios.
Injeção de prompt como um problema fundamental
- Prompts de sistema como “obedeça apenas à caixa de texto” ou “nunca faça X” são vistos como pouco confiáveis; atacantes podem mais tarde adicionar “ignore todas as instruções anteriores” dentro de conteúdo não confiável.
- Tentativas de sanitizar prompts (por exemplo, escape estilo “addslashes”, separar “instruções” vs “dados”) são relatadas como falhas na prática.
- Vários comentaristas comparam isso a XSS, injeção SQL ou sinalização in-band: um único canal não diferenciado para código e dados.
Modelos de segurança, permissões e sandboxing
- Muitos argumentam que LLMs devem ser tratados como componentes não confiáveis com sandboxes e permissões estritas, como apps de sistemas operacionais móveis.
- Forte preocupação com assistentes que podem ler e-mail, documentos, calendário etc., e então agir com base em instruções ocultas maliciosas em conteúdo acessível ao usuário, mas não confiável.
- Alguns propõem limitar o acesso do LLM apenas a dados que o usuário já está autorizado a ver; outros observam que isso não resolve os riscos de entrada não confiável ou de exfiltração.
Abordagens de detecção e seus limites
- Uma empresa afirma que detectores podem capturar esse ataque; críticos respondem que tais classificadores são probabilísticos, como antivírus, com falsos positivos/negativos.
- Para ameaças sérias de exfiltração de dados, comentaristas argumentam que “talvez capture” é insuficiente; ainda faltam defesas arquiteturais robustas.
- Ideias como um “LLM babá” revisando saídas são descartadas como, no fim, vulneráveis a prompts elaborados (“turtles all the way down”).
Debates de arquitetura
- Vários sugerem que modelos futuros devem separar instruções de dados (por exemplo, fluxos duplos de tokens, canais de dados não executáveis).
- Outros duvidam que isso seja viável com os designs de transformadores atuais, em que tudo é uma sequência única de tokens e os modelos são efetivamente Turing-completos.
- Alguns veem isso como análogo à migração de arquiteturas iniciais inseguras para outras com dados não executáveis, mas reconhecem que isso continua sem solução.
Sentimento sobre LLMs e o Bard
- Entusiasmo por se tratar de uma questão “real” de segurança de IA, em contraste com conversas mais abstratas sobre alinhamento.
- Visões mistas sobre LLMs: alguns os depreciam como “adivinhadores por força bruta”; outros enfatizam o quanto já avançaram e esperam mais progresso.
- O Bard, em particular, é criticado por ser quebrável (por exemplo, via overflow de contexto) e confuso sobre suas próprias capacidades, reforçando dúvidas sobre a maturidade do produto.