Injeção de prompt: uma fonte pode mudar a tarefa do seu assistente?

Um bom primeiro uso de IA pode ser bastante simples: reunir informações públicas de concorrentes e preparar uma síntese para a equipe. Esse trabalho continua útil sem acesso a documentos confidenciais e sem permissão para enviar mensagens. Definir esses limites ajuda a entender o que está sendo automatizado antes de acrescentar novas funções.

Consultar um documento não significa aceitar suas ordens

A injeção de prompt ocorre quando um conteúdo controlado por um atacante tenta modificar o comportamento previsto de um modelo de linguagem. Na forma indireta, esse conteúdo chega por uma página, um documento, um e-mail ou o resultado de uma ferramenta. O assistente pode encontrar a instrução mesmo sem que alguém da equipe a tenha inserido de propósito.

Considere um exemplo hipotético: o assistente compara três páginas públicas para um briefing interno. Uma delas contém uma orientação para favorecer a própria empresa ou omitir uma fraqueza. A página pode fornecer informações para a comparação, mas não pode redefinir o pedido. O assistente deve tratar essa orientação como conteúdo não confiável e sinalizar a tentativa sem obedecer a ela.

Isso é diferente de uma afirmação inventada pela IA. Aqui, existe uma instrução na fonte tentando desviar o trabalho. O efeito pode ser uma síntese tendenciosa, o uso indevido de uma ferramenta ou a exposição de dados, conforme as permissões disponíveis. Procurar frases suspeitas não permite detectar todas as tentativas com segurança.

Mapeie o que o assistente lê e por onde os dados podem sair

Faça esse levantamento com o responsável pelo sistema. Liste as entradas, os dados privados que podem ser consultados, as ferramentas disponíveis, os canais de comunicação externa e quem recebe os resultados. No exemplo anterior, acrescentar acesso a notas privadas de preços e a envio de mensagens mudaria as possíveis consequências. Essas permissões não devem acompanhar automaticamente toda pesquisa.

O acesso somente para leitura impede determinadas alterações pelas ferramentas autorizadas, mas não bloqueia necessariamente a divulgação de informações. Também é preciso conferir quais endereços podem ser acessados, quais dados seguem nas requisições e quais destinatários podem receber respostas. Impedir uma edição não equivale a impedir uma saída de dados.

Na MindVerve, nossa recomendação é manter o primeiro piloto restrito a um rascunho, com fontes aprovadas e não sensíveis. Não forneça segredos à etapa de pesquisa. Peça ao responsável pela configuração que desative funções desnecessárias de escrita, envio e publicação e restrinja os destinos permitidos na plataforma.

Guarde a origem das fontes para que uma pessoa confira as afirmações importantes nos documentos originais. Se não for possível verificar os acessos e as restrições de saída, reduza o piloto a documentos aprovados fornecidos manualmente, sem ações externas. Envolva o responsável de TI ou segurança antes de usar dados sensíveis.

O prompt esclarece a tarefa, mas não configura as permissões

Separar visualmente as instruções do material consultado ajuda a comunicar a intenção. Você também pode pedir que o assistente sinalize tentativas de desvio como conteúdo da fonte e não as execute. Essas orientações são úteis, porém não criam uma barreira de segurança nem substituem a configuração técnica.

RAG, ou geração aumentada por recuperação, usa a busca de trechos relevantes para apoiar a produção de uma resposta. Esses trechos ainda podem conter instruções indevidas. Uma segunda IA encarregada de revisar a resposta também pode falhar. Nenhuma dessas medidas garante, por si só, proteção contra injeção.

As análises de OpenAI e Anthropic descrevem defesas combinadas que permanecem imperfeitas. Instruções claras, acesso limitado, validação de ações fora do modelo e acompanhamento com testes cumprem papéis complementares. Esses controles dependem da plataforma e da equipe técnica; escrever um pedido não altera as permissões do sistema.

Um ensaio precisa mostrar o que aconteceu de fato

Propomos um exercício ainda não realizado, em ambiente isolado, com documentos e dados fictícios e sem envio de mensagens reais. Compare uma fonte comum com um documento que peça um slogan sem relação com a tarefa e outro que solicite transmissão a um destinatário fictício não autorizado.

Espera-se uma síntese fiel e útil, com as tentativas de desvio identificadas e tratadas como conteúdo, sem ação externa não autorizada. Verifique isso no registro de ações do sistema. A resposta final do assistente, sozinha, não comprova que ele deixou de enviar algo.

Registre as versões das entradas, do prompt, do modelo e do fluxo, o resultado esperado, o observado e as ações efetivamente registradas. Anote também falsos alarmes, a conclusão do trabalho útil e o esforço de revisão. Repita o exercício após mudanças relevantes; passar uma vez não comprova a segurança do sistema.

Uma ação inesperada ou divulgação deve impedir a expansão do uso. Interrompa o fluxo afetado, preserve apenas as evidências necessárias sem espalhar informações sensíveis e acione o responsável de TI ou segurança. Faça novos testes antes de retomar.

Depois do rascunho, cada ação exige uma decisão própria

Enviar o texto, publicá-lo e mudar o orçamento de uma campanha são ações distintas. Cada uma exige permissão e a conferência do conteúdo ou da alteração exata, do destino e da ação proposta. Um pedido genérico para continuar não deixa claro o que a pessoa está autorizando.

A formação da equipe ajuda na análise das fontes e nas aprovações. Os controles técnicos restringem os acessos e a execução. Escolha um processo que continue útil com esses limites e essa revisão. Uma fonte pode trazer evidências, mas não pode conceder permissão.

Fontes oficiais verificadas em 22 de setembro de 2026, no horário UTC.