Prompt injection: o risco que surge quando o agente de IA ganha acesso

Um assistente de IA que apenas responde perguntas erra e pronto. Um agente de IA que lê e-mails, consulta o ERP, navega em sites e dispara ações erra com consequências. É essa mudança — de responder para agir — que colocou um problema técnico específico no centro das discussões de segurança corporativa: o prompt injection.

A tradução mais direta seria "injeção de instruções". Um atacante esconde comandos dentro de um conteúdo que o agente vai ler — uma página web, um PDF, um chamado de suporte, o corpo de um e-mail — e o agente obedece, achando que aquilo faz parte da tarefa.

Por que isso acontece (e não é um bug comum)

A raiz do problema é arquitetural, não um descuido de implementação. Modelos de linguagem processam a instrução do sistema, o pedido do usuário e o texto trazido de fontes externas como um único fluxo de tokens. Não existe uma separação confiável entre "isto é um comando" e "isto é apenas dado a ser lido".

Na prática, um texto hostil escondido dentro de um documento pode ter a mesma autoridade que a ordem legítima do seu time. É por isso que o OWASP GenAI Security Project aponta o prompt injection como a vulnerabilidade dominante em sistemas agênticos — a técnica se conecta a seis das dez categorias do seu Top 10 para aplicações de agentes.

E a variante mais perigosa é a indireta: não é o usuário que digita o comando malicioso, é o conteúdo que o agente encontrou sozinho pelo caminho. Ninguém está monitorando esse canal.

O padrão que multiplica o estrago

Circula na comunidade de segurança uma regra prática útil para a diretoria, batizada pelo pesquisador Simon Willison de "trifeta letal". Um agente vira uma ferramenta de exfiltração quando acumula três propriedades ao mesmo tempo:

• acesso a dados privados da empresa;
• exposição a conteúdo não confiável (web, e-mails, arquivos de terceiros);
• capacidade de comunicação externa (enviar, publicar, chamar APIs).

Com as três juntas, uma única instrução injetada basta para transformar um assistente útil em um vazamento silencioso. Daí a recomendação prática que a Meta popularizou como "regra dos dois": agentes que operam sem aprovação humana deveriam reunir no máximo duas dessas três propriedades. Quer as três? Então coloque um humano no circuito.

O risco não está na inteligência do agente. Está na combinação de permissões que ninguém revisou antes de ligar a automação.

Não espere uma solução definitiva

Aqui vale o realismo. A própria Anthropic descreve o prompt injection como área ativa de pesquisa, e não como problema resolvido: mesmo taxas baixas de sucesso de ataque representam risco relevante quando o agente age em escala. As defesas existentes são em camadas — treinamento mais robusto, classificadores que analisam conteúdo não confiável e testes adversariais contínuos.

Para quem vai colocar agentes em produção, isso se traduz em decisões de arquitetura:

• Menor privilégio sempre: o agente acessa só o que a tarefa exige, nada além;
• Aprovação humana para ações sensíveis (pagar, enviar, apagar, publicar);
• Separação de contextos: quem lê conteúdo externo não deveria ser quem tem a chave do sistema crítico;
• Registro de tudo: sem log, você não descobre o que aconteceu nem consegue corrigir;
• Testes adversariais periódicos, e não só testes de "caminho feliz".

Segurança é decisão de projeto, não remendo

A conclusão prática é boa notícia: nada disso impede a empresa de automatizar. Impede apenas que ela automatize no escuro. Agentes bem desenhados — com escopo estreito, permissões explícitas e pontos de aprovação nos lugares certos — entregam ganho real sem abrir a porta dos fundos.

Na R-Byte, é assim que construímos agentes de IA e automações: integrados aos sistemas que a empresa já usa, com controle de acesso, rastreabilidade e limites definidos desde o desenho — não depois do incidente. Quer avaliar o que dá para automatizar com segurança no seu negócio? Fale com a gente.