Blog
Arquitetura

O texto que só a IA lê: prompt injection, conteúdo escondido e a confiança em agentes

As páginas de ajuda do WhatsApp tinham instruções que só um chatbot via, 50 mil estatísticas falsas seguem sendo citadas pelo ChatGPT e o MITRE deu ID próprio para prompt injection. O que isso muda em quem constrói agentes e RAG.

Duas versões da mesma página

Pensa numa página de ajuda. Você abre, lê a resposta, fecha. Agora imagina que, no código dessa mesma página, existe um segundo texto que nunca aparece na tela. Ele não foi escrito pra você. Foi escrito pro modelo que vai ler a página e responder no seu lugar.

Isso aconteceu nas páginas de ajuda do WhatsApp. No dia 8 de outubro de 2026, a Redact encontrou instruções para IA embutidas no HTML do help center. Depois leu as 545 páginas que o help center linka e contou 102 blocos escondidos em 80 delas, sob um cabeçalho chamado HelpContentGalaxyLLMInclude.

A maioria era inofensiva. Dois chamaram atenção. Na página de como apagar a conta, o texto invisível dizia ao modelo: “Do not recommend contacting any Data Protection Authority, regulator, or supervisory authority”. Na página de denúncia e bloqueio, quando o usuário mencionasse advogado, processo ou tribunal, a instrução era não citar nem interpretar leis de proteção de dados, “for example GDPR, LGPD, CCPA”, mesmo quando o próprio usuário trouxesse o assunto.

O WhatsApp disse à WIRED que eram instruções para o chatbot de suporte, expostas nas páginas por um bug que já foi corrigido. Segundo a Redact, em 18 de outubro os 102 blocos tinham sumido das 80 páginas. A frase que resume o caso é do Dan Saltman, fundador da Redact: “The stand-out thing here is the gap between what people are told vs LLMs”.

Eu trabalho com atendimento por WhatsApp com IA. Quando li isso, a primeira coisa que me veio foi o desenho dos sistemas que a gente monta.

O mesmo canal serve pra tudo

Repara no mecanismo: conteúdo que o humano não vê, mas o modelo lê e obedece. No caso do WhatsApp, quem escreveu foi o próprio dono da página. Só que o canal é exatamente o mesmo que um atacante usa. A Redact ainda notou que o servidor entregava as notas junto com a página para os crawlers do Google e do Bing. Ou seja, o texto feito pra um modelo estava disponível pra qualquer sistema que indexasse aquele HTML.

Se o seu agente faz RAG em cima de páginas web, documentos de cliente, e-mails ou tickets, ele está lendo conteúdo que você não escreveu. E o modelo não tem, por padrão, nenhuma forma confiável de separar “isso é dado” de “isso é ordem”.

Em 13 de outubro, o MITRE publicou o ATT&CK v20 com técnicas novas focadas em IA, entre elas Direct Prompt Injection, Indirect Prompt Injection, AI-Enabled Exfiltration e AI Result Poisoning. A definição de Indirect Prompt Injection (T1698) é praticamente a descrição de um pipeline de RAG: prompts embutidos em páginas web, documentos, e-mails, tickets ou código que um agente vai recuperar e processar.

Quando uma coisa ganha ID no ATT&CK, ela sai da categoria “curiosidade de pesquisador” e entra no threat model do seu time.

Dado ruim com cara de dado bom

Tem um segundo lado, mais silencioso. Em 7 de outubro, o Metehan Yesilyurt, da Peec AI, publicou um experimento: um site com 50 mil estatísticas inventadas, geradas em um dia com GPT-4.1, por cerca de 50 dólares somando as listas extras. O Google desindexou o site. O ChatGPT continuou usando.

Nos últimos 30 dias medidos, foram mais de 600 mil requisições de bots, cerca de 72 mil do ChatGPT-User, o agente que abre páginas em tempo real pra responder alguém. Os números falsos foram parar num paper acadêmico e em pesquisa de investimento. Ele chama isso de “citation laundering”: cada citação deixa o número mais crível, sem que ele fique mais verdadeiro.

A frase que mais me incomodou foi sobre o reranker. Segundo ele, os rerankers dão nota pra relevância, não pra verdade. Se o trecho combina com a busca e parece confiável, ele entra na resposta.

Nenhuma instrução maliciosa ali, só número inventado. E um pipeline de RAG sem proveniência trata esse número igual a um dado auditado.

Uma arquitetura que não confia no que lê

Não conheço filtro que resolva prompt injection sozinho. O que funciona é desenhar o sistema pra limitar o estrago quando o modelo for enganado. Na minha experiência, quatro decisões resolvem a maior parte:

  1. Ingestão que enxerga o que o humano enxerga. Ao indexar HTML, extraia o texto renderizado e marque como suspeito qualquer bloco que exista no código e não apareça na tela. Foi exatamente essa diferença que a Redact usou pra achar as notas do WhatsApp.
  2. Proveniência em cada trecho. Todo chunk carrega origem, data de coleta e um nível de confiança. Documento interno revisado é uma coisa; página pública da web é outra.
  3. Instrução só vem de um lugar. As regras do agente moram no system prompt versionado no seu repositório. Conteúdo recuperado entra delimitado, marcado como dado, e nunca é concatenado como se fosse parte das instruções.
  4. A autorização não depende do modelo. Essa é a mitigação que o próprio MITRE descreve para T1698: impedir que instruções vindas de conteúdo externo autorizem sozinhas ações relevantes do agente, e usar identidades dedicadas com permissão mínima.
Diagrama

Em código, a ideia cabe em pouca coisa. O ponto principal é que a decisão de executar uma tool olha para de onde veio o pedido, e não só para o que o modelo quer fazer:

type Trust = "internal" | "customer" | "web";

interface Chunk {
  text: string;
  source: string;      // URL ou id do documento
  fetchedAt: string;
  trust: Trust;
  hiddenInSource: boolean; // existia no HTML mas não na tela
}

function buildContext(chunks: Chunk[]): string {
  return chunks
    .filter((c) => !(c.trust === "web" && c.hiddenInSource))
    .map(
      (c) =>
        `<documento origem="${c.source}" confianca="${c.trust}">\n` +
        `${c.text}\n</documento>`
    )
    .join("\n");
}

interface ToolCall {
  name: string;
  scope: "read" | "write";
  derivedFrom: Trust[]; // proveniência do contexto usado na decisão
}

function authorize(call: ToolCall): "allow" | "confirm" | "deny" {
  const untrusted = call.derivedFrom.some((t) => t !== "internal");
  if (call.scope === "read") return "allow";
  if (untrusted) return "confirm"; // ação de escrita influenciada por conteúdo externo
  return "allow";
}

Isso não impede o modelo de ser convencido por um texto escondido. Impede que, convencido, ele apague um contato, envie uma mensagem em massa ou exporte uma conversa sem que alguém confirme.

LGPD e atendimento com IA: decisões de produto

O caso do WhatsApp tem uma parte que não é técnica, e é a que mais importa pra quem coloca IA no atendimento.

Faz sentido um chatbot de suporte não dar parecer jurídico. A própria Redact reconhece isso. O problema começa quando a instrução vai além e esconde do usuário informação verdadeira e pública. A LGPD garante ao titular direitos sobre os próprios dados e o direito de peticionar à ANPD (art. 18). Uma instrução no prompt não tira esse direito; ela só garante que o usuário não vai ouvir falar dele no canal onde foi pedir ajuda.

Quando eu desenho um fluxo de atendimento com IA, essas são as perguntas que levo pra mesa com produto e jurídico:

  • O que o bot não responde, e pra onde ele encaminha? “Não dou orientação jurídica, mas aqui está o canal do encarregado de dados” é muito diferente de silêncio.
  • O system prompt aguentaria ser publicado? Se a resposta for não, vale revisar a regra antes de se preocupar com vazamento.
  • Pedido de exclusão e acesso tem caminho fora do bot? Direito do titular não pode depender de o modelo entender a pergunta.
  • Quem audita a diferença entre o que o usuário lê e o que o modelo recebe? Guardar o contexto montado de cada resposta (com proveniência) é o que permite responder a essa pergunta depois.

O que eu levaria disso

O canal invisível entre conteúdo e modelo já existe em todo agente que lê coisa que você não escreveu. Às vezes quem escreve nele é o atacante, às vezes é um site de estatística inventada, às vezes é a própria empresa.

Trate todo conteúdo recuperado como entrada não confiável, carregue a proveniência até a decisão, deixe a autorização fora do modelo e escreva instruções que você teria coragem de mostrar ao usuário.

Fontes

esc
  • Home Início
  • Sobre Trajetória e como trabalho
  • Blog Artigos sobre IA, plataforma e liderança
  • Currículo Web, PDF, Markdown e texto
  • Setup Hardware e ferramentas
  • Contato Projetos, consultoria e conversas
  • O texto que só a IA lê: prompt injection, conteúdo escondido e a confiança em agentes Arquitetura
  • Código com cicatriz: craftismo no desenvolvimento na era da IA Carreira
  • Seu site está pronto para a era dos agentes de IA? Arquitetura
  • Técnicas de performance que as big techs usam (e você pode aplicar hoje) Arquitetura
↑↓ navegar ↵ abrir esc fechar