Prompt injection em chatbots para websites: proteção para RAG, ferramentas e dados

Um chatbot para websites não processa apenas perguntas inofensivas. Os visitantes podem tentar reescrever as suas regras, expor instruções internas ou disparar ações não autorizadas. Ainda mais difíceis de detetar são as ordens que não estão diretamente no chat, mas sim ocultas numa página web recolhida pelo crawler, num documento carregado ou num sistema de terceiros ligado ao chatbot.

Quem deseja mitigar a prompt injection em chatbots para websites não se pode fiar apenas num prompt de sistema formulado de forma estrita. É necessária uma arquitetura multicamada: as entradas e fontes são tratadas como não confiáveis, as permissões são restritas do ponto de vista técnico, as saídas são verificadas antes do processamento posterior e as ações de risco são confirmadas por código determinístico ou por um ser humano.

O que significa a prompt injection num chatbot para websites

A OWASP descreve a prompt injection como uma entrada que altera não intencionalmente o comportamento ou a saída de um modelo de linguagem. Uma prompt injection direta provém diretamente do utilizador, por exemplo, sob a forma de uma instrução para ignorar regras anteriores. Por outro lado, uma prompt injection indireta encontra-se oculta em conteúdos externos recuperados posteriormente pelo sistema: páginas web, documentos de conhecimento, e-mails, dados de produtos ou ficheiros.

Esta distinção é importante para os gestores de websites. Um chatbot de FAQ puro tem uma superfície de ataque muito menor do que um sistema que rastreia continuamente páginas web, pesquisa documentos internos, lê dados do CRM ou executa funções. A geração aumentada por recuperação (Retrieval-Augmented Generation ou RAG) melhora a base factual das respostas, mas não elimina o risco de injection. Mesmo uma base de conhecimento bem mantida pode conter instruções manipuladas ou mal interpretadas.

Avaliar o risco por funcionalidades e não pelo nome do modelo

A questão crucial não é apenas: „Que modelo estamos a utilizar?“, mas sim: „Que impacto pode ter uma resposta manipulada?“. Crie um mapa simples de funcionalidades e dados para o chatbot:

• Que fontes públicas e internas pode o chatbot ler?
• Que dados pessoais, confidenciais ou críticos para o negócio estão acessíveis?
• O chatbot apenas gera texto ou também pode criar tickets, leads, e-mails, agendamentos ou encomendas?
• Que ações alteram sistemas externos?
• Que decisões são tomadas automaticamente sem validação humana?

Quanto maiores forem as permissões de leitura, escrita e o grau de automatização, mais importantes se tornam os limites técnicos fora do modelo. O resumo existente sobre erros comuns em chatbots de IA ajuda no levantamento geral. No caso da prompt injection, é necessário documentar adicionalmente os fluxos de dados, as fronteiras de confiança e as permissões de ação.

Separar claramente quatro zonas de confiança

Um modelo prático de segurança distingue quatro zonas, mesmo que sejam processadas tecnicamente na mesma aplicação.

Zona 1: Regras do sistema e diretrizes

Aqui definem-se o papel, o propósito permitido, os limites das respostas e as regras de escalamento. Estas regras orientam o modelo, mas não constituem um controlo de acesso fiável. A OWASP alerta expressamente contra o tratamento de prompts de sistema como segredo ou mecanismo de segurança. Dados de acesso, chaves de ligação e informações internas confidenciais não devem constar aqui.

Zona 2: Entradas dos visitantes

Todas as mensagens do chat devem ser tratadas como não confiáveis. Limite o comprimento, os tipos de ficheiro e as funções permitidas; normalize as entradas para o processamento técnico e identifique-as claramente no prompt como dados do utilizador. Um filtro pode detetar padrões de ataque conhecidos, mas não deve bloquear perguntas legítimas de forma genérica. Um visitante que pergunte sobre „ignore previous instructions“ numa documentação de segurança pode ter uma dúvida legítima.

Zona 3: Fontes recuperadas e contexto RAG

Mesmo os conteúdos recolhidos por crawler, PDFs e resultados de serviços externos continuam a ser dados, e não instruções. Separe visualmente o seu conteúdo do contexto de controlo, armazene a origem e a data de recolha e permita apenas fontes aprovadas. O artigo sobre manter a base de conhecimento do chatbot atualizada mostra como o inventário de fontes, a frequência de crawl e o QA trabalham em conjunto.

Zona 4: Ferramentas, ações e saídas

As chamadas de função não devem ser executadas apenas porque o modelo gerou o texto correspondente. Um controlador determinístico verifica o nome da função, os parâmetros, as permissões, o contexto da sessão e os sistemas de destino permitidos. As saídas do modelo que sejam posteriormente utilizadas como HTML, Markdown, SQL, caminhos de ficheiro ou parâmetros de API necessitam de validação e codificação adequadas a esse contexto.

O menor privilégio limita o impacto

Atualmente, não é possível eliminar de forma fiável a prompt injection com uma única medida. Por esse motivo, a aplicação deve ser construída de modo a que uma tentativa de manipulação bem-sucedida tenha o menor impacto possível. A OWASP e a Microsoft recomendam para o efeito o princípio do menor privilégio (Least Privilege).

• Utilize identidades técnicas separadas para leitura e escrita.
• Conceda acesso apenas aos dados estritamente necessários para a finalidade específica do chatbot.
• Restrinja as funções a esquemas de parâmetros pequenos e claramente definidos.
• Utilize permissões temporárias quando uma ação realmente necessitar delas.
• Exija uma confirmação explícita para passos de risco ou irreversíveis.
• Nunca confie a autorização ao texto livre gerado pelo modelo.

Por exemplo, um chatbot de suporte pode preparar um rascunho de ticket, mas não deve definir automaticamente destinatários genéricos, prioridades ou permissões de acesso internas. Um chatbot de captura de leads pode recolher dados de contacto estruturados sem que isso lhe dê acesso de leitura a todo o CRM.

Verificar e isolar fontes RAG

A prompt injection indireta transforma a pipeline de fontes numa parte integrante da arquitetura de segurança. Uma página manipulada pode parecer inofensiva à vista desarmada e, ainda assim, conter texto que o modelo interprete como uma instrução. Em sistemas multimodais, imagens ou outros formatos de ficheiro também podem desempenhar um papel.

Por isso, estabeleça um fluxo de entrada de fontes com regras de aprovação: domínios e áreas de documentos permitidos, responsáveis identificáveis, versionamento, verificação de malware e ficheiros, bem como revisão de conteúdos novos ou invulgarmente alterados. Identifique os excertos recuperados no contexto do modelo expressamente como conteúdo não confiável (untrusted content). Um resultado da pesquisa pode fornecer informações, mas não deve alterar regras do sistema ou permissões de ferramentas.

Verifique também se a resposta está realmente fundamentada nas fontes. O guia sobre qualidade das respostas de chatbots de IA com Golden Set e testes RAG descreve a fundamentação (groundedness) e a validação de fontes. Esta verificação de qualidade complementa os controlos de segurança, mas não os substitui.

Filtros de entrada e saída são uma camada, não a solução completa

Serviços de proteção especializados podem detetar tentativas de ataque diretas e indiretas. O Microsoft Prompt Shields, por exemplo, distingue ataques em entradas do utilizador de instruções ocultas em documentos. A Google também recomenda nas suas diretrizes de segurança medidas de proteção contra prompt injection, tarefas mais delimitadas, identificadores de utilizadores, limites de taxa e supervisão humana em cenários de maior risco.

Estes filtros fornecem sinais probabilísticos. Planeie, portanto, um comportamento em níveis: bloquear, responder de forma segura, alternar para um modo estritamente limitado ou transferir para um operador humano. Registe a classe de decisão e a versão técnica, mas evite o armazenamento desnecessário de texto integral. No caso de dados pessoais, aplicam-se adicionalmente as áreas de verificação descritas no artigo sobre chatbots de IA e RGPD. Este artigo não constitui aconselhamento jurídico.

Validar as saídas do modelo antes do processamento posterior

Uma entrada segura não garante uma saída segura. A OWASP lista o tratamento inadequado da saída como um risco autónomo: o texto do modelo pode acabar por ser injetado em HTML, scripts, consultas de base de dados ou caminhos de ficheiros. Por isso, trate também qualquer saída do modelo inicialmente como não confiável.

Exija um formato estruturado estrito para fluxos automatizados e valide-o em relação a um esquema. Utilize listas de permissão (allowlists) para nomes de funções e sistemas de destino. Codifique o texto visível para o contexto de saída específico. Descarte campos inesperados, URLs externas e parâmetros fora dos valores permitidos. Dados sensíveis devem passar por uma verificação de diretrizes própria antes da exibição ou transmissão.

Testar a prompt injection com um conjunto de testes de segurança

Complemente o Golden Set funcional com casos de teste adversariais. Os testes devem avaliar o sistema em produção real — incluindo recuperação, ferramentas e lógica de permissões — e não apenas o modelo base. Um conjunto útil inclui:

• tentativas diretas de substituir regras ou consultar instruções internas;
• variantes multilingues, codificadas e distribuídas por várias mensagens;
• perguntas legítimas que contenham palavras-chave semelhantes e não devam ser bloqueadas por engano;
• trechos manipulados numa fonte de conhecimento de teste;
• nomes de funções não permitidos, parâmetros adicionais e endereços de destino externos;
• tentativas de expor dados confidenciais ou conteúdos de sessões anteriores;
• testes para saídas de HTML, Markdown e links;
• fluxos de cancelamento, transferência humana e confirmação para ações de risco.

Não meça apenas se um filtro foi acionado. Avalie o resultado final: Uma ação não autorizada foi evitada? Os dados confidenciais permaneceram protegidos? Uma consulta legítima continuou a funcionar? O incidente suspeito foi registado de forma auditável?

Plano prático de implementação para equipas de websites

1. Mapear o escopo: Documentar fontes de dados, ferramentas, permissões de escrita e destinos externos.
2. Separar zonas de confiança: Identificar tecnicamente regras do sistema, entradas de utilizadores, conteúdos RAG e saídas de ações.
3. Reduzir permissões: Remover acessos não utilizados e dividir ações de escrita em pequenas funções.
4. Adicionar validações: Implementar limites de entrada, saídas estruturadas, listas de permissão e codificação específica do contexto.
5. Definir confirmações: Proteger ações de risco e fluxos de dados sensíveis com intervenção humana (Human-in-the-Loop).
6. Executar o conjunto de testes: Validar casos de controlo diretos, indiretos e legítimos antes de cada lançamento relevante.
7. Monitorizar a operação: Rever regularmente eventos de filtro, ações recusadas, alterações invulgares nas fontes e falsos positivos.

Lista de verificação: Proteção contra prompt injection

• O prompt de sistema não contém segredos nem substitui a autorização.
• Os textos dos utilizadores e as fontes externas são tratados por padrão como não confiáveis.
• As fontes RAG têm aprovação, origem, versão e responsáveis definidos.
• As ferramentas seguem o princípio do menor privilégio e aceitam apenas parâmetros validados.
• Ações de risco exigem uma confirmação auditável.
• As saídas do modelo são verificadas antes de irem para HTML, API, CRM ou outros sistemas de destino.
• Os filtros de segurança são avaliados quanto a falsos positivos e falsos negativos.
• Testes de ataque diretos e indiretos são executados regularmente e após alterações.

Conclusão

A prompt injection não é um problema exclusivo da engenharia de prompts. Em chatbots para websites, uma proteção sólida surge apenas quando a aplicação trata entradas, fontes, saídas e ações como zonas de confiança separadas. Os filtros podem detetar ataques, mas o menor privilégio, a validação determinística e a confirmação humana delimitam o seu impacto potencial.

Comece com o mapa de funcionalidades e dados do seu chatbot. Remova permissões desnecessárias, isole conteúdos RAG e teste todo o caminho até à ação externa. Desta forma, o chatbot continua útil sem que o texto livre do modelo decida sobre permissões ou alterações críticas para o negócio.

Fontes

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance