Prompt injection indireto expõe falha de segurança em agentes de IA

Prompt injection indireto é o ataque em que uma instrução maliciosa é plantada em conteúdo externo (uma página, um e-mail, um documento) que o agente de IA lê durante uma tarefa legítima. Ao processar esse conteúdo, o modelo pode interpretar a instrução plantada como um comando válido e executá-la com as ferramentas que tem à disposição. O risco cresce porque o agente pode navegar, preencher formulários e acessar contas, não apenas gerar texto.

Para a definição, diferenças em relação a jailbreak e SQL injection e as variantes LLM2X, leia o guia completo sobre o que é prompt injection.

Neste guia

• O que muda quando um chatbot vira agente
• O que é prompt injection indireto
• StepJack: o ataque dividido em etapas
• LoginTrap: a fronteira da autenticação
• StepJack e LoginTrap lado a lado
• Por que o modelo não precisa ser hackeado
• Prompt injection já circula na internet real
• Permissão como camada de segurança
• O custo de proteger um agente
• Como reduzir o risco na prática
• Perguntas frequentes

O que muda quando um chatbot vira agente

Um modelo de linguagem que só responde perguntas tem um raio de dano limitado. Se ele interpreta mal um dado, o resultado é uma resposta ruim, e cabe à pessoa decidir o que fazer com ela.

Um agente de IA opera diferente. Dependendo das ferramentas e permissões concedidas, ele pode navegar na internet, ler e-mails, preencher formulários, clicar em elementos de uma página e executar ações em contas autenticadas. A OpenAI reconhece que, quando um agente está conectado a sites e aplicativos, ele pode acessar informações sensíveis e agir em nome do usuário, e que as proteções existentes reduzem, mas não eliminam, o risco de prompt injection.

A Anthropic descreve o mesmo problema pelo lado do navegador: para ser útil, um agente de browsing precisa processar conteúdo externo, e cada página visitada é um vetor potencial para instruções maliciosas. Em testes internos com adversário adaptativo, a companhia registrou taxa de sucesso de ataque de 23,6% em uso de browsing sem as mitigações mais recentes, número que caiu para cerca de 1% depois de reforços de treinamento e classificadores aplicados ao Claude Opus 4.5.

O conflito de fundo não muda: o agente precisa ler a internet para trabalhar, mas não deveria obedecer a tudo que lê nela.

O que é prompt injection indireto

Um modelo de linguagem recebe, no mesmo espaço de contexto, instruções do desenvolvedor, comandos do usuário, resultado de ferramentas e conteúdo externo (páginas, documentos, e-mails, dados recuperados de uma base). Prompt injection indireto tenta fazer com que esse conteúdo externo seja interpretado não como informação a processar, mas como uma instrução a executar.

A diferença para a injeção direta é o canal. Em um ataque direto, alguém conversa com o modelo tentando convencê-lo a ignorar regras. Em um ataque indireto, o atacante não precisa falar com o agente: basta colocar a instrução em algum lugar que o agente vá visitar durante uma tarefa legítima.

OpenAI, Anthropic e Google tratam esse tipo de ataque como um problema de segurança ativo dos sistemas agentivos, não como uma falha pontual corrigível de uma vez. O desafio central é estrutural: o agente precisa distinguir informação sobre a tarefa de instrução autorizada para executar a tarefa, e essa fronteira, óbvia para um humano, nem sempre é óbvia para um modelo.

StepJack: o ataque dividido em etapas

StepJack: Benchmarking Computer-Use Agent Safety Against Multi-Step Indirect Prompt Injection é um artigo de Zhuoxin Zhan, Akbar Rafiey, Avery Ma, Leila Pishdad e Layla El Asri, publicado no arXiv em 6 de agosto de 2026. O trabalho propõe uma nova classe de ataque contra agentes de uso de computador (computer-use agents, ou CUAs): em vez de esconder o objetivo malicioso inteiro em uma única página, os pesquisadores o decompõem em sub-etapas que, isoladas, parecem inofensivas, e distribuem essas sub-etapas ao longo da cadeia de páginas que o agente percorre durante a tarefa.

Cada etapa isolada tende a passar despercebida pelo raciocínio de segurança do agente. O objetivo malicioso só se completa quando a sequência inteira é executada.

Os autores construíram o benchmark StepJack com 480 exemplos de teste e avaliaram seis agentes de uso de computador de ponta. Em decomposição de três etapas, o ataque elevou a taxa de sucesso (ASR, na sigla em inglês) em três dos seis agentes testados, em até 31,2 pontos percentuais. No caso do GPT-5.4-mini, a taxa de sucesso subiu de 41,7% no ataque de uma única etapa para 72,9% no ataque dividido em três etapas.

Considerando a média dos cinco agentes capazes de seguir de forma confiável a cadeia de páginas de referência (todos, exceto o EvoCUA-32B), a taxa de sucesso média subiu de 31,3% para 36,9% entre o ataque de uma etapa e o de três etapas.

Esses números vêm de condições experimentais específicas do benchmark e não devem ser lidos como a chance de qualquer agente real ser comprometido na internet aberta. O achado relevante é qualitativo: dividir uma instrução perigosa em partes aparentemente normais dificulta que o agente reconheça o objetivo malicioso completo, porque nenhuma etapa isolada dispara o sinal de alerta que uma instrução única e explícita dispararia.

LoginTrap: a fronteira da autenticação

LoginTrap: Uncovering Task-Agnostic Phishing-Style Indirect Prompt Injection Attacks against LLM-based Web Agents é um artigo de Longtao Guo, Zelin Zhang, Kaifeng Huang e Yang Shi, publicado no arXiv em 5 de agosto de 2026. O estudo mira um ponto específico da navegação agentiva: o momento de login.

O ataque assume um adversário que controla o conteúdo de uma página e o fluxo de login induzido, sem conhecer a tarefa do usuário nem os detalhes internos do agente. A partir do contexto da própria página, o LoginTrap gera injeções específicas por meio de um processo inspirado em fuzzing, fazendo o login parecer um pré-requisito plausível para continuar a tarefa e conduzindo o agente até uma página de login controlada pelo atacante.

O resultado central do artigo é uma taxa média de sucesso ponta a ponta de 86% entre diferentes modelos de base, com efetividade mantida em diferentes arquiteturas de agente e diante das defesas testadas pelos autores.

A lógica lembra phishing tradicional, com uma inversão importante. No phishing clássico, o atacante engana um humano, que então realiza a ação. No cenário mapeado pelo LoginTrap, o atacante engana o agente, que inicia a ação, e o humano pode entrar no processo apenas no fim, ou precisar perceber que algo é anormal antes disso.

StepJack e LoginTrap lado a lado

Por que o modelo não precisa ser hackeado

Um dos aspectos menos intuitivos desse tipo de ataque é que ele não depende necessariamente de uma falha clássica de software, como corrupção de memória ou execução arbitrária de código por um bug de navegador. O agente continua funcionando exatamente como foi projetado: lê linguagem, interpreta instruções, escolhe ferramentas e executa ações. O atacante tenta interferir justamente nessa cadeia de decisão, não no código que a implementa.

Isso muda a pergunta que a segurança de agentes precisa responder. Não basta perguntar se o modelo reconhece um prompt malicioso. É preciso perguntar também o que o agente tem permissão para fazer, mesmo quando é enganado.

Prompt injection já circula na internet real

O problema não é apenas de laboratório. Um estudo publicado no arXiv em abril de 2026, Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives, analisou 1,2 bilhão de URLs de 24,8 milhões de hosts e identificou 15,3 mil instâncias validadas de prompt injection distribuídas em 11,7 mil páginas.

Os objetivos variavam entre tentativas de bloquear coleta automatizada por IA, manipular sistemas de busca e influenciar como agentes interpretam determinado site. Cerca de 70% das instruções identificadas estavam em partes do HTML que normalmente não aparecem visualmente para quem navega, como cabeçalhos, comentários e metadados. O Google relatou observações semelhantes de tentativas de prompt injection voltadas a manipular sistemas de IA na web.

A implicação prática é que a internet passou a conter dois tipos de texto ao mesmo tempo: o escrito para pessoas lerem e o escrito para tentar instruir a máquina que está lendo em nome delas.

Permissão como camada de segurança

A vulnerabilidade de um modelo a determinado ataque de prompt injection pode ser parecida entre dois agentes diferentes. O potencial de dano não é.

Um agente restrito a consultar informação pública e produzir texto tem um raio de dano limitado mesmo se for enganado. Um agente com acesso a e-mail, documentos privados, sessões autenticadas e capacidade de preencher formulários e executar comandos tem um raio de dano muito maior diante do mesmo tipo de manipulação.

Por isso o princípio do menor privilégio, um conceito antigo de segurança da informação, volta ao centro do debate sobre agentes. A Anthropic recomenda avaliar com cuidado quais ferramentas, dados e ambientes são disponibilizados a um agente, e afirma que nenhuma salvaguarda hoje representa garantia absoluta contra prompt injection. A OpenAI segue abordagem parecida, combinando restrições de acesso, confirmação de ações sensíveis e monitoramento de tentativas de injeção nos seus sistemas agentivos.

O custo de proteger um agente

Reduzir o risco de prompt injection tem preço em fricção e engenharia, não apenas em dinheiro. Separar leitura de execução, exigir confirmação humana para ações sensíveis e tratar todo conteúdo externo como não confiável adicionam etapas ao fluxo do agente e podem tornar tarefas simples mais lentas.

A alternativa (dar ao agente autonomia ampla sem essas camadas) reduz a fricção no curto prazo, mas amplia exatamente a superfície que StepJack e LoginTrap exploram. Quanto mais ferramentas e dados um agente acumula para ficar mais útil, maior fica o conjunto de ações que uma instrução manipulada pode disparar.

A OpenAI descreve esse mesmo trade-off ao observar que o impacto potencial de um ataque de prompt injection cresce quando o agente tem acesso simultâneo a mais ferramentas e mais dados. Não existe hoje uma atualização de modelo capaz de eliminar esse cálculo, porque dado e comando podem chegar ao modelo no mesmo formato: linguagem.

Como reduzir o risco na prática

1. Evite acesso permanente sem necessidade. Se o agente precisa de um serviço só para uma tarefa pontual, encerre a conexão depois.
2. Separe leitura de execução. Consultar dados é uma permissão. Enviar, alterar ou excluir dados é outra, e deveria exigir concessão à parte.
3. Exija confirmação humana para ações sensíveis. Envio de e-mail, compras, alteração de conta, transferência e exclusão de arquivos são bons candidatos a essa trava.
4. Trate páginas, e-mails e documentos como conteúdo não confiável. Uma instrução aparecer dentro de um conteúdo externo não significa que ela faça parte da tarefa pedida pelo usuário.
5. Limite as credenciais disponíveis durante a tarefa. Menos acesso sensível ativo reduz o impacto possível de uma manipulação bem-sucedida.
6. Use isolamento (sandboxing). Ambientes e perfis dedicados limitam o alcance de um comportamento inesperado.
7. Registre as ações do agente. Em ambiente corporativo, saber o que foi acessado e qual ferramenta foi usada é o que viabiliza auditoria depois de um incidente.

Essas medidas seguem a mesma lógica presente nas recomendações públicas de OpenAI, Anthropic e Google: nenhuma defesa isolada é suficiente, e o objetivo é empilhar barreiras entre conteúdo não confiável e ações de alto impacto.